Bug 1390045 - get_param does not work on Horizon
Summary: get_param does not work on Horizon
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-django-horizon
Version: 8.0 (Liberty)
Hardware: Unspecified
OS: Unspecified
medium
urgent
Target Milestone: ---
: 8.0 (Liberty)
Assignee: Radomir Dopieralski
QA Contact: Ido Ovadia
URL:
Whiteboard:
Depends On:
Blocks: 1421631
TreeView+ depends on / blocked
 
Reported: 2016-10-31 02:54 UTC by Shinobu KINJO
Modified: 2020-04-15 14:47 UTC (History)
14 users (show)

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.
Clone Of:
: 1421631 (view as bug list)
Environment:
Last Closed: 2017-03-08 18:15:26 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1658111 0 None None None 2017-01-20 14:59:43 UTC
OpenStack gerrit 431426 0 None None None 2017-02-09 10:26:54 UTC
Red Hat Product Errata RHBA-2017:0469 0 normal SHIPPED_LIVE python-django-horizon bug fix advisory 2017-03-08 23:15:11 UTC

Comment 3 Shinobu KINJO 2016-11-04 05:33:28 UTC
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

Comment 19 Shinobu KINJO 2016-12-14 03:39:44 UTC
* 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.

Comment 29 Carlos Camacho 2017-01-11 20:51:24 UTC
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.

Comment 30 Carlos Camacho 2017-01-11 20:53:31 UTC
Just one more clarification, the error isn't related to OSP, is related to Horizon itself.

Comment 32 Radomir Dopieralski 2017-01-17 10:11:01 UTC
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.

Comment 33 Radomir Dopieralski 2017-01-20 14:59:44 UTC
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

Comment 38 Radomir Dopieralski 2017-02-09 09:47:30 UTC
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.

Comment 39 Radomir Dopieralski 2017-02-09 10:10:25 UTC
I see that this field name changed from "Default" to "DefaultValue".

Comment 40 Radomir Dopieralski 2017-02-09 10:26:54 UTC
I posted a patch upstream that works around the problem on the Horizon side.

https://review.openstack.org/431426

Comment 41 Radomir Dopieralski 2017-02-13 10:27:18 UTC
Backporting to OSP8: https://code.engineering.redhat.com/gerrit/#/c/97552/

Comment 42 Shinobu KINJO 2017-02-13 10:30:49 UTC
(In reply to Radomir Dopieralski from comment #39)
> I see that this field name changed from "Default" to "DefaultValue".

Great finding.

Comment 47 errata-xmlrpc 2017-03-08 18:15:26 UTC
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


Note You need to log in before you can comment on or make changes to this bug.