Bug 1126381 - StayPuft hostgroup parameters must be values and not variables
Summary: StayPuft hostgroup parameters must be values and not variables
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhel-osp-installer
Version: 5.0 (RHEL 6)
Hardware: Unspecified
OS: Unspecified
Target Milestone: ga
: Installer
Assignee: Scott Seago
QA Contact: Omri Hochman
Depends On:
TreeView+ depends on / blocked
Reported: 2014-08-04 09:54 UTC by Ofer Blaut
Modified: 2014-08-08 18:24 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-08-05 15:20:34 UTC

Attachments (Terms of Use)

Description Ofer Blaut 2014-08-04 09:54:26 UTC
Description of problem:

Currently most of the parameters in staypuft are variables 
like  in neutron networker :
Ovs tunnel iface = <%= n = @host.deployment.neutron; n.enable_tunneling? ? n.networker_tenant_interface : "" %>

1. User can know what is the values being used
2. when we will export deployment and will import it NO value will exist 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. create new deployment 
2. advanced configuration -> see values or edit them
3. export deployment and check no values are used but variables 

Actual results:

Expected results:

Additional info:

Comment 2 Mike Burns 2014-08-04 11:53:02 UTC
Scott, this is already fixed in the 0.2.x stream, right?

Comment 3 Scott Seago 2014-08-04 15:57:20 UTC
At this point, the advanced configuration summary view should show the calculated value -- the text field will show the variable/method interpolation src, and below there is an "evaluates to..." section which shows what it will evaluate to on a host. The edit version lets you edit the actual value set, which in some cases is the erb code snippet like you see here. In both cases this is correct behavior, as 1) on the view screen the user needs to see both values -- what will be active on the host, and where the value comes from. On the edit screen, we're editing the actual value stored in the database, which in some cases is a simple value, but in others is the formula used for dynamic interpretation.

For import/export, the formula is exactly what we need -- if we export a calculated value, then on import, the UI parameters will be ignored, which would be a problem -- the UI parameters are, in most cases, the source for calculating those dynamic parameters. On export, we export both together, and import brings them back -- the goal of export/import is to preserve the deployment state as close as possible to the original, and exporting calculated values would fail to do that.

I'm pretty sure this is working right in 0.1.x even.

Comment 4 Mike Burns 2014-08-05 15:20:34 UTC
I agree with Scott, we need to keep the expressions/formulas stored there.  The UI does show the evaluated values.

When exporting/importing, we need to make sure the expressions and formulas are kept consistent.

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