Created attachment 1348638 [details] controller flavor Description of problem: Using custom profiles, node that tagged with profile X wan't assigned to a role with the same profile. Role counter wasn't updated. Version-Release number of selected component (if applicable): openstack-tripleo-ui-7.4.2-2.el7ost.noarch How reproducible: always Steps to Reproduce: 1. via UI, create a custom profile 2. tag a node with the custom profile 3. on deployment page, edit a roles flavor to match the custom profile Actual results: roles counter for # of assigned nodes to the role (with matching flavor) is not updated. Expected results: node tagged with the custom profile should be assigned to the role with matching profile. roles counter for # assigned nodes to the role was updated. Additional info:
Note that this is currently expected behaviour. Tagging the node does not explicitly mark the node for deployment. It just means that in case it gets deployed, it is going to be used for a role which profile matches the tagged profile of the node. Nodes are added for deployment by specifying the count on deployment page. This is completely separate step and IMHO it is a good thing -> user does not always want to deploy all the nodes available.
Hi Jiri, Can you clarify from your above comment: is this therefore an unwanted feature that should be closed or is there a way to complete this RFE while keeping desired behaviours? Thanks, Beth
IMHO this is unwanted feature as, as described above, the nodes tagging and assignment are two separate steps on purpose.
Verified. The UI now checks for the roles with the profile that's configured as the flavor of the role (instead of just expecting the flavor name to always be the role name). The only known limitation is that the GUI expects the flavors' profiles to always be the same as the flavors' names.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2019:0045