VM Deployment always in Pending state

Question
#1

ManageIQ Newbie.

I have deployed ManagerIQ so that I can create a VM ordering system on top of a typical VMware cluster.
I have added the VMware cluster provider, can see the cluster, hosts and VMs.
When I attempt to deploy a VM is never complete the deployment. The deployment always stays in a Pending state. Why is that and how can I get the VMs deployed (I will worry about the approval process later).

Love the potential in this product.
Thanks.

#2

@NoWay_Hose What roles do you have enabled on the system?

Make sure that the automate role is enabled and is in the proper zone.

#3

Thanks for your response. This has resolved the issue and a large number of deployment all started once selected.
Why would this feature not be enabled by default - seems key to the functionality of the product.

I found the following doco
https://pemcg.gitbooks.io/introduction-to-cloudforms-automation/content/chapter2/writing_and_running_our_own_scripts.html

which states:

“Before we do anything we need to ensure that the Automation Engine server role is ticked on one of the appliances in our CloudForms/ManageIQ Zone (many Automation actions are Zone-specific, so we may need to enable the role in several Zones). We do this from the Configure -> Configuration menu, selecting one of the CloudForms/ManageIQ Servers in the Settings accordion.”

#4

Agreed, the fact that the Automation Engine role is not checked by default is a first-use usability issue.

People have explained it to me in the context of multi-appliance deployments. If you add an appliance to an existing deployment you don’t want it to pick up load until the operator explicitly enables the automation role.

I wonder if both problems can be solved at the same time. For example, if we detect this is the first appliance (e.g. when creating the database), the role is enable automatically.

#5

The automate role was changed to be enabled by default on new appliances in June. PR #3212 - Enable automate role on new servers by default

#6

Hi @gmccullough,

we have multi zone setup. Although there ware several appliance with automation role enabled, there were several Automation Requests and Service Template Provisioning tasks initiated, approved, but stayed in PENDING
[----] I, [2017-04-24T15:39:26.422613 #19626:eb3138] INFO -- : Updated namespace [/System/Process/Event?EventStream%3A%3Aevent_stream=1000003028827&MiqRequest%3A%3Amiq_request=1000000034755&MiqServer%3A%3Amiq_server=1000000000005&ServiceTemplateProvisionRequest%3A%3Aservice_templa te_provision_request=1000000034755&User%3A%3Auser=1000000000001&event_stream_id=1000003028827&event_type=request_created&object_name=Event&vmdb_object_type=service_template_provision_request ManageIQ/System]

These requests stayed in pending untill Automation role at some additional node was initiated.

Is there relation to some other role / worker? As experience says requests stays in queue “somewhere else” even when automation is enabled on defined / designed nodes. Any advice?

Thanks,
Vaclav

P.S. even stayed in “PENDING” when automation task initiated using $evm.execute('create_automation_request', options, 'admin', auto_approve) with defined zone that have enabled automation within that zone

#7

For service-initiated VM provisioning requests you’ll also need the Provider Operations server role enabled in the zone in addition to Automation Engine

pemcg

#8

if i activate the “provider operations server” role, will the actually pending state automatically switch to running state?

#9

If the request was pending because there were no workers available to pick up the ‘ems_operations’ message in the zone, then yes, enabling the ‘Provider Operations’ server role should enable the request to continue and create the Service Template Provisioning tasks.

#10

ok thanks. it didn’t work. in fact it does not work anymore since last upgrade (CF 4.2 -> 4.6) i think.

#11

finally it worked. there were a big delay. strange.

#12

There may have been a lot of ems_operations messages backed up. Try running this command on an evm.log from a couple of days ago, it’ll tell you the number of queued messages of each type, per zone:

zgrep 'count for state=\["ready"\]' evm.log-20180702.gz