Bug 1398283 - Nodes that are assigned to custom roles are "Not Assigned" in other plans
Summary: Nodes that are assigned to custom roles are "Not Assigned" in other plans
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-ui
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: z3
: 10.0 (Newton)
Assignee: Jiri Tomasek
QA Contact: Ola Pavlenko
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-24 11:44 UTC by Udi Kalifon
Modified: 2017-06-28 15:27 UTC (History)
5 users (show)

Fixed In Version: openstack-tripleo-ui-1.1.0-2.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-06-28 15:27:21 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1644801 0 None None None 2016-11-25 12:03:25 UTC
OpenStack gerrit 427204 0 None None None 2017-01-31 13:34:08 UTC
Red Hat Product Errata RHBA-2017:1587 0 normal SHIPPED_LIVE Red Hat OpenStack Platform 10 Bug Fix and Enhancement Advisory 2017-06-28 19:11:42 UTC

Description Udi Kalifon 2016-11-24 11:44:26 UTC
Description of problem:
Nodes are shared by all plans, but if different plans define different roles, the nodes that assigned to those roles will appear as "not assigned" in plans that don't recognize them.


Version-Release number of selected component (if applicable):
openstack-tripleo-ui-1.0.5-1.el7ost.noarch


How reproducible:
100%


Steps to Reproduce:
1. Upload a plan with custom roles
2. Assign nodes to these roles and check in the Nodes page that the assigned role is displayed on the nodes
3. Switch to another active plan
4. Look in the Nodes page again


Actual results:
The nodes appear as "not assigned". We could have a collision here if the same nodes are assigned to different roles in different plans.


Expected results:
The assigned role should be displayed even if such a role doesn't exist in the plan that is currently active.

Comment 1 Julie Pichon 2016-11-25 12:03:26 UTC
I filed the bug upstream. I also strongly disagree with the "urgent" severity FWIW. It's annoying and confusing and needs to be fixed, ideally soon, but it's not blocking any major workflow and easy to work around. As far as I could see, the node assigned to a custom-role is not shown in the Deployment Page if the role isn't defined so there shouldn't be space for a collision.

Comment 2 Ola Pavlenko 2017-01-31 12:49:21 UTC
upstream fix was merged

Comment 3 Julie Pichon 2017-01-31 13:34:09 UTC
The flag are not quite right, the fix merged in Ocata aka 11. Either we need to change the flags/target version, or switch the status back to ON_DEV until the backport is merged.

Comment 4 Ola Pavlenko 2017-01-31 15:31:39 UTC
Thanks Julie. Changing back to ON_DEV

Comment 5 Julie Pichon 2017-02-06 15:00:20 UTC
Stable/newton backport merged.

Comment 6 Jon Schlueter 2017-02-14 17:35:24 UTC
updated to include only stable/newton patch

Comment 8 Udi Kalifon 2017-04-12 13:19:51 UTC
It works in OSP11 and needs to be tested in OSP10 z3. There is only a small problem that you can't un-assign a node from a custom role, when you're in a plan that doesn't feature this role (you won't find a role assignment card for it in the deployment page).

Comment 9 Udi Kalifon 2017-04-12 13:24:09 UTC
What happens if you delete the plan with the custom roles? You can't un-assign nodes from a role that doesn't exits in any plan, which makes these nodes unrecoverable for further use any more.

Comment 10 Udi Kalifon 2017-04-20 15:24:40 UTC
Verified in puddle 2017-04-10.

Comment 13 errata-xmlrpc 2017-06-28 15:27:21 UTC
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/RHBA-2017:1587


Note You need to log in before you can comment on or make changes to this bug.