Prior to this change we had workflow defined inside python-tripleoclient, and most API calls were made directly to Heat. This worked OK but there was too much "business logic" inside the client, which doesn't work well if non-python clients (such as tripleo-ui) want to interact with TripleO.
To solve this problem, number of mistral workflows and custom actions have been implemented, which are available via the Mistral API on the undercloud. This can be considered the primary "TripleO API" for driving all deployment tasks now.
Here's a diagram showing how it fits together:
|Overview of Mistral integration in TripleO|
Mistral workflows and actionsThere are two primary interfaces to mistral, workflows which are a yaml definition of a process or series of tasks, and actions which are a concrete definition of how to do a specific task (such as call some OpenStack API).
Workflows and actions can defined directly via the mistral API, or a wrapper called a workbook. Mistral actions are also defined via a python plugin interface, which TripleO uses to run some tasks such as running jinja2 on tripleo-heat-templates prior to calling Heat to orchestrate the deployment.
Mistral workflows, in detailHere I'm going to show how to view and interact with the mistral workflows used by TripleO directly, which is useful to understand what TripleO is doing "under the hood" during a deployment, and also for debugging/development.
First we view the mistral workbooks loaded into Mistral - these contain the TripleO specific workflows and are defined in tripleo-common
The name of the workbook constitutes a namespace for the workflows it contains, so we can view the related workflows using grep (I also grep for tag_node to reduce the number of matches).
When you know the name of a workflow, you can inspect the required inputs, and run it directly via a mistral execution, in this case we're running the tripleo.baremetal.v1.tag_node workflow, which modifies the profile assigned in the ironic node capabilities (see tripleo-docs for more information about manual tagging of nodes)
At this point the mistral workflow is running, and it'll either succeed or fail, and also create some output (which in the TripleO model is sometimes returned to the Ux via a Zaqar queue). We can view the status, and the outputs (truncated for brevity):
So that's it - we ran a mistral workflow, it suceeded and we looked at the output, now we can see the result looking at the node in Ironic, it worked! :)
Mistral workflows, create your own!Here I'll show how to develop your own custom workflows (which isn't something we expect operators to necessarily do, but is now part of many developers workflow during feature development for TripleO).
First, we create a simple yaml definition of the workflow, as defined in the v2 Mistral DSL - this example lists all available ironic nodes, then finds those which match the "test" profile we assigned in the example above:
This example uses the mistral built-in "ironic" action, which is basically a pass-through action exposing the python-ironicclient interfaces. Similar actions exist for the majority of OpenStack python clients, so this is a pretty flexible interface.
Now we can now upload the workflow (not wrapped in a workbook this time, so we use workflow-create), run it via execution create, then look at the outputs - we can see that the matching_nodes output matches the ID of the node we tagged in the example above - success! :)
Using this basic example, you can see how to develop workflows which can then easily be copied into the tripleo-common workbooks, and integrated into the TripleO deployment workflow.
In a future post, I'll dig into the use of custom actions, and how to develop/debug those.