I've successfully gotten the com.vmware.coe.vcd51.notifications.package update package working with vCO 5.5 and vCD 5.5. After setting up the "Create a vCloud Director notification subscription" to trigger on "instantiate vApp from template" i can now run a specified workflow in vCO.
I need to use a custom IPAM using a REST API which i've found plenty of documentation/examples on how to do, however what's not so crystal clear is the rest.
I've been studying the examples that come with the notifications package, and also the com.vmware.coe.vcd51.vapp.customdeploy.package workflow which would have suited perfectly if only it where meant to be triggered by AMQP blocking tasks.
1. i get a blocking task in a queue through the AMQP which is cought by a listener workflow. It seems however whats actually getting executed is the statically configured workflow "Workflow runner" that does some magic and then triggers the workflow i specified. When looking into "Customize VMs name and IPs" workflow it seems that the first thing it does is resume the blocking task, i assume this should trigger vCloud to continue to create the vApp, and then the workflow should receive a new blocking task once this is done to do the modification?
Is this how it's designed to work, that customization is done post-deployment instead of pre-deployment? I've tried to set the Customize VMs name and IPs as the destination workflow from the notification subscription but it generates 6 failed workflows in a row each time with various errors. ( 2014-03-11 14:31:55.125] [I] TypeError: Cannot call method "getTask" of null (Workflow:Customize VMs name and IPs / Resume Blocking Task (item8)#2) ) Is this workflow supposed to be called from another workflow or directly from the notification subscription?
2. What are good resources to study to be able to create such a workflow?
3. Does anyone have a workflow they can share that one could build on, or that might be clear and simple on how to work with blocking tasks?
the notifications package has multiple samples that you can use to get familiar. I found typically they don't always meet your internal requirements.
basically what happens is as you suspected.
VCD creates the BT and drops a message on the Rabbit MQ server. This server is configured with a routing key which then delivers the message within Rabbit to the respective AMQP queue.
The routing key is a somewhat poorly documented part of the process (anywhere not just the notifications package) I will endeavour to blog this detail this weekend. I keeping seeing similar posts so I may as well solve that once and for all.
Basically what happens is VCD attaches the routing key which then routes that message to a queue within AMQP.
VCO then monitors various queues and performs an action based on either the queue itself or information within the message that can be used to manipulate behaviour in the workflow itself.
Out of the box the notifications package runs the workflow running first which does a bunch of scaffolding work which gathers information within the messages and converts that to usable VCO data.
Once the workflow running starts you will notice a few very important bits of information in the workflow token.
The type of BT you setup in VCD will determine the routing key and therefore the respective AMQP queue that should receive that message.
After the message is received the workflow running will instantiate a "workflow runner" workflow instance
this will in turn instantiate a "desired workflow" workflow instance. (this is specified in the workflow attribute)
I would recommend to start with do a very simple "instantiate vApp" with approval scenario. As this introduces the least amount of moving parts to test the full cycle. From there start to modify accordingly what you need.
The example you are referring to is I assume "Customize VMs name and IPs" the process within that is deploy a vApp which is likely to have start params passed to it.
From there it is iterating the machines within the vApp and doing the renaming setup.
From the limited detail I have of what is going on I would expect that the task parameter is not correctly set / received in the workflow runner workflow. Check a workflow token for workflow runner to determine if the task is configured with a value.
one other bit of info that might be useful. Is how the queues are configured in AMQP is quite important.
Typically the queue should be configured as a topic queue which to cut a rather long story short means that it will be routed based on the information in the routing key as described earlier.
If you dont have the correct queue you might find messages are getting lost before you process them..
actually on 2nd thoughts try the log all workflow first its much simpler. I did also notice one version doesnt work ./
From what i can understand my queues should be setup correctly.
I actually tried using the notification package to set this up, however since we're using vCO 5.5 and vCD 5.5 it wouldn't work because it couldn't set the routing key via Server.SetCustomProperty. Vmware managed to solve this by nesting that one cmd in it's own workflow and calling that workflow from the original workflow.
If i setup the "Create a vCloud Director Notification Subscription", only filtering on the blocking task (select No on everything else), and then start a Subscription Listener and point it to "Log All" workflow it populates the log with data:
[2014-03-12 09:59:00.956] [I] operationSuccess (type = boolean, value = true)
[2014-03-12 09:59:00.957] [I] taskOwnerVApp (type = vCloud:VApp, name = vApp_system_22, URL = https://company.se/api/vApp/vapp-35377c5e-3280-4505-bfca-0f70ffbad1c8)
[2014-03-12 09:59:00.958] [I] entityTask (type = vCloud:Task, name = task, URL = https://company.se/api/task/61a1662a-96e3-4efb-9561-c59871e295c0)
[2014-03-12 09:59:00.959] [I] user (type = vCloud:User, name = administrator, URL = https://company.se/api/admin/user/9ba4c1c7-8e4d-4fb3-8e99-c2978cdae0ec)
[2014-03-12 09:59:00.960] [I] organization (type = vCloud:Organization, name = demo, URL = https://company.se/api/org/21b4acee-7ae4-4156-82f2-a01065b74d20)
[2014-03-12 09:59:00.960] [I] notificationType (type = vCloud:EventType, value : com/vmware/vcloud/event/task/create)
However if i check the "Variables" it doesn't seem to set the "blockingTask" variable. while reading the examples that are included it seems that most workflows that do any kind of block or interaction have two inputs into the Workflow.
vApp (type: vCloud:vApp)
blockingTask (type: vCloud:BlockingTask)
As i previously stated i think i need to "release" the blocking task at one point or another, However since "log all" doesn't see the task i'm guessing;
- Somethings gotten lost in the process and i should be seeing a BT variable.
- The "Workflow Runner" is handling this with some kind of black magic and i shouldn't be too concerned.
- this is handled some other way.
I also tried to run the workflow "Approve vApp Simple" which also stated:
2014-03-12 10:33:03.166] [W] No blocking task !!!
[2014-03-12 10:33:03.797] [I] 1 VM records found
[2014-03-12 10:33:03.835] [I] orgAdminApprovals: false
Any help/guidance on this would be much appreciated.
I am not sure I fully understand your goal here. You are certainly on the right track for what it seems like you are doing.
Is your goal here to Deploy a vApp and customise the vm names and ip addresses? There are numerous ways to look at this problem with vCD involved. It does depend heavily on your actual target as to whether some of those options will fit your requirement without the complex orchestration.
If you are simply trying to achieve cloning a couple of machines then you can do that without the ip customisation using internal fencing options. Fencing is however someone dependant on certain scenario's that you may or may not meet.
If this is just cloning a couple of non domain connected boxes, I would say forget the option to customise and just turn on the fencing in the network setup then be done with it. If they are domain joined then there are some issues some places forsee as problematic using this approach and then look to what your doing now.
so taking a step back from the picture what is the end goal of this?
to understand BT?
or to deliver clones of guest operating systems etc?
The end goal is for users to be able to deploy vApps directly connected to the org network, however with a pre specified naming convention, and IP's checked out from a proprietary http rest IPAM.
Everything points to having to have experience with AMQP since this involves blocking tasks.
sorry i got busy for a bit, I assume you have already sorted this.
but you could certainly use the "power on vapp" and "power off vapp" options to generate a blocking task,
from there trigger a workflow that uses REST to hit your proprietary setup. I have done a similar thing in my environment using this method. not to get IP data but to update an environment repo using rest for newly generated vApps
if you still have an issue let me know and we can progress this further.
Sadly this project has been at a standstill but we got help from another consultant today and workflows are now able to be executed, and blocking tasks resumed. I'm now going to try do the ip modifications.
I'm still however missing a lot of valuable information on how this is actually supposed to work, so if you have the time i would very much like to read what you intended to write.