Bug 1193922
| Summary: | CLI is not saving deployment parameters to Tuskar plan | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Udi Kalifon <ukalifon> |
| Component: | python-rdomanager-oscplugin | Assignee: | Lennart Regebro <lregebro> |
| Status: | CLOSED ERRATA | QA Contact: | Udi Kalifon <ukalifon> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | Director | CC: | akrivoka, calfonso, ekuris, jslagle, kambiz, lregebro, mandreou, mburns, mcornea, ohochman, rbrady, rhel-osp-director-maint, yeylon |
| Target Milestone: | ga | Keywords: | Triaged |
| Target Release: | Director | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | python-rdomanager-oscplugin-0.0.8-27.el7ost | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-08-05 13:50:29 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1227873 | ||
|
Description
Udi Kalifon
2015-02-18 14:54:07 UTC
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 |