MyST: How to get a CLI model from MyST Studio

The work horse for provisioning OFMW domains with MyST Studio is the MyST Agent. When there is something to be executed on hosts, it is the MyST Agent performing that action. MyST Studio is for the modeling of your environment and the Agent is the driving force to actually get it done on your infrastructure.

This post is part of a Series in which Robert Jan de Groot and I explore the inner and hidden parts of Rubicon Red MyST Studio which might come in handy at times.

The ‘communication’ between MyST Studio and the Agent is done through a properties-file and some supporting files, but everything you see in MyST Studio is translated into key-value pairs in the fc.properties file. This file is also known as the CLI model.

This post will enable you to get this CLI model from the API of MyST Studio, which often is a good help in trying to figure out what the issue is if you encounter problems during provisioning.

The CLI model

During and after the execution of a MyST Action on a host where the Admin Server of a FMW domain resides, the CLI model of that Platform Instance can be found on disk.
This location is user defined, and can be found in MyST Studio in both the Platform Blueprint and the Platform Model.

mystworkspace

Each run has a GUID as its ID, and this is also how they are stored in this workspace-base directory. The file also known as the CLI model is called fc.properties and can be found in:

${myst.agent.workspace.base}/<GUID>/conf/fc.properties

Next to this file, there is also a fc_minimal.properties, and this only includes the user defined values. Any auto-computed values are absent from this.
In our experience, the file fc.properties is more valuable as it includes all necessary information and this is also the file used by the MyST Agent.

Accessing the API

The MyST Studio API is the key to the success here, and it can be accessed through its REST API.
Ever since MyST Studio 6.0, Rubicon Red publishes a Swagger definition of the interface, and links to it in their documentation.

We are assuming a Linux client here, with a shell and curl as available tools.

The MyST Studio API requires authentication, and handily supplies a user with the correct access and roles by default. This user is called mystsystemuser, and it has the API User role.

You can find it by logging on as a user with Administrative rights, and by navigating to Administration -> Users. You’ll be greeted with the following screen:
users

To find the API Key, click on the dropdown-icon next to the Edit-button and select Show API Key.
ShowAPIKey

You’ll find something like the below screen:
mystsystemuser

You’ll need this API Key later on.

Also, you’ll need to find out the GUID for the Platform Model you are interested in.
This GUID can be found by viewing your Platform Model in your browser and by copying the GUID from the address bar.

modelguid

Now you’re all set to start using the MyST Studio API!

The below script is ready-to-use, the only thing left to do is to replace the values with the ones you just obtained, and it would look something like this:

#!/bin/bash

export MYST_TOKEN="eyJhbGciOiJSUzI1NiJ9.eyJleHAiOjM2OTM3NDA3NDIsInVzZXJfbmFtZSI6IklOVEVSTkFMLW15c3RzeXN0ZW11c2VyIiwiYXV0aG9yaXRpZXMiOlsiUk9MRV9VU0VSIl0sImp0aSI6IjhkMmI3ZWIzLWMwNzktNDAwOS1iZGJkLTI1OTEwMTk5MzU0OCIsImNsaWVudF9pZCI6ImZ1c2lvbmNsb3VkYXBpIiwic2NvcGUiOlsiYWxsIl19.UKY1ULByLebhn5KLArHcHteFrZRbPGB9PHWh9iOO2SJ8i8Nz5xLFzTrN5fJXnWlDi0rg08uJ5VAkpGUB-7ZcWujIC_wQLYGVRpmHN9C1Td6F2JiRGpZNLEdPCo6tEC-cJ8mFSJeqyxN-W38O2C-zi_mfK5AUMdIsCHn0B6z4WkrBDQgZNo6fD00LZGEiIfEvbVcd82ME46zkhT0XtVF6B_hm9PARNkC2yaOEaTHB-3cBIlc4r9tgaIP1Isd4Tny9_7fPOisrBaGl29Oy3knG1YylIJ-RNSEh05ygPcTTECCEeNMO7STNZ-aTsN7TlDPsJk8Ypd2S-zMcmFLQewanCg"
export PLATFORM_MODEL_ID="6fafeb5a-0bcb-4683-8f57-e287ea7eebaf"

curl -k -s -X GET -H "Authorization: Bearer ${MYST_TOKEN}" "https://localhost/api/v1/platform/models/${PLATFORM_MODEL_ID}/cli-model"

Running it in your shell would yield output like the following:

runmesh

And there you have it! Your very own CLI Model.
This can be used for all kinds of things, among which the “easy” way of comparing Platform Models inheriting from the same Platform Blueprint, and checking out differences between versions of the same Platform Model.

Let us know what you used it for, by dropping by @maartentijhof or leaving a comment below!