Bug 1567893
| Summary: | Can't browse to the properties tab if the Cinder NetApp backend is enabled | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Udi Kalifon <ukalifon> |
| Component: | openstack-tripleo-heat-templates | Assignee: | Alan Bishop <abishop> |
| Status: | CLOSED ERRATA | QA Contact: | Avi Avraham <aavraham> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 13.0 (Queens) | CC: | abishop, bnemec, jjoyce, joflynn, jschluet, jtomasek, mburns, pgrist, rdopiera, scohen, slinaber, tshefi, tvignaud, ukalifon |
| Target Milestone: | z2 | Keywords: | Triaged, ZStream |
| Target Release: | 13.0 (Queens) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | openstack-tripleo-heat-templates-8.0.4-3.el7ost | Doc Type: | Bug Fix |
| Doc Text: |
TripleO's capabilities-map.yaml referenced Cinder's Netapp backend in an incorrect file location. The UI uses the capabilities map and was unable to access Cinder's Netapp configuration file.
The capabilities-map.yaml has been updated to specify the correct location for Cinder's Netapp configuration. The UI's properties tab for the Cinder Netapp backend functions correctly.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-08-29 16:35:26 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: | 1492728 | ||
|
Description
Udi Kalifon
2018-04-16 11:35:22 UTC
The error occurs because https://github.com/openstack/tripleo-heat-templates/blob/master/environments/storage/cinder-netapp-config.yaml environment points to non-existent ../../puppet/extraconfig/pre_deploy/controller/cinder-netapp.yaml template from resource_registry. This makes the environment unusable. The environment needs to get updated or removed and removed from capabilities-map.yaml in tripleo-heat-templates. This goes deeper than I thought. Yes, the problem is triggered by environments/storage/cinder-netapp-config.yaml not being updated to reflect changes made to support composable roles And I traced things further to the sample config generator's input [1]. [1] https://github.com/openstack/tripleo-heat-templates/blob/master/sample-env-generator/storage.yaml#L139 I can easily solve the problem for NetApp, but looking around in that file I see bigger issues. The Ceph backends are still referencing puppet-ceph templates, which are only valid through Ocata. This has me questioning whether the generated config files are suitable for current releases. Ben, can you comment on this? The generated storage environments were originally intended as a PoC for the environment generator tool. The intent was that they would eventually replace all of the hand-written environments and become the primary way to enable features. That obviously hasn't happened. Since they're evidently not being maintained, I'd be inclined to say just remove them and point back at the hand-written files. I still think all environments should be generated, but I've had limited success convincing upstream of that and I don't intend to pursue it further. Thanks, Ben! So it seems the UI should not be using generated environment files such as tht/environments/storage/cinder-netapp-config.yaml. Reassigning back to UI team. What's a generated environment file, and how do we know if a file is such? Is there a way to prevent users (CLI users as well as UI users) from enabling those unmaintained files? Won't it be simpler to remove them if they don't work anyways? Udi, Ben has created a tool which generates environment files based on input files. This tool ensures, that all necessary information is provided in the generated environment files. I really value this as it gives us a validation that when an environment is introduced, it is produced in a form which is consumable by UI and includes proper information. Also as part of Ben's effort, the environments were nicely organized in environments directory. It is quite a pity that it is not being used by upstream. Alan, TripleO-UI is listing environments and taking information from capabilities-map.yaml which is included in tripleo-heat-templates repository. This file contains all necessary metadata about environments, so GUI can guide user through the large amount of environments currently available and provide as much information as possible. IMHO it should be a responsibility of each DFG to update capabilities-map.yaml when an environment is addded/updated to THT. This ensures, that GUI lets user use up to date environments and description and other metadata are up to date. It is not possible for UI DFG to keep up with the amount of environment files currently available in tripleo-heat-templates and understand what features these environments enable. Could you please verify that the Storage section in capabilities-map.yaml is up to date and includes all features (environments) which are currently available? The benefit of TripleO UI in this sense is that there is no need to introduce additional code to support certain feature in UI. All that is needed is that environment file is properly defined and metadata provided in capabilities-map.yaml. I forgot that the UI is keying off the capabilities map, and yes, the Storage DFG is responsible for the storage entries. Merged on upstream master, proposed to stable/queens. *** Bug 1581070 has been marked as a duplicate of this bug. *** Udi, Need help getting access/deploying a system with UI. Can you point to me to some docs or contact person for this? Verified, package version openstack-tripleo-heat-templates-8.0.4-10.el7ost.noarch Parameters updated from UI and been updated to plan-environment.yaml file 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/RHBA-2018:2574 |