Bug 1193922 - CLI is not saving deployment parameters to Tuskar plan
Summary: CLI is not saving deployment parameters to Tuskar plan
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-rdomanager-oscplugin
Version: Director
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ga
: Director
Assignee: Lennart Regebro
QA Contact: Udi
URL:
Whiteboard:
: 1233629 1236687 1238106 (view as bug list)
Depends On:
Blocks: 1227873
TreeView+ depends on / blocked
 
Reported: 2015-02-18 14:54 UTC by Udi
Modified: 2015-08-05 13:50 UTC (History)
13 users (show)

Fixed In Version: python-rdomanager-oscplugin-0.0.8-27.el7ost
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-08-05 13:50:29 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Gerrithub.io 237713 None None None Never
Gerrithub.io 238733 None None None Never
Red Hat Product Errata RHEA-2015:1549 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform director Release 2015-08-05 17:49:10 UTC

Description Udi 2015-02-18 14:54:07 UTC
Description of problem:
When deploying the overcloud from the command line (for example by 'instack-deploy-overcloud --tuskar'), the deployment is initialized but you don't see that from the "Overview" page in the GUI... There you still see "Initialization needed" and there is an "Initialize" button. Instead, what you're supposed to see are the credentials to connect to the overcloud (url and admin password).


Version-Release number of selected component (if applicable):
openstack-tripleo-0.0.5-2c3fb309727671130a32b4c19de48ec22c8530aa1.el7ost.noarch
openstack-tuskar-ui-extras-0.0.3-1.el7ost.noarch
openstack-tuskar-0.4.15-4.el7ost.noarch
openstack-tuskar-ui-0.2.0-11.el7ost.noarch
python-tuskarclient-0.1.15-3.el7ost.noarch


How reproducible:
100%


Steps to Reproduce:
1. Install according to https://wiki.test.redhat.com/RhevmQe/OpenStackTeam/TripleO/RhosWithTripleO
2. To deploy from the command line, edit deploy-overcloudrc and add "export CONTROLSCALE=1" to the file, then source the stackrc file and the deploy-overcloudrc file and run 'instack-deploy-overcloud --tuskar'
3. When deployment finishes (takes almost 15 minutes) log in to the GUI and visit the "Overview" page.


Actual results:
Deployment seems uninitialized


Expected results:
Tuskar should realize that initialization is not necessary. For example, you can get the KeystoneURL by running 'heat output-show overcloud KeystoneURL' (I'm not sure how to get the admin password except by logging into the VM and looking at the stackrc there).

Comment 3 Udi 2015-02-18 15:16:33 UTC
If you click the "Initialize" button in the GUI - you get 2 networks called "default-net" in the overcloud.

Comment 6 Ana Krivokapic 2015-06-19 11:23:29 UTC
*** Bug 1233629 has been marked as a duplicate of this bug. ***

Comment 8 Ana Krivokapic 2015-06-24 10:04:54 UTC
Ryan, can you please look if this is still an issue?

Comment 9 Ryan Brady 2015-06-24 19:04:13 UTC
Confirmed this issue is still valid.

Comment 10 Ryan Brady 2015-06-26 12:41:36 UTC
It seems the issue is the password used when trying to connect to the overcloud keystone service is 'unset' in the tuskar plan.

Comment 11 Dougal Matthews 2015-06-26 15:15:38 UTC
I think this happens because during a deploy the CLI generates various parameters that are needed but not provided by the user. These include all the passwords and the keystone cert. These are incorrectly not written back to the Tuskar API. This means the UI has no way of accessing these details.

This problem also impacts the CLI when doing a stack update. I think we should consider raising the priority of this.

Comment 12 Ana Krivokapic 2015-06-26 15:40:27 UTC
Related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1236054

Comment 13 Marios Andreou 2015-06-29 10:54:27 UTC
I think this is another one  related bug@ https://bugzilla.redhat.com/show_bug.cgi?id=1235334

Comment 14 Dougal Matthews 2015-06-30 09:39:59 UTC
*** Bug 1236687 has been marked as a duplicate of this bug. ***

Comment 15 Udi 2015-07-01 07:38:12 UTC
In addition to the scale parameters, testing is needed to insure that parameters such as --network-cidr and --floating-ip-start etc' are saved to the plan, and users are not required to repeat them every time they scale.

Comment 16 Ana Krivokapic 2015-07-01 11:58:52 UTC
*** Bug 1238106 has been marked as a duplicate of this bug. ***

Comment 17 Lennart Regebro 2015-07-02 09:33:26 UTC
Udi, that's a good point, and in fact they are not saved, and I'm not sure where they should be saved. I think we should make this a separate bug.

Comment 18 Udi 2015-07-02 10:06:18 UTC
Alright there is a new bug based on my comment #15. See it here: https://bugzilla.redhat.com/show_bug.cgi?id=1238622

Comment 20 Udi 2015-07-05 11:35:56 UTC
We still see "Initialization needed" in the GUI, even though the deployment automatically initializes the cloud with the latest cli. At least you see the nodes' count so there is an improvement, but the bug was originally opened on the initialization. 

Also, when you click on initialize, the defaults in the dialog are not the values you used in the deployment. For example the floating ip range is 10.0.0.2 to 10.255.255.254, and I specified in the command line --floating-ip-start 10.35.190.10 --floating-ip-end 10.35.190.50. 

See related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1238622

Comment 21 Ryan Brady 2015-07-06 19:26:11 UTC
Patch: https://review.gerrithub.io/#/c/238733/

When deploying from the UI, horizon is registered as a service in the overcloud.  The UI checks the list of available services for horizon in determining if the overcloud has been initialized.  The current CLI deployment isn't registering horizon.

Comment 22 Udi 2015-07-08 18:01:34 UTC
Why is it necessary to define an endpoint for horizon? It's a real service (in the sense that it provides any services to other components) so noone will contact it.

Why are we relying on the existence of an endpoint in keystone, to determine if initialization occurred or not? A user might delete that endpoint. Can't we initialize the overcloud every time it is deployed, like the cli does, and then we can assume that it's initialized (if it isn't in ERROR state) ?

Comment 23 Ana Krivokapic 2015-07-09 09:12:57 UTC
Udi, those are both good points and we can make those improvements after GA. Specifically, we should merge the initialization with the deployment, making it a single step like the CLI does, and ideally using the shared code from tripleo-common to perform this operation.

Comment 25 Udi 2015-07-13 16:40:15 UTC
Verified:
openstack-tuskar-ui-extras-0.0.4-1.el7ost.noarch
openstack-tuskar-ui-0.3.0-10.el7ost.noarch
python-rdomanager-oscplugin-0.0.8-30.el7ost.noarch

Comment 27 errata-xmlrpc 2015-08-05 13:50:29 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/RHEA-2015:1549


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