Role decomposition

Problem description

Currently a role encompasses many tasks that cannot be separated from each other. Deployers should have the flexibility to distribute services across nodes in any combination they see fit.

Proposed changes

Task placement will be determined based on new unit - tag. Each release or plugin role may contain(or not, in this case role name will be considered as a tag name) specific set of tags. Task definitions will contain a list of tags which will be used to match them to nodes. This requires a new task resolver on nailgun side and work on decoupling of tasks on fuel-library side.

Web UI



A new tags based resolver which supports tags should be introduced. Tags are simple entities what should be used for tasks resolution(in opposite to old role driven resolution approach) only. User is not able to operate with node’s tags directly, but, he should create new role containing tags what he is interested in and assign created role to the node. primary-tags field should be introduced for node model to store primary set of tags for the node. Tags will be fetched from roles metadata during serialization process and will not be stored for each node directly(we have no tags field in node db model). It should be possible to create roles for clusters and it will be possible to have so-called roles for release and cluster created with this release. The idea is that cluster roles have a higher priority than release roles and it means that only cluster role will be used if we have so-called cluster and release roles.

Data model

An additional field named tags will be added to release metadata to provide ability to specify set of tags for release roles. Tag should have only one field: - has_primary property


    name: "Controller"
      - controller
      - mysql
    name: "controller"
    has_primary: true
    name: "mysql"
    has_primary: true

New JSON fields volumes_metadata and roles_metadata should be introduced for cluster model.

New JSON field tags_metadata should be introduced for cluster, release, plugin models.

primary_roles column should be renamed to primary_tags for node model.


Nailgun API should be extended to support role’s creation for clusters to make cluster’s specific roles not visible for other clusters and avoid mishmash.



RPC Protocol


Fuel Client

Fuel Client should be extended to support role’s creation for clusters.


As plugins have ability to define its own roles it will be possible to specify tags for any particular role introduced by a plugin. I would mention that it’s possible, but, not obligatory to specify tags for role(in this case role name will be used for tasks resolution).

Fuel Library

Blueprint’s scope includes detaching of following components: - Neutron (incl. L3 agents, LBaaS, etc) - Keystone - MySQL DB - RabbitMQ

tags will be introduced for controller role: - neutron - keystone - mysql - rabbitmq - controller

Fuel-library tasks part should be re-written for corresponding components to support new approach with tags. All tasks related only to specific tag should be marked with this tag( field role or groups should be replaced with tags).

The version of library tasks where role field has been replaced with tags shall be bumped.


keystone task to be changed:

- id: keystone
  type: puppet
  groups: [controller]
- id: keystone
  type: puppet
  groups: [controller]
  tags: [keystone]

As we have a lot of places in fuel-library code where we are collecting set of ip address for particular component by node’s role we should re-write this data access methods to work with tags and provide fallback mechanism to support old style role based approach.

Initially, we are going to have one pacemaker cluster for all nodes with assigned tags what need in it. For example, if we have ‘node-1’ with tag ‘mysql’ and ‘node-2’ with tag ‘rabbitmq’ then single pacemaker cluster with resources ‘rabbitmq’ and ‘mysql’ acting on corresponding nodes will be created.

There is no detached plugin for neutron. So, additional efforts should be spent to collect mandatory tasks for neutron task group and test it.



Upgrade impact

We should consider changes in tag’s assignment between minor releases. For example, it may be embedded into db migration process.

Security impact


Notifications impact


End user impact

User will be able to create roles with specific set of tags. Initially, user has only default set of roles and its tags. If he wants, for example, create detached role with ‘mysql’, he should create new cluster role containing only ‘mysql’ tag. User is able to modify roles(and its set of tags) in any moment except of deployment process.

Performance impact


Deployment impact


Developer impact


Infrastructure impact


Documentation impact

Describe how to create custom roles(with custom set of tag).



Primary assignee:
Other contributors:
Mandatory design review:

Work Items

  1. Introduce operations with roles for cluster(API, DB)
  2. New tags based resolver in nailgun
  3. Extend fuel-client to support operations with roles for cluster
  4. Role/Tag decomposition in Fuel-library
  5. Update composition data access methods in fuel-library
  6. Decouple Neutron component in fuel-library



Testing, QA

  • Create new test cases for the new operations with tags
  • Extend fuel-qa test suite with new API tests for the operations with tags

Acceptance criteria

User is able to deploy services currently tied to the controller (e.g. Keystone, Neutron, Mysql) on separate nodes via CLI(Web UI have a nice to have priority).