What’s in a name?

“O! be some other name:

What’s in a name? that which we call a rose

by any other name would smell as sweet”

From one of my favourite plays, rendered in somewhat recent times in superb fashion IMHO, by one of my favourite directors (a fellow Aussie and New South Welshman by the way:-).

The naming gods must have finally read “Connecting UrbanCode Deploy with Patterns to OpenStack” and decided the UrbanCode Deploy with Paterns (UCDP/UCDwP/UCD+P..) name is indeed a mouthful.  Mouthful or not, Eric Minick provides a bit more detail on  UCDwP becoming part of UrbanCode Deploy with the 6.1.2 version in his post . Problem solved indeed and does make perfect sense as I’ve been finding when showing UCDwP to customers moving into the cloud over the past year or so. For simplicity I’m just going to call the cloud blueprint capability the “Designer”.

The name change is only one of many changes since I last wrote about UCdwP late last year. You can read all about the significantly enhanced capabilites on the UrbanCode microsite on IBM developerWorks.  Out of that pretty long list here are my favourite or most useful enhancements, in no particular order:

  • UrbanCode Deploy agent packaging is better

    The way the UCD agent is auto-magically installed via a compute resource’s user_data is now much more transparent. Probably makes no difference for those who haven’t used versions prior to but here’s what the cryptic script looked like:
    userdataDeciphering that wasn’t too bad but modifying the installation couldn’t be done without some trickery – like figuring out what the generated script content was, manipulating it and hoping for the best. The generated install script now looks like this:
    newuserdataA more subtle but significant change is in the fact that the new install script isn’t an embedded part of a compute resource’s user_data but is actually a OS::Heat::SoftwareConfig resource invoked by the compute resource via a OS::Heat::MultipartMime resource part. Gobbledygook, say you? Nay, say I. The change means that the compute resource can have other stuff done to it by other OS::Heat::SoftwareConfig resources. Like so:

  • Installing is simpler, Keystone included

    The install processes for both the Heat engine (with UCD extensions) and the Designer is simpler now: the Designer doesn’t require Internet access for any packages and the engine lists its initial dependencies when running the installer.
    In addition if you wish to only provision to AWS and/or VMWare or can’t/don’t want to use an existing Keystone service for identity management, the engine installation can set Keystone up for you.

  • Retrieving Component Versions and Processes

    I’ve lost count of the number of times I’ve felt silly because I’ve named the default component process in UCD “install”, provisioned a blueprint with the component in it and wondered why it didn’t work as expected. The Designer defaults the process name to “deploy”. When a component has multiple processes it was also a bit painful to get the name right. Same deal for the version labels.
    With the latest version of the Designer I can now select the version and process directly from the component.

  • Keeping up to date with provisioning progress

    With previous versions I used to have to switch between the Designer, the UCD UI and the cloud provider UI to figure out where things were at. This was especially annoying when provisioning multiple resources and multiple UCD components. Now almost all of the progress information I need is in one place in UCD.
    When the provision is initiated, the UCD Dashboard page shows the provisioning progress as the progress of an Application process :
    ucddashSelecting the Details link takes me to , well, a detailed, consolidated, hierarchical view of all the resources and what’s happening to them:
    processdetails01processdetails02If I want the system log for any of the compute (server) resources, I can get that too from here by clicking the little Output Log icon next to the the server resource:



  • Editing HOT YAML is easier

    Take this blueprint for example:
    xnilbpThat’s close to 700 lines of YAML in the HOT document that is generated by the Designer – not including *any* of the software install parts, which in this case are delegated to UCD. Sure there are YAML parsers/validators and the like that can help improve productivity a little, but having Designer actually connected to the target cloud (OpenStack, AWS, VMWare, SoftLayer) and validating a whole ton of stuff behind the scenes is invaluable, particularly when designing and changing complex blueprints. And that’s not even touching on “minor” features like content assist when working in the source view.

So just a taster of some of the good stuff in the latest version of the UrbanCode Deploy Designer component. For all the details visit the Knowledge Centre, the YouTube playlist or the IBM developerWorks microsite.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s