| Summary: | get_param does not work on Horizon | |||
|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Shinobu KINJO <skinjo> | |
| Component: | python-django-horizon | Assignee: | Radomir Dopieralski <rdopiera> | |
| Status: | CLOSED ERRATA | QA Contact: | Ido Ovadia <iovadia> | |
| Severity: | urgent | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 8.0 (Liberty) | CC: | achernet, aortega, apannu, athomas, beth.white, ccamacho, csong, jstransk, lruzicka, mburns, mrunge, rdopiera, rhel-osp-director-maint, srevivo | |
| Target Milestone: | --- | Keywords: | ZStream | |
| Target Release: | 8.0 (Liberty) | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | python-django-horizon-8.0.1-11.el7ost | Doc Type: | Bug Fix | |
| Doc Text: |
Cause:
It seems there has been changes in the Heat API, and it no longer returns the default value for a parameter in the "Default" key, it has been instead renamed to "DefaultValue" and later to "Value".
Consequence:
The default values for the create stack form fields weren't picked up by Horizon.
Fix:
This patch makes it use all those key names, whichever exists.
Result:
The fields in the create stack form now properly have default values taken from the environment file.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1421631 (view as bug list) | Environment: | ||
| Last Closed: | 2017-03-08 18:15: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: | ||
| Bug Depends On: | ||||
| Bug Blocks: | 1421631 | |||
* Please find out additional 1 png and 2 yaml files which specifically show you what happen. * Please update. * Please tell us if any reason that there is zero progress. Hello, I finally managed to finish the test battery that I had planned for this bug. The error itself it's that when uploading the environment+template it doesn't refresh the form fields in the second step of the wizard. Affected 'tested' versions: - Downstream Packstack OSP 8 to 11. - Upstream TripleO Liberty, Mitaka, Newton and Ocata. For all versions using the CLI, the deployment tooling worked without issues. I'll check into the UI issue to get the root cause. Just one more clarification, the error isn't related to OSP, is related to Horizon itself. Looking at the code, I don't think that it was ever supposed to update the fields in the second step. I think it's leaving doing that to heat, and simply just passes the environment data to the heat calls. It looks like this feature is simply not supported by Horizon at the moment. Adding support for it would be a feature, and would happen in the latest version upstream -- I have created a bug upstream to further discuss the issue and plan the work on implementing that feature: https://bugs.launchpad.net/horizon/+bug/1658111 So here's what I learned: There is no difference in how parameters are handled in Horizon between OSP7 and OSP8 (and further), and in fact Horizon doesn't have any code that would parse the environment file and fill-in the default values for the form fields. That much can be seen by examining the code. However, when I tried different versions of Horizon (OSP7, OSP8, OSP9, current upstream master, etc.) with different deployments of the Open Stack Platform, I noticed that the fields *are* properly populated with default values from the environment file when using OSP7 and *any* version of Horizon, and they are *not* populated if using any later version of the Open Stack Platform, even with Horizon from OSP7. Further investigation led me to examine the "api.heat.validate()" call, and I learned that with OSP7 stack, that call will return parameters with "Default" values taken from the environment file, while any later stack will omit the "Default" keys, or even return an error straight away. This makes me believe that the change that is causing this problem is in fact on the Heat side, in how the template validation works. I will need some further investigation to pin-point the change. I see that this field name changed from "Default" to "DefaultValue". I posted a patch upstream that works around the problem on the Horizon side. https://review.openstack.org/431426 Backporting to OSP8: https://code.engineering.redhat.com/gerrit/#/c/97552/ (In reply to Radomir Dopieralski from comment #39) > I see that this field name changed from "Default" to "DefaultValue". Great finding. 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://rhn.redhat.com/errata/RHBA-2017-0469.html |
On top of OSP8, the following template and environment sources do not work. But on top of OSP7, they work. * If I've missed anything, please point it out to me. // **************** // * Horizon web ui // **************** Project -> Orchestration -> Stacks -> Launch Stack # Template Data heat_template_version: 2015-04-30 description: > Test Stack parameters: server_port_ip: type: string description: IP Address for Port resources: server_port: type: OS::Neutron::Port properties: network: private admin_state_up: true fixed_ips: [{ip_address: { get_param: server_port_ip }}] # Environment Data parameters: server_port_ip: 10.0.0.10