Bug 1395810 - Node assignment always updates the 'overcloud' node count, no matter the current plan
Summary: Node assignment always updates the 'overcloud' node count, no matter the curr...
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
unspecified
Target Milestone: rc
: 10.0 (Newton)
Assignee: Julie Pichon
QA Contact: Ola Pavlenko
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-16 18:06 UTC by Julie Pichon
Modified: 2016-12-14 16:33 UTC (History)
7 users (show)

Fixed In Version: openstack-tripleo-ui-1.0.5-2.el7ost openstack-tripleo-common-5.4.0-3.el7ost
Doc Type: If docs needed, set a value
Doc Text:
.
Clone Of:
Environment:
Last Closed: 2016-12-14 16:33:06 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1642342 0 None None None 2016-11-16 18:06:48 UTC
OpenStack gerrit 400263 0 None None None 2016-11-22 10:25:18 UTC
OpenStack gerrit 400949 0 None None None 2016-11-22 19:56:10 UTC
Red Hat Product Errata RHEA-2016:2948 0 normal SHIPPED_LIVE Red Hat OpenStack Platform 10 enhancement update 2016-12-14 19:55:27 UTC

Description Julie Pichon 2016-11-16 18:06:49 UTC
Description of problem:
When I try to assign nodes on a non-default plan, the profile gets added to the node correctly but the node count wrongly gets updated for the 'overcloud' default plan, *not* the plan currently activated.

It means only the default of 1 controller and 1 compute will ever be deployed for non-default plans. This may also cause issues later on if people use the CLI to scale up/down the default plan.

Version-Release number of selected component (if applicable):
1.0.4-4.el7ost

How reproducible:
100%?

Steps to Reproduce:
1. Create a new plan, e.g. test
2. Click on the new plan to "activate" it and got to the "Deployment Plan" page
3. On the CLI, look at the mistral environments for both 'overcloud' and 'test', confirm nothing is set in the parameters_defaults ($ mistral environment-get <plan_name>)
4. On the UI, assign a node to 'Ceph storage'

Actual results:
5. The CephStorageCount for 'overcloud' was updated to 1, the 'test' environment didn't change.

Expected results:
5. The CephStorageCount for 'test' got updated in the Mistral environment.

Additional info:
This is possibly related to the larger node assignment/tagging splitting (tracked upstream at https://bugs.launchpad.net/tripleo/+bug/1640103) though it'd be good to get a band-aid for this while waiting for the better, possibly-not-easily-backportable fix.


There is a workaround: On the deployment page in the UI, editing the overall Deployment Configuration and navigating to the Parameters, it is possible to manually update the node count for the main roles (CephStoragecCount, ControllerCount, etc).

I don't think this is a release blocker, as it doesn't affect the default plan and there is a workaround. However, I think it needs to be documented in a release note, and hopefully fixed shortly.

Comment 1 Julie Pichon 2016-11-16 18:26:17 UTC
See bug 1395755 (especially comments 3 to 7) to see additional information on the bug's effect.

Comment 2 Julie Pichon 2016-11-22 10:25:19 UTC
Updating the doc text to mark this as a known issue, in case the upstream patches don't merge in time for GA.

Comment 3 Julie Pichon 2016-11-22 19:56:10 UTC
Last backport proposed upstream.

Comment 4 Julie Pichon 2016-11-23 13:18:46 UTC
All the upstream fixes have merged in stable/newton.

Comment 6 Jon Schlueter 2016-11-28 20:17:18 UTC
identified external tracker patches are included in specified Fixed in versions

Comment 10 errata-xmlrpc 2016-12-14 16:33:06 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://rhn.redhat.com/errata/RHEA-2016-2948.html


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