Looking to take Nutanix for a free test drive?
Click on the following to see what it's all about:

Nutanix Calm DSL – Blueprint Launch Parameters

Nutanix Calm DSL - Blueprint Launch Parameters

In recent articles I’ve talked a lot about the various things you can do with the Nutanix Calm DSL. The Calm DSL, due to being designed as an SDK, opens up all sorts of possibilities when it comes to automating various types of workflow.

Let’s take automation via API for example. It’s a great way of having complete control over how something gets done, but can be a little daunting for those not familiar with API usage. This is just one way the Calm DSL abstracts a lot of automation complexity away from the user. Today’s article covers how abstraction can be applied to a key part of Nutanix Calm – blueprint launch.

The Blueprint

The blueprint used in today’s article is very simple. The highlights are:

  • A single VM is deployed based on a CentOS Linux image
  • The CentOS Linux image is downloaded from an online repository, if it doesn’t already exist
  • The single VM is booted for the first time, and a number of package installation tasks are run e.g. updating the Linux packages
  • During deployment, three application profile variables can be used to define how various test messages appear in the blueprint’s launch output. The variables are:
    • var1 – A string variable with a default value of “sample_val1”.
    • var2 – A string variable with a default value of “sample_val2”
    • var3 – An integer variable with a default value of 2
    • There is a 4th variable named ENV that is defined on the blueprint’s single VM, but we won’t refer to or modify it in today’s article

Important note: Variables “var1” and “var2” are runtime variables. This means their values can be specified by the user during blueprint launch. “var3” is not a runtime variable and can only have its value altered by modifying and re-saving the blueprint. Please keep this in mind as it will play a part in an upcoming section.

Launching this blueprint using either the Nutanix Calm UI or the Calm DSL, and leaving the variables at their default values, will look like this:

Running Calm application, showing three variables left at their default values

The statement and question being posed right now, though, is as follows:

“I want to set those variable values when I launch the blueprint. How do I do that using the Nutanix Calm DSL?” I’m glad you asked – we’re about to look at that now.

The Options

There are two ways the variable values can be specified at the time of blueprint launch. To begin with, let’s look at the command I used to launch the application above.

calm launch bp HelloBlueprint --app_name HelloApp01 --ignore_runtime_variables

Note: –ignore_runtime_variables is the long version of using -i, often seen in documentation and other articles.

This method accomplishes a couple of key things:

  1. The blueprint is launched as normal
  2. All variables are left at their default values

Now let’s look at the what happens if we omit the –ignore_runtime_variables parameter:

calm launch bp HelloBlueprint --app_name HelloApp02
Omitting the –ignore_runtime_variables parameter

As you can see above, the omission of the –ignore_runtime_variables parameter tells the Calm DSL to prompt the user for the variable values. It does show the defaults that have been already set, but it will specifically pause so that a value can be specified, if required.

For automation purposes, this isn’t ideal as it would likely cause a background task to pause indefinitely, or until some predefined timeout period has expired.

With that in mind, it’s time to answer our earlier question – “I want to set those variable values when I launch the blueprint. How do I do that using the Nutanix Calm DSL?”

Launch Parameters File

Like all commands provided by the Calm DSL, blueprint launch can be run with the addition of a –help parameter. This will run the command and provide context-sensitive help for the command that’s been run. Here’s how we’d do that:

calm launch bp --help

The result will be as follows – I’ve highlighted the important part.

Result of requesting context sensitive help as it applies to blueprint launch

The help text, just in case the image above doesn’t load, is as follows:

The blueprint default values can be overridden by passing a Python file via ‘launch_params’. Any variable not defined in the Python file will keep the default value defined in the blueprint. When passing a Python file, no variables will be prompted.

Help for Calm DSL blueprint launch command

That sounds like something that will do what we need, so let’s look an example of a launch parameters file.

variable_list = [
    {"value": {"value": "hello"}, "context": "HelloProfile", "name": "var1"},
    {"value": {"value": "goodbye"}, "context": "HelloProfile", "name": "var2"},

Earlier in the article, you’ll recall the mention of not two, but three variables. However, I also specified that only two of them, var1 and var 2, are runtime variables. This means that no matter what we do, we can’t change value of the non-runtime variable, var3, without editing and re-saving the blueprint. Even if a value for var3 was specified in the launch parameters file, it would be ignored. Think of this is as a form of protection imposed by Nutanix Calm – an application designer may have a specific reason for allowing a variable to be set by other application designers, but they don’t want the variable to be set by application consumers.

It is important to take note of the “context” field, too. Within Nutanix Calm blueprints, application profiles can control where an application runs (e.g. AHV or public cloud) but also “t-shirt sizing” for an application. This means a variable’s value may change based on a user selecting a “large” or “small” instance of an application. In today’s sample blueprint there’s a single application profile named “HelloProfile”. Setting this field within the parameters file allows the developer to specify an variable’s value for any application profile available within the blueprint.

With all that out of way, how do we make use of that launch parameters file? Before continuing, let’s keep in mind what the default variable values are:

  • var1 (string, runtime) = sample_val1
  • var2 (string, runtime) = sample_val2
  • var3 (integer, non-runtime) = 2

And here is what we want the variable values to be, based on our launch parameters file:

  • var1 (string, runtime) = hello
  • var2 (string, runtime) = goodbye
  • var3 (integer, non-runtime) = 2 i.e. blueprint default

Take a look at the command below:

calm launch bp HelloBlueprint --app_name HelloApp05 --launch_params ./runtime_variables.py

Note: –launch_params is the long version of using -l, often seen in documentation and other articles.

The result of running the command above is an application that “looks” almost identical to the first launch, but we weren’t asked for variable values along the way. In addition, the variable values specified in our launch parameters file were used instead of the variable defaults.

Using the Calm DSL to launch a blueprint along with a launch parameters file

Lastly, here’s how the application appears in the Calm UI. Note that our updated variable values are visible, exactly as planned.

Running Calm application, showing three variables updated with launch parameter values

Wrapping Up

As you’ve seen throughout today’s extended article, the Nutanix Calm DSL has been written to allow total control over variable values defined in a blueprint. Aside from being able to dictate how an application is launched, it also allows the Calm DSL to form part of almost any automation workflow when used along with the –launch_params launch parameter.

Thanks for reading and have a great day! 🙂

Nutanix CALM DSL LAB 1.0


Have you wanted to learn the Nutanix Calm DSL, but haven't been sure where to start?
Check out the Nutanix Calm DSL Lab 1.0 now!