An NFV Customer Use Case on Creating Custom Workflows With Cloudify and TOSCA

Recently, I worked with a prospect in the NFV domain who had quite a complex topology. They wished to orchestrate with TOSCA in an environment that included dozens of different VMs with different roles. In addition, there were many different networks, and some of the VMs had multiple ports on different networks.
When we discussed the use case, the prospect was looking to define a “complete” topology blueprint, but instantiate it in steps, or rather, be able to control which subset of nodes will be created and installed, and later, build on top of it and deploy an additional subset of nodes.

Intelligent NFV orchestration for any telecom environment. Download today. Go

Cloudify’s built-in “install” workflow traversed the entire topology and instantiated the nodes based on the dependency graph implied by the blueprint. This fits many use cases, but was not a good fit with this prospects specific use case.
Cloudify lets you express such workflows with its custom workflow feature. Custom workflows are implemented using plugins, typically in python. Cloudify injects into these custom workflow methods a context that gives the workflow developer a handle to the blueprint topology and allows the developer to traverse the nodes and their relationships.
Pleased with the good fit between the requirements and custom workflow functionality, we went on to define the specific workflows we would need:
Install_subset(subset_name, nodes, install_dependencies=True)
This takes a list of nodes and checks dependencies to make sure they are not dependent on nodes that are not running. If there are such nodes, it will either start them by default as well install_dependencies=True or fail the workflow during validation phase due to unmet dependencies install_dependencies=False.
The nodes that were started will be tagged with the subset_name parameter.
Uninstall_subset(subset_name)
This takes a subset_name for a subset that was installed with the “Install_subset” workflow, checks dependencies to make sure that by uninstalling the subset group of nodes, no dependencies are left unmet for running nodes afterwards (i.e. if node A is connected to node B and node B is about to be uninstalled by the workflow, if node A is not in the subset of nodes for “uninstall”, the workflow will fail – node A can run without node B).

The implementation code is quite straightforward. It first validates the dependencies, then uses the lifecycle “install” operation to get the subset installed and, finally, tags the affected nodes with the subset name that was given:

In order to use a custom workflow, a plugin.yaml file with the plugin declaration and pointer to the plugin archive has to be imported for the blueprints that want to add the “install_selective:” and “uninstall_selective:” subset workflows. No other change is needed.
After going through the implementation and starting to use the new custom workflows, I think they can be quite useful for other use cases, too. Who knows, maybe one day we will include them as built-in workflows without the need to import anything.