If environment has two and more plugins, plugin developer should be able to specify priorities in which plugins will be deployed.
Plugins for network configuration should be run before plugins which install software services. Currently it is not possible to specify the order of plugins tasks deployment.
For each stage name plugin developer adds a postfix, which defines stage specific execution order of the task.
Lets take a look at the following example:
tasks.yaml file of Fuel plugin A
- role: ['primary-controller', 'controller'] stage: post_deployment/100 type: shell parameters: cmd: ./deploy.sh timeout: 42
tasks.yaml file of Fuel plugin B
- role: ['primary-controller', 'controller'] stage: post_deployment/50 type: shell parameters: cmd: ./deploy.sh timeout: 42
During post_deployment stage execution post task of plugin B will be executed before plugin post task of plugin A, because “post_deployment/50” is lower than “post_deployment/100”.
But in some cases plugins don’t know about each other, and the best way to solve the problem is to define as convention the ranges which plugin developers will be able to use.
Pre and post deployment ranges:
In this case if one network plugin defines “stage: post_deployment/100” and another plugin defines “stage: post_deployment/2000”, they will be installed in the right order without knowing about each other.
Also if there are two plugins which implement monitoring, plugin developers can figure out which plugin should be installed first and tune postfixes accordingly.
If two tasks have the same priorities, they should be sorted in alphabetic order by name and the first in the list should be deployed first.
If in a single plugin there are several tasks with the same postfix priority, then they should be deployed in the same order in which they specified in the file.
Postfix can be negative or positive, floating or integer number.
Additional plugin specific stages can be defined:
And then existing stages
And the last one new stage
In this case plugin developer will be able to work with a single entity without some additional postfixes.
But, in this case plugin developer won’t be able to more granularly define order, for example if two plugins implement monitoring, it’ll be impossible to define the order.
Another cons is it’ll confuse a plugin developer because plugin specific stages are differ from granular deployment stages. Also it will complicate migration to the next release when we will implement granular deployment like tasks.
Plugins priorities should be defined not for entire plugin, but for each task, because a single plugin can have drivers and services, which should be deployed in the right order.
It was decided to use “/” instead of ”:”, or ”::” as a separator because in case of typos like:
stage: post_deployment:: 50
stage: post_deployment: :50
Yaml parser fails and it’s impossible to customize error message.
Also people got used to convention that “/” is used to define subdirectories or subgroups for RPMs and DEBs.
Numerical postfixes for stages in each task.
Here is example of order which tasks should be executed in:
Plugin with name “plugin1”, and with the next task stages:
stage: pre_deployment stage: pre_deployment/100 stage: pre_deployment/-100 stage: pre_deployment/-99.9
Plugin with name “plugin2”, and with the next task stages:
stage: pre_deployment stage: pre_deployment/100.0 stage: pre_deployment/-101 stage: pre_deployment/0
Execution order of the tasks for both plugins which is sent to orchestrator:
stage: pre_deployment/-101 # plugin2 stage: pre_deployment/-100 # plugin1 stage: pre_deployment/-99.9 # plugin1 stage: pre_deployment # plugin1 stage: pre_deployment # plugin2 stage: pre_deployment/0 # plugin2 stage: pre_deployment/100 # plugin1 stage: pre_deployment/100.0 # plugin2