VMware released vCenter Orchestrator 5.5.1

This week VMware released vCenter Orchestrator 5.5.1. While this is not a major new release it contains a lot of new features focusing on making vCO content development easier. Also important is a list of deprecated features.

Protocol plug-ins are now included

The days where vCO was mainly used to automate vCenter are over. vCO integrates with many third party applications using generic protocol based plug-ins. In previous releases you had to find the latest release, download the plug-ins and install these. You will not have to worry about this anymore.

The main plug-ins that are shipped with the vCO platform are SSH, SQL, mail, vCenter. Starting with vCO 5.5.1 they all have been bumped to version 5.5.1[plug-in build number]

Plug-Ins included with vCenter Orchestrator 5.5.1 (that were not in 5.5.0)

  • vCenter Orchestrator SOAP Plug-In 1.0.3
  • vCenter Orchestrator HTTP-REST Plug-In 1.0.3
  • vCenter Orchestrator Plug-In for Microsoft Active Directory 1.0.4
  • vCenter Orchestrator AMQP Plug-In 1.0.3
  • vCenter Orchestrator SNMP Plug-In 1.0.2
  • Dynamic Types 1.0.0 (experimental – requires 5.5.1 U1 build)

NB: vCloud Automation Center uses an older build of vCO 5.5.1 that also include the same protocol plug-ins but also the PowerShell and vCAC IaaS plug-ins. The Dynamic Types plug-in requires the at least the build that was released this week (and likely will require a newer build when released as final).

Tagging

You may already be familiar with tags in vSphere. It is a convenient way to set a key / value property on an object so query can be used to list the objects with specific tags.

vCO 5.5.1 supports at the javaScript and REST API level methods to tag any vCO object with a string from 3 to 64 characters. If you look for “tag” in the API explorer you will notice 16 methods to create, find, query tags.

Tags can be ‘global’ or ‘private’:

  • Global tags - visible by all users.
  • Private tags - visible only by the user created the tag.

Use case example : Find workflows by tag (i.e “remediation”, “presentation”). This is the first step of the implementation. It is likely that newer version of vCO will allow to perform queries from the vCO client but also from the vCO worklfow consumers such as the vSphere web client and vCAC.

Tags set on objects in packages can be exported & imported to another vCO server.

Dynamic Types

The objects you see in the vCO inventory (such as VM, datastores) are the one you can use as inputs of your workflows. These are coming from the vCO plug-ins. They are statically defined by a plug-in developer using the freely available Plug-in SDK. The plug-in developer is typically a software engineer with java / eclipse / web services skills.

The Dynamic Types allow to define new types without installing a new plug-in. Basically the plug-in can be implemented by a System engineer with scripting experience by creating workflows that are creating objects from making calls to the API of the system to orchestrate.

vCloud Automation Center allows you to provision and run day two operations on any service (XaaS) as long as you have a vCO inventory object that you can associate to a service blueprint. With leveraging the Dynamic Types it is possible to create service blueprints for any service that can be orchestrated via an API.

Technically the plug-ins provides workflows to help you author the plug-in:

Once completed creating objects and their relations the inventory will list the types hierarchy:

For each object you define you will need to implement 4 workflows (FindById, FindAll, FindRelation, HasChildrenInRelation). Once completed you will be able to browse your inventory.

Then you will need to implement Create, Update, Delete workflows on each of this objects. The effort for creating such a plug-in is proportional to the number of objects you need to handle. NB: DynamicTypes plug-in released in 5.5.1 this week is in beta quality so developers can start to get familiar with it but is not supported yet for production use.

REST API

There are a few REST API new calls in 5.5.1 One noticeable new features is that you can start a vCO action through the REST API:

  • POST /actions/{actionId}/executions Runs an action with given ID
  • POST /actions/{categoryName}/{actionName}/executions Runs an action with given category and name

You can now delete a folder / category using the REST API:

  • DELETE /categories/{id} Deletes a category with a given ID

And of course the new tagging functionality also provides a REST API so the feature can be leveraged from an external application :

  • GET /tags Retrieves list of tag owners.
  • GET /tags/{owner} Retrieves list of tag created by specific user.
  • DELETE /tags/{owner} Removes all tags created by specified owner.
  • GET /tags/{owner}/{tagName} Retrieves list of tag instance created by specific user.

Expand to folder

If, as a vCO developer, you need to put in a version control tool the content of your package you now have an option to expand a package to a folder.

When you do this all the elements included in a package will be unarchived in their raw XML format so they can be checked in in the versioning system.

Plug-in Configuration API

If you use the plug-in SDK you have now access to facilities that will store the plug-in configuration for you. In previous releases you had to implement saving the plug-in configuration in a file or a resource or a database, use a given format such as XML or JSON.

With using these facilities the configuration will be stored in a vCO configuration element stored in the vCO database making it available to all the vCO nodes. This eliminates the requirement of replicating file based plug-in configuration files across all the vCO nodes.

SDK in Appliance

If you are using the plug-in SDK you now have the ability to leverage a maven repository from the appliance. This repository contains project files and dependencies required to build a vCO plug-in. The instructions are included on the vCO appliance page:

Deprecated features

These features are still available in vCO but will be removed in upcoming releases.

  • vCenter Orchestrator 32-bit client: XP days are over. You will have to use a 64 bit client.
  • vCenter Orchestrator Web Views: You should use the REST API for your custom web design requirements or the vSphere web client for infrastructure operators or the vCloud Automation Center portal for end users.
  • vCenter Orchestrator Simple Object Access Protocol (SOAP) service API: The REST API is the way to go, much more powerful than the SOAP one.
  • vCenter Orchestrator Configuration Interface: This is aimed for the plug-in developers: new plug-ins configuration should be driven by workflows as it is now the case for the VMware authored plug-ins. This allows for example to be able to configure a plug-in from the vCloud Automation Center interface. vCO configuration is now possible through the vCO configuration plug-in.

How to get it

  • You can check the release notes here.
  • You can download vCO here.
  • You can get the vCO documentation here.