be274f1f49
Prior to Ocata, the Controller role was hardcoded for various lookups. When we switched to having the primary role name being dynamically pulled from the roles_data.yaml using the first role as the primary role as part of I36df7fa86c2ff40026d59f02248af529a4a81861, it introduced a regression for folks who had previously been using a custom roles file without the Controller being listed first. Instead of relying on the position of the role in the roles data, this change adds the concepts of tags to the role data that can be used when looking for specific functionality within the deployment process. If no roles are specified with this the tags indicating a 'primary' 'controller', it will fall back to using the first role listed in the roles data as the primary role. Change-Id: Id3377e7d7dcc88ba9a61ca9ef1fb669949714f65 Closes-Bug: #1677374
19 lines
953 B
YAML
19 lines
953 B
YAML
---
|
|
features:
|
|
- |
|
|
Adds tags to roles that allow an operator to specify custom tags to use
|
|
when trying to find functionality available from a role. Currently a role
|
|
with both the 'primary' and 'controller' tag is consider to be the primary
|
|
role. Historically the role named 'Controller' was the 'primary' role and
|
|
this primary designation is used to determine items like memcache ip
|
|
addresses. If no roles have the both the 'primary' and 'controller' tags,
|
|
the first role specified in the roles_data.yaml is used as the primary
|
|
role.
|
|
upgrade:
|
|
- |
|
|
If using custom roles data, the logic was changed to leverage the first
|
|
role listed in the roles_data.yaml file to be the primary role. This can
|
|
be worked around by adding the 'primary' and 'controller' tags to the
|
|
custom controller role in your roles_data.yaml to ensure that the defined
|
|
custom controller role is still considered the primary role.
|