vCloud Director 1.5 blocking tasks and notification package using AMQP

[#1]

This package for the vCenter Orchestrator plug-in for vCloud Director 1.5 allows to trigger custom workflows on vCloud Director blocking tasks and notifications with including:

• "Create a vCD notification subscription" (including AMQP host, exchange, queue, binding) with getting AMQP configuration from the vCloud Director configuration. Select end user custom workflow to run on specific blocking task or notification.
• "Start a subscription listener workflow" Start a looping workflow waiting for new messages from the selected subscription created with the workflow "Create a vCloud Director notification subscription" and then run the workflow runner which convert the message to vCD inputs and pass these to the end user selected workflow.
• Workflows samples to be triggered by the blocking tasks and notifications: 
  • Approve vApp (Simple) : Sent email notification with details to approver with link to web page to approve vApp.
  • Approve vApp (AD) : Same plus add computer to AD Organization matching vCloud Director Organization.
  • Customize VM names and IP : Upon deployment of new vApp set custom vApp VM names & IPs.
  • Log all : Log all the information passed by the workflow runner. Usefull to check what information can be obtained from a given event.

Disclaimer: These samples workflows are provided AS IS and are not production quality. Use at your own risk. Feel free to modify and expand and share your contributions.

Documentation

These are the instructions to have the sample workflows working

• Pre-requisite : 
  • vCO installed and configured
  • AMQP plug-in installed
  • vCloud Director 1.5 vCO plug-in installed and configured using the System org
  • Microsoft AD vCO plug-in installed and configured
  • Perspective plug-in installed
  • Mail plug-in configured
  • AMQP server freshly installed (if you messed up with AMQP before chances are something will be set wrong)

• vCloud Director: 
  • Configure blocking tasks settings with AMQP server info and Test the AMQP Connection
  • Check "Instantiate vApp from Template" blocking task
• Import package in vCO:  
  • Start vCenter Orchestrator Client.
  • Import package com.vmware.coe.vcd.notifications.package
• Configure email notifications for sample workflows
  • Run the workflow "customization Config" (Approver group, email, parent OU to create new OU, timeouts)
• Configure Perspectives (the web front-end)
  • Start the "Initialize vCD Notifications Perspective" workflowUse Perspectives to create a new notification subscription:
  • Upon successful execution of workflow, open browser to http://<vco server>:8280
  • Click “Web View List”
  • Click “Perspectives”
  • Login to Perspectives as your vCO Administrator
  • Load the “vCD Notification Admin” perspective by clicking the link
  • Run the “Create a vCloud Director notification subscription” workflow by clicking the link in the left pane and then the “Start task” button in the right pane
    • Give a subscription name (i.e "On vAppTemplate Instantiation")
    • Set AMQP password
    • Create a broker: yes
    • Filter on blocking task operation type: yes
    • Select event type (this should display the one you enable in vCD)
    • Filter on entity type: no
    • Filter on notification age: no
    • Select a Workflow to start (i.e Approve vApp)
    • Next screen will show the calculated routing key. Do not change it ! Submit.
• Start the listener workflow:
  • Click “Start a subscription listener workflow”, choose the Subscription that was just created and click Submit
• Test:
  • Go to vCD and attempt to Instantiate (deploy in vCD UI terms) a template from the catalog
  • Open the vCO client and check "Start a subscription listener workflow" has a new Workflow run
  • Check the Approve vApp workflow you selected ran as well. If successful check email of the approver.
  • Click on the approve link, login, approve.

[mschubi]

Hello Christophe,

thats a realy good sample to start with blocking tasks.

But i have some trouble with "Configure vCloud Ddirector AMQP subscription" workflow.

(AMQP and this stuff works well - testet with own workflows that trigger "Delete" of a vApp)

But if i start the "Create a vCloud Director notification subscription" Workflow it fails in "Configure... AMQP subscription" on step "Get config". I checked the code an add some debugging to it. So i found

that the method "toAdminObject()" on vCloud:Host Object works but than method "toAdminExtensionObject()" on the vCloud:HostAdmin Object returns null.

I checked all extensions an Plugins for vCO. (all installed an in the right version.) i have no idea what happens.

Do you have some hints for me?

thanks,

Mike

[cdecanini_]

Hi,

How is configured your vCloud Director plug-in ? It is necessary to be connected to the System organization as the cloud administrator.

Can you browse your cloud inventory and get to the Admin / Extension part ?

Christophe.

[mschubi]

Hi Christophe,

i used the Administrator for "Organisation01". (Same as cloud director admin)

But what must i choose as Organization on the vCloud Plugins credentials if i

have to configure the cloud system admin?

The cloud plugin inventory is browsable. (see attached image)

best regards,

Mike

[cdecanini_]

You must use the System Organization to have access to the needed Admin extensions. On your screenshot you do not have the Extension folder under Admin because you are connected as an Org tenant.

I should definitely edit the doc to mention the vCD plug-in must be set up with the System org.

Christophe.

[mschubi]

Hi Christophe,

that was the problem.

for all others: the inventory should have this items:

Thanks a lot for the quick response...

Mike

[mschubi]

the best is to view the video on

http://www.vcoteam.info/learn-vco/vcloud-director-blocking-tasks-and-notifications-integration-with-...

before starting 😉

best regards,

Mike

[khensler]

Chirstophe,

I'm having a problem with this during the "Configure vCloud Director AMQP subscription" workflow.  It errors out saying "Unable to set custom property, reason: null."

Any help?

[Burke-]

This sounds like you may have upgraded your vCO server from a previous version to version 4.2.1, is this correct? If so, please call GSS. I think they have information regarding this issue with Custom Properties after an upgrade. If this is a test server and you can easily just spin up a new 4.2.1 server, that may be easier

[khensler]

That was it.  Reinstalled everything and its working now.  Thank You!

[UofS]

When working through the video and reaching the calculation of the routing key I find that it in not populating the filter routing key  field?  The workflow obviously failes due to this.

[Burke-]

When did you download the package? I came across this issue and thought that an updated package had been uploaded here.. Please re-download the package and do an import - see if any of the elements are newer (During import, you should ideally see one or more GREEN arrows indicating updated elements.)

[UofS]

redownloaded and reimported and selected ALL checkboxes and still find the routing key is empty. Are there specific logs I can see to see if there is something failing?

[cdecanini_]

Are you using vCO 4.2.1 by any chance ? Patches were issued as there are issues with workflow presentation fields in this version.

[UofS]

Yes.  I am running 4.2.1.  I have looked on the vmware site and cannot find the patches you are referring to.  Are they downloadable or by request only?

[cdecanini_]

Hi,

Find the patches and instructions in this thread

[UofS]

Applying those patches seems to have worked.  Now I am getting the

Error Message: Unable to set custom property, reason : null

Per the previous message I will attempt to call GSS or reinstall vCO.  It is on my vCenter Server but I assume I can just remove and install the vCO component.

What will be faster?  Calling GSS or reinstalling?

d

Would it be better to use the Appliance instead going forward?

[cdecanini_]

I think I know this issue. You certainly did an upgrade to this vCO version.

If you reinstall a new vCO 4.2.1 and apply the patches you will not have this issue. If you do not want to reinstall there is a SQL script to fix the issue that was broken by the update.

[UofS]

Yes - this is the KB article that GSS also referred me to (in record time I might add!)

It has worked.  thanks.

[UofS]

I was able to continue but when find this error in the approve app workflow.  It appears the "null" message has returned in these logs:

[2012-05-09 17:53:19.569] [I] DynamicWrapper (Instance) : [VclXMLGregorianCalendar]-[class javax.xml.datatype.XMLGregorianCalendar] -- VALUE : 2012-05-09T16:52:02.070-04:00
[2012-05-09 17:53:19.569] [I] vCO server offset is GMT6
[2012-05-09 17:53:19.569] [I] blockingTaskCreatedTimeDate : Wed May 09 2012 14:52:02 GMT-0600 (CST)
[2012-05-09 17:53:19.569] [I] newBlockingTaskTimeOutDate : Sat May 19 2012 14:52:02 GMT-0600 (CST)
[2012-05-09 17:53:19.569] [I] Actual timeout date : DynamicWrapper (Instance) : [VclXMLGregorianCalendar]-[class javax.xml.datatype.XMLGregorianCalendar] -- VALUE : 2012-05-14T16:52:02.070-04:00
[2012-05-09 17:53:20.334] [I] newBlockingTaskTimeOutDateSet : DynamicWrapper (Instance) : [VclXMLGregorianCalendar]-[class javax.xml.datatype.XMLGregorianCalendar] -- VALUE : 2012-05-14T16:52:02.070-04:00
[2012-05-09 17:53:20.444] [I] TypeError: Cannot read property "name" from null (Workflow:Approve vApp (AD:Computer) / get scaffold vApp details (item7)#14)

Do I need to start this from scratch?

I see line 14 (assuming #14 means line 14) says:

var userRole = vcdHost.getEntityByReference(VclEntityType.ROLE, user.role).name;

[cdecanini_]

No, it may just be that your settings for blocking the task are timing out too quickly. Change the settings in vCD and try with new vApps.

[cdecanini_]

Or that for some reasons the user role was not defined. If the problem persists you may want to comment this line to test.

[UofS]

You were correct.  It was because I was inadvetantly connected as the System Admin not the Org Admin.

[GHUser911]

Hi and thanks for that, any idea why I'm getting two emails on every vApp Instantiate ?

It seems like the Approve vApp workflow is running twice , one time it's finished succesfully (after the aproval), and the second time it's idle  (waiting for the approvment again).