aboutsummaryrefslogtreecommitdiffstats
path: root/releasenotes/notes/role-tags-16ac2e9e8fcab218.yaml
diff options
context:
space:
mode:
Diffstat (limited to 'releasenotes/notes/role-tags-16ac2e9e8fcab218.yaml')
-rw-r--r--releasenotes/notes/role-tags-16ac2e9e8fcab218.yaml18
1 files changed, 18 insertions, 0 deletions
diff --git a/releasenotes/notes/role-tags-16ac2e9e8fcab218.yaml b/releasenotes/notes/role-tags-16ac2e9e8fcab218.yaml
new file mode 100644
index 00000000..dadbfa4b
--- /dev/null
+++ b/releasenotes/notes/role-tags-16ac2e9e8fcab218.yaml
@@ -0,0 +1,18 @@
+---
+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.