leaseSettingsSection = currentVapp.getLeaseSettingsSection()

System.log("Updating runtime lease for vApp: " + currentVapp.name + ". Current lease is: " + leaseSettingsSection.deploymentLeaseInSeconds)
System.log("Updating storage lease for vApp: " + currentVapp.name + ". Current lease is: " + leaseSettingsSection.storageLeaseInSeconds)

newDeploymentLeaseInSeconds = currentVapp.parent.parent.toAdminObject().settings.vAppLeaseSettings.deploymentLeaseSeconds
newStorageLeaseInSeconds    = currentVapp.parent.parent.toAdminObject().settings.vAppLeaseSettings.storageLeaseSeconds

leaseSettingsSection.deploymentLeaseInSeconds = newDeploymentLeaseInSeconds
leaseSettingsSection.storageLeaseInSeconds    = newStorageLeaseInSeconds

var task = currentVapp.updateSection(leaseSettingsSection)

Using vCenter Orchestrator with RabbitMQ and vCloud Director – Part 5

Posted: November 7, 2014 | Author: Chris Greene | Filed under: vCO | Leave a comment

Overview

In this post we will create the workflow that will run when vCD sends a message to the AMQP server.  At the end we will see the data that vCloud passes to the workflow.  We will simply print out some of this data, but this info can be used in many ways.  For example, it could be used for a provisioning process that performs various tasks such as creating a computer object in AD, creating an IP/DNS entry, registering the VM in a configuration management tool, etc.  This is what we do in our private cloud.  Users log into vCloud Director, select their VM and from there vCO talks to all the necessary components to get the VM ready for the user.

Configuring the Workflow Runner Workflow

From anywhere within the vCO client, right-click a folder and select New workflow:

Provide the workflow a name:

After you press OK, you’ll be on the Inputs page.

1. Select the new parameter icon (right-arrow with plus sign)
2. Select arg_in_0
3. Enter organization
4. Press OK

Now we need to set the object type of our organization attribute.

1. Select string
2. Enter organization
3. Select vCloud:Organization
4. Press Accept

Repeat for the vapp, user and blockingTask attributes.  It should look like this:

Select the Schema tab and drag a Scriptable task object from the Generic group onto the blue line between the Start and End elements:

Select the IN tab and select organization, vapp, blockingTask and user:

Click on the Scripting tab and enter the following in the scripting field:

You should be able to press Save and close and not receive any errors.

Now we can configure the Workflow runner workflow to call the workflow we just created.  You can easily find the workflow by:

1. Entering Workflow runner in the search box in the upper-right corner of the vCO client.
2. Select the highlighted workflow
3. Select Go to selection
4. Select Close

Edit the workflow and on the General tab under attributes we want to set vcdHost and wf.  Here we can see that they are both not set:

Select Not set for the vcdHost attribute then

1. Double-click vCloud Director to expand it.
2. Select your vCloud Director host.  Mine is vcd55.vmware.local
3. Press Select

Select Not set for the wf attribute then

1. Enter the name of our test workflow.
2. Select it
3. Press Select

It should look like this:

We need to make a quick change to make sure the vcdHost and wf attributes get passed correctly.  I’m not sure why this needs to be done.

1. Click the Schema tab.
2. Select the Retrieve message object.
3. Select the Out tab.
4. Select both the vcdHost and wf parameters and delete them.

It should look like this:

 

You can now save and close.

Back to vCloud Director

If we’ve done everything correctly up to this point and we start a vApp in vCloud Director, the Workflow runner workflow should run and then start our vcd Test workflow.  Here we can see see that the Workflow runner workflow ran successfully.  You can also see some data is was able to parse from the blocking task:

We can see the same thing with the vcd Test worflow that we ran.   We simply display a few attributes and resume the blocking task, which tells vCloud Director that it can continue with starting the vApp:

---

Using vCenter Orchestrator with RabbitMQ and vCloud Director – Part 4

Posted: October 28, 2014 | Author: Chris Greene | Filed under: vCO | Leave a comment

Overview

In this post we are going to install the vCloud Director Notification Package, subscribe to a RabbitMQ queue and then configure vCenter Orchestrator to monitor to the newly created queue.

Installing the vCloud Director Notification Package

The vCloud Director Notification Package has various workflows, actions, etc that will allow us to parse AMQP notification messages from vCloud Director and act on them.  By avoiding this heavy lifting, we can focus on using the parsed values in our workflows. Go to https://communities.vmware.com/docs/DOC-20446 and select the download link for com.vmware.coe.vcd55.notifications.package.zip. Unzip the archive and you’re left with a file named com.vmware.coe.vcd55.notifications.package.

From the the vCO client:

1. Select Administer from the drop-down menu
2. Select the Packages tab
3. Select Import package
4. Select the file com.vmware.coe.vcd55.notifications.package
5. Select Open

Select Import on the following screen:

I’ve already imported the package so there is nothing selected, but you should have a lot of items with green arrows that will be imported:

Once the import is finished, you’ll see a new package with various workflows, actions, etc:

 

Subscribing to a RabbitMQ queue

In the vCO client go to the workflow tab and then Library > AMQP > Configuration.  Right-click the Subscribe to queues workflow and set select Start Workflow. Give the queue a name and select Next

Select your broker and click Next.

Select Not Set and enter the name of your test queue in the in the New value field.  Once you’ve entered your queue name select Accept.

My Queue section looks like:

Press submit and it should complete successfully:

 

Creating a new policy

Here is where we will create a policy that will tell vCO to monitor a RabbitMQ queue for messages and to run a workflow when a new message is found.

1. Select the Run menu
2. Select the Policies tab
3. Create the new policy

Edit the new policy:

1. Select Add policy element
2. Select AMQP:Subscription
3. Press OK

Type the name of your queue, select it and press Select.

Select the AMQP:Subscription line and then select Add trigger event.

Select OnMessage and then Select Trigger.

It should now look like this (not sure what’s up with the blue background):

Select OnMessage and below you will notice that no workflow is set.  Click on the magnifying glass to search for a workflow to run:

Select the highlighted workflow:

Once you select the workflow you’ll notice that you have two new parameters that are not set:

Click on not set for subscription and then select the highlighted entry below:

Now do the same for messageBody:

The result should look like:

Start the policy by right-clicking on your policy and selecting Start policy. 

The policy should now have a green arrow on it:

In the next post we will configure the workflow that will run when a new message is found.

---

Using vCenter Orchestrator with RabbitMQ and vCloud Director – Part 3

Posted: October 8, 2014 | Author: Chris Greene | Filed under: vCO | Leave a comment

Overview

In this post we are going to use vCO to create a RabbitMQ broker, exchange and a queue.  We will then bind to the queue so that we can send messages to the queue and retrieve them.

Adding a Broker

In the vCO client go to the workflow tab and then Library > AMQP.  Right-click the Add a broker workflow and set select Start Workflow. Give the broker a name and select Next.

Fill in the RabbitMQ host, leave the virtual host as / unless you want to change it and know what you’re doing.  The credentials are guest / guest.

If the workflow is successful, you will see:

Declaring an Exchange

In the vCO client go to the workflow tab and then Library > AMQP.  Right-click on Declare an exchange and select Start Workflow.

1. Select Not Set and browse to your broker
2. Expand AMQP and select your broker
3. Select Select

Press Next and enter the following:

Press Submit and if it completes successfully, you’ll see a green check.

If you go to your RabbitMQ web interface, you’ll see the exchange we just created:

Declaring a Queue

In the vCO client go to the workflow tab and then go to Library > AMQP.  Right-click on Declare a queue and select Start Workflow.

Select your broker as before:

Fill in the following info:

Select Submit and you should get a green check if the workflow completes successfully.

In the RabbitMQ web interface we can see the new queue:

Binding to the Queue

In the vCO client go to the workflow tab and then go to Library > AMQP.  Right-click on Bind and select Start Workflow.

Select your broker and select Next:

Fill in the following and press Submit.

The routing key is “true.*.*.*.com.vmware.vcloud.event.blockingtask.create.vappDeploy”.  See Notification Message Format for more information on this. Once we have blocking tasks in vCloud set up, every time a vApp is deployed, a blocking task will go into this queue.  Now if we click on the queue in the RabbitMQ web interface, we will see the new binding:

Sending a message to the queue

In the vCO client go to the workflow tab and then go to Library > AMQP.  Right-click on Send a text message and select Start Workflow.

Select your broker and select Next:

Fill in the following and select Next:

Type in a message and select Submit.  Sometimes here Submit isn’t highlighted so you have to press Back then Submit

Back in the RabbitMQ web interface we see that a new message has arrived:

We can also scroll down to the Get messages section and press Get Messages.

Here we can see our message.  Set Requeue to No so that the message is removed off of the queue.

vCloud Director Configuration

Let’s do something a little more interesting and configure vCloud Director (vCD) to send messages to RabbitMQ when a vApp is deployed.  From the vCD portal, enter the following:

Configure the blocking task:

1. Select the Administration menu item
2. Select Extensibility
3. Check Start vApp (Deploy from API)
4. Press Apply

Go ahead and start any vApp.  You’ll see the status change to Pending processing…

This time the payload has a lot of vCD related information such as the ids for the org, user, etc of the vApp that was attempted to be deployed:

You could work with this data in the current format, but it’s much easier to use the vCD Notification Package.  This package will extract all the details from the blocking task and populate variables such as user, org, org vDC, etc.  It also allows you to run vCO workflows where you can use the data that was extracted out of the blocking task to do whatever you want.  For example, you could add the deployed system to a CMDB, call out to Infoblox to update the DNS, etc.  You probably want to use a different blocking task (vApp creation) type for this however.  There are two different types for creating vApps.  I’ll cover the vCD Notification Package and creating RabbitMQ subscriptions from vCO in the next post.

 

 

 

---