Nutanix Calm DSL – Run Custom Actions

In recent articles we’ve covered a few things now. Some of the highlights are:

• Introducing the Nutanix Calm DSL including launching blueprints
• Generating VM Provider Specs
• Creating a custom blueprint from scratch

If you’ve followed the Calm DSL articles up to this point, there’s a good chance you’ll have a couple of blueprints ready to launch and may have an app launched already.

If you want to follow along with today’s article, please ensure you have at least one application running that’s been launched from a blueprint containing custom actions. The articles linked above go through that process in extensive detail.

Collecting App Info

In my dev environment, I’ve already got an deployed with the name LAMP_v4_DSL_12_01. I agree that’s a pretty crazy app name, but it just tells me the application launches a LAMP v4 stack, it’s version 12 of the blueprint and it’s the first time that specific blueprint has been launched.

If we assume for a moment that we don’t know the name of the app we need to work with, here’s how we can list the apps currently in our configured environment.

calm get apps

In the screenshot below you can see I have three running apps in my dev environment, with LAMP_v4_DSL_12_01 showing as the first in the list. The app is running and was launched on March 26th, 2020 at 10:50 a.m.

In a “real” environment, it’s quite possible that we already know the name of our application. In today’s example that is the situation we’re in, so we can use the describe command as outlined in the documentation to do just that:

calm describe app LAMP_v4_DSL_12_01

Looking at the output of that command we can see a lot of information has been returned. We’ll go through this in just a moment.

• The highlighted “Deployments” section lists deployments that have been been run as part of this application. You can see MySQLDeployment, HAProxyDeployment and ApachePHPDeployment that match the three configured services in the LAMP blueprint.
  • Note the [‘running’, ‘running’, ‘deleted] next to ApachePHPDeployment? This shows the status of each replica within that deployment. In the case of the Apache PHP services, the LAMP_v4_DSL_12_01 application was scaled out in the past, and then scaled in again. That means the application did for a short time have three Apache PHP replicas running. One was deleted during scale in, indicated by the “deleted” member of the above list.
  • As a final note, if the LAMP application is launched for the first time and never scaled out, the describe app information above will only show two instances of “running” replicas.
• The “App Actions” section lists the actions that are available to us as part of this app. This list is important in the context of today’s article as it includes ScaleOut and ScaleIn.
• The last important point is that the DSL actually shows us exactly how we can run post-deployment actions. Let’s do that now.

Launching Post-Deployment Actions

Before continuing, there’s an important thing to note. At the time of writing this article, the Calm DSL doesn’t yet support the setting of action variables. This means that our ScaleOut and ScaleIn actions, which do provide a COUNT variable in the Calm UI, can still run but will use the variable’s default value for now. The default value of COUNT is set to 1, meaning the scaling actions can only be in increments of 1 for now. More information will become available if and when this changes.

For today’s article, though, all that is fine as we can scale out our application using the ScaleOut action and don’t need to specify a scaling number to make it work.

The syntax is very simple, just like all commands provided by the Nutanix Calm DSL:

calm run action ScaleOut --app LAMP_v4_DSL_12_01

You’ll see the action has been launched and the runlog UUID has been displayed. If required, –watch parameter can be used so that the DSL will show a dynamically-updating progress log of what’s happening. This includes a percentage counter to indicate the custom action’s progress.

calm run action ScaleOut --app LAMP_v4_DSL_12_01 --watch

Why do this?

At this point it’s a good idea to think about why we’d want to do this in the first place. If we think about why you’d want to control Calm from the command line, it makes sense that the typical actions would be in response to an event. For example, a script that carries out various actions as part of a larger workflow that launches Calm blueprints based on “something” happening. The same workflow could also respond to an application that’s already running and, in the case of this example, scaling out an application in response to increased load requirements.

Of course, there’s no reason at all this is restricted to built-in actions like ScaleOut or ScaleIn. In fact, the article linked above, Creating a custom blueprint, goes into detail on how to add BackupDB and RestoreDB custom actions. These are 100% user-defined and aren’t part of any built-in feature of Calm beyond the ability to add the actions themselves.

Wrapping Up

While this short article only demonstrates a single feature and how to use it, it forms part of the larger workflow mentioned above. Combining the info in the articles up to the point plus the info coming in future articles, the SDK-like nature of the DSL makes command line operation of Calm extremely simple.

Please do continuing following this series as it evolves – there’s much more info to come.

Thanks for reading and have a great day! 🙂