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:
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
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
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.
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
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.
Hi Christophe,
that was the problem.
for all others: the inventory should have this items:
Thanks a lot for the quick response...
Mike
the best is to view the video on
before starting 😉
best regards,
Mike
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?
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
That was it. Reinstalled everything and its working now. Thank You!
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.
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.)
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?
Are you using vCO 4.2.1 by any chance ? Patches were issued as there are issues with workflow presentation fields in this version.
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?
Hi,
Find the patches and instructions in this thread
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?
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.
Yes - this is the KB article that GSS also referred me to (in record time I might add!)
It has worked. thanks.
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;
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.
Or that for some reasons the user role was not defined. If the problem persists you may want to comment this line to test.
You were correct. It was because I was inadvetantly connected as the System Admin not the Org Admin.
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).