Description of problem: If you enable some of the Cinder backends in your environment, and save and move over to the "Properties" tab, you get this: Deployment parameters could not be loaded 404 Client Error: Not Found for url: https://192.168.24.2:13808/v1/AUTH_d89c3add038047b0b4bedc6bebe43c87/overcloud/puppet/extraconfig/pre_deploy/controller/cinder-netapp.yaml Version-Release number of selected component (if applicable): openstack-tripleo-ui-8.3.1-2.el7ost.noarch How reproducible: 100% Steps to Reproduce: 1. Open the plan configuration dialog 2. In the "Storage" section, enable the Cinder NetApp backend 3. Save 4. Click on the "Properties" tab Actual results: Error: Deployment parameters could not be loaded Additional info: This happens with several other Cinder environment files as well.
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