Bug 1554909
| Summary: | [RFE][tripleo]: UI support for config-download. | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Beth White <beth.white> |
| Component: | openstack-tripleo-ui | Assignee: | Jiri Tomasek <jtomasek> |
| Status: | CLOSED ERRATA | QA Contact: | Amit Ugol <augol> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 10.0 (Newton) | CC: | apannu, augol, beth.white, jjoyce, jrist, jschluet, jtomasek, mbarnett, mburns, rhel-osp-director-maint, sclewis, slinaber, tvignaud, ukalifon |
| Target Milestone: | Upstream M2 | Keywords: | FutureFeature, Triaged |
| Target Release: | 14.0 (Rocky) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | https://blueprints.launchpad.net/tripleo/+spec/config-download-ui | ||
| Whiteboard: | |||
| Fixed In Version: | openstack-tripleo-ui-9.3.1-0.20180909174557.1a18ba7.el7ost | Doc Type: | Enhancement |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-01-11 11:49:11 UTC | Type: | --- |
| 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: | 1635745 | ||
|
Description
Beth White
2018-03-13 14:41:56 UTC
Please elaborate what is config-download, thanks. It is work that is being done as part of OSP14 to change and improve deployment. Deployment status is now stored in Swift object and is updated by Mistral workflows. This allows clients to easily retrieve the current deployment status at any point of time. The reality is that we don't have a choice since deployments will default to config-download for Rocky/14 Do I understand correctly that this is just a different Mistral workflow that the UI needs to trigger, replacing the current workflow that was in use up to OSP13, or is there any more impact to the UI in addition to that? Please give some details on what in the UI needs to change, and how we can test it. (In reply to Udi from comment #9) > Do I understand correctly that this is just a different Mistral workflow > that the UI needs to trigger, replacing the current workflow that was in use > up to OSP13, or is there any more impact to the UI in addition to that? > Please give some details on what in the UI needs to change, and how we can > test it. Config download changes the way the deployment is done and it also has impact on GUI. The deployment does not consist of only the Heat stack creation but there is a second - configuration part driven by Ansible. Doe to this, to track deployment status and progress it is not possible to use just Heat stack status. For this, deploy_plan workflow as been updated to trigger config-download part as a subworkflow and tracking deployment status has moved into Swift/Mistral rather than being equal to Heat stack status. During the progress of the deployment relevant deployment tasks update deployment_status which is then stored in <planName>-messages Swift container in deployment_status.yaml object. GUI then looks at this to get current deployment status. The deployment progress tracking has also changed in GUI. In first part of deployment (Heat stack creation) GUI displays progress percentage calculated based on count of total heat resources and CREATE_COMPLETE resources. In detail section, a table of resources is shown. This has not changed. For the second (applying deployment configuration) part though, the percentage changes into a generic 'in progress' progress bar and detailed view displays real time Ansible output which arrives via Zaqar queue. Undeploy process has changed too, due to addition of a workflow which updates deployment_status as described above. In case of deployment failure a deployment_status error message is shown and deployment failures are displayed (implementation of this is currently in progress), The failures are based on errors coming from Ansible part of the deployment. For backwards compatibility, for upgrades, for case when deployment_status.yaml is deleted, a functionality to recover deployment status is provided. All related patches now landed upstream Verified: openstack-tripleo-ui-9.3.1-0.20180921180341.df30b55.el7ost.noarch There are still issues, mainly when deployments are aborted or fail, where you see a false success of false failure. Separate bugs will be opened on those issues. 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-2019:0045 |