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).
If you click the "Initialize" button in the GUI - you get 2 networks called "default-net" in the overcloud.
*** Bug 1233629 has been marked as a duplicate of this bug. ***
Ryan, can you please look if this is still an issue?
Confirmed this issue is still valid.
It seems the issue is the password used when trying to connect to the overcloud keystone service is 'unset' in the tuskar plan.
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.
Related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1236054
I think this is another one related bug@ https://bugzilla.redhat.com/show_bug.cgi?id=1235334
*** Bug 1236687 has been marked as a duplicate of this bug. ***
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.
*** Bug 1238106 has been marked as a duplicate of this bug. ***
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.
Alright there is a new bug based on my comment #15. See it here: https://bugzilla.redhat.com/show_bug.cgi?id=1238622
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
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.
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) ?
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.
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
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