UrbanCode Deploy with Patterns and its Integration with UrbanCode Deploy

Well it has been quite a while since I have posted and lots has happened in the past 3 months. The re-organization of IBM has caused some internal shakeup but I have landed in the Cloud group which still is the home of the IBM DevOps solution. So I get to keep my current trajectory. With that though I have tried to expand my horizons and learn some new things. I have started to look at UrbanCode Deploy with Patterns more closely. It will play a key role in the IBM Cloud software offerings and will be the center point of HEAT document editing.

To back up a bit, HEAT is the OpenStack project focused on orchestration. The mission of the OpenStack Orchestration program is to create a human- and machine-accessible service for managing the entire lifecycle of infrastructure and applications within OpenStack clouds. In other words, HEAT provides the ability to define full stack application definition in a human readable artifact. The HEAT engine then reads the artifact and farms out the necessary tasks to other parts of the Cloud infrastructure to fulfill the parts as defined in the artifact.

UrbanCode Deploy with Patterns (UCD+P) provides a rich editor that allows you to craft HEAT documents in a visual way. It also defines some custom extensions to HEAT that allow some additional capabilities that are necessary to provide full stack functionality. Let’s examine in more detail.

UCD+P provides extensions that allow you to assign components from UrbanCode Deploy (UCD) to nodes in the blueprint. The component drawer of the resource pallet provides the list of components available to the user that can be applied to nodes.


The entries in this drawer come directly from the UCD integration. The first time you drag a component onto the blueprint canvas you are presented with a dialog. This dialog is to confirm the application that you want to associate to the blueprint. In UCD you will end up with a new environment of the application you choose once the blueprint is provisioned. Remember that components can be included in more than one application and therefore this dialog allows you to choose which one.





Here is a picture of a node after a few components have been assigned to a node.


Now let’s switch over to the blueprint source view and take a look at the UCD information that is included. First we see the blueprint parameters. Notice the UCD values that are necessary when provisioning the blueprint.params


Next we can look at the component information. We see two different resources defined. The war file deploy component defines the type of server it is being installed on. The version property is important. UCD+P defaults to the LATEST component version. This is fairly unrealistic. There are most likely a limited amount of scenarios where the LATEST version of all components are installed. More likely would be a snapshot. Unfortunately as of the writing of this post there is no capability to specify a snapshot name. This would be easy to add to the “choose an application” dialog since snapshots are associated with applications. This will be my first UCD+P enhancement request. I encourage anyone reading this to also chime in on this RFE.

A few other details to note are found in the component configuration resource. Here we see the name of the component and the component process to use. Note that the process name defaults to “deploy.” I believe it assumes you will have a process named “deploy.” You can change it to something else if you want to use another defined process. This again would be easy to add to the user interface when dragging it onto the blueprint canvas. But this one isn’t as critical as users typically define a default deployment process named “deploy.” Also note the input property that is required (JKE_DB_HOST). This is defined in UCD as a component environment property and is picked up via the UCD integration. It is not clear if, for example, I have a process property that is required or some other property whether those will be picked up as well. Note that this property can be associated with a UCD+P property that is then gathered at provision time.



The UCD+P integration to UCD is very powerful and these HEAT extensions allow us to define both storage, compute, and networking information along with UCD component info in the same blueprint making this a true full stack artifact.

Now I am sure you can image some things that are missing in this picture. I will give you some hints. First, it looks to me in the example that I have shown that the middleware installation (and non-application configuration) is being performed by UCD. I am not sure this is the best place to perform this type of task and maybe there is a better way to do it. Also, it won’t take long in talking with an operations team some additional activities that are necessary in a production “Go Live” scenario. Stay tuned to some additional posts on things coming down the pike to fill in some of the gaps in the full stack picture.


One thought on “UrbanCode Deploy with Patterns and its Integration with UrbanCode Deploy

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s