TOSCA Service Modeling With REST API For Non-Programmers

.gist
.gist-file
.gist-data {max-height: 400px}

REST API has become the most common method for system integration these days. The majority of controllers, managers, and even network elements expose their services via REST API as it provides substantial benefits over traditional CLI scripting. There are tons of programming frameworks and libraries to interface with REST API – however, what if you’re not a programmer? Or perhaps you are but you’re looking for some way of fast prototyping your idea?
The intent of this blog is to demonstrate how service architects can use Cloudify Manager to interface with REST API in order to model service intent without the need to write code – you only need a TOSCA blueprint.

Watch our upcoming Cloudify 4.2 webinar to see what the new version is capable of!   REGISTER NOW

In order to interface with external systems, Cloudify Manager uses plugins. It’s the plugin that delivers the various types and interfaces to the TOSCA blueprint in order to model service intent. Plugins have obvious benefits and some drawbacks. They provide a lot of flexibility for modeling the object and service intent as we have full control over the code we’re developing. We can turn every complex system into a model and, at a later stage, assemble it through TOSCA grammar into service intent. Unfortunately, this comes at the cost of time and effort needed to develop the particular plugin.
This is one of the reasons why Cloudify decided to incubate the Utilities Plugins. This group of plugins provides methods for most common scenarios and processes that we see during integrations most often. For example, we created a the Cloudify Terminal plugin, which is a standard way to interface with a CLI-based system, along with many other utility plugins like Cloudify Deployment Proxy and Cloudify Configuration.
Based on a similar concept to the terminal plugin, we also developed a REST plugin which is a template-based mechanism to interface with our REST-based API system. Without any programming knowledge, service architects can develop TOSCA blueprints which interface with the REST-based system. All you need to know is REST call format, which can be found in and good REST API documentation.
In order to better explain how this works, let’s look at an example where the REST plugin is leveraged to provision F5’s BigIP VE.
This is a very simple blueprint which models the baseline configuration of BigIP VE. There are only 3 nodes in this blueprint: token, baseline_config, and baseline_networking with a topology dependency model. The file structure is as follows:
..
f5-baseline-blueprint.yaml
templates
 get-token-template.yaml
 baseline-config-template.yaml
 baseline-networking-START-template.yaml
 baseline-networking-STOP-template.yaml

Baseline Blueprint

f5-baseline-blueprint.yaml:

The first node, labeled token,will hold information in its runtime properties about the token for authentication purposes (as you can see in blueprint above, two other nodes have the “get_attribute” intrinsic function in order to query the model for token value). It’s important to note the use of TOSCA relationships. As you can see, we can steer the flow of the execution, avoiding a race condition and making sure that the node token will be established first.

Node token, once instantiated, calls the start interface – and this is where REST plugin is showcased. As you can see, we’ll leverage “get-token-template.yaml” – the place where we use REST calls.

get-token-template.yaml:

There are two important things to note here:
       1. REST calls are represented by a list, meaning we can have more than one, which will be presented later on.
       2. The template is powered by JINJA, which means that we can parameterize it in a very flexible way.
What happens here is the following:

• We send a POST request to F5 BigIP VE
• The response is being put in node’s runtime properties under a “token-content’ key

Once the node is instantiated we can query it’s runtime properties by running cfy node-instances get token_...

Configuration Blueprint

Let’s move to baseline_config node, where we’re using several REST calls during node instantiation.
baseline-config-template.yaml:

Once the node is instantiated, we can query it’s runtime properties the same way. As we can see, there are 4 keys, each holding a response from the relevant REST query (dnsstate, ntpstate, savestate, global-settings):

Baseline Networking Configuration

The last node represents baseline networking configuration. What’s really interesting and cool about this configuration is that we demonstrate how to use START/STOP interfaces in the TOSCA blueprint which PROVISION and DEPROVISION a service on a device – showcasing the lifecycle management capabilities of TOSCA. Once it’s instantiated, it uses baseline-networking-START-template.yaml to send configuration REST calls and once decommissioned, it uses baseline-networking-STOP-template.yaml to clean up configuration.
baseline-networking-START-template.yaml:

Once instantiated, we can query the node instance to see its runtime properties:

baseline-networking-STOP-template.yaml:

The plugin is currently in the development phase, but we’re excited to share this very early preview to demonstrate how powerful it can be once combined with TOSCA grammar. We’ve already proven its worth in a couple of POC’s and the outcome is really amazing!
So keep an eye out for more on this plugin, and if you’re interested in more details, please feel free to contact us.