Invalid parameter defaults can't be overriden

[Steven Hardy]

If you have a template with a parameter constraint (particularly when using custom constraints), it's possible that the default in the template may not match your environment, but that when resolved at runtime the value provided in the environment/parameters may be perfectly fine.

However heat fails the validation step, so you can't override the invalid parameter default with a valid value:

$ nova keypair-list
+-----------+-------------------------------------------------+
| Name | Fingerprint |
+-----------+-------------------------------------------------+
| stack_key | 46:de:3d:cb:fe:7e:82:7d:28:b8:b8:fc:0e:88:9f:d2 |
+-----------+-------------------------------------------------+

$ cat param_ex.yaml
heat_template_version: 2013-05-23

parameters:
  key_name:
    type: string
    constraints:
      - custom_constraint: nova.keypair
    default: noexist

$ heat stack-create param_ex -f param_ex.yaml -P "key_name=stack_key"
ERROR: Invalid default noexist (Error validating value u'noexist': The Key (noexist) could not be found.)

[Thomas Herve (therve)]

I'm a bit puzzled by that one. Why having a default if it's not valid in all your environments? I presume you can reproduce this problem easily by having an integer parameter with a default value of 'foo'.

We may be able to fix, but I'm a bit worried that we'll end up with an inconsistent template in Heat, where a future update will fail in weird way. It's certainly something to test.

[Steve Kowalik (stevenk)]

I am currently impacted by this in TripleO. Currently, we creare one Nova flavor (called 'baremetal'), which describes the lowest common denominator hardware the cloud has available. This deals badly with hetrogenous environments, and environments where you want to more finely control where services are deployed by Heat. Which means we have a number of flavors available to describe the hardware, none of which are called 'baremetal', and so stack validation fails because the default flavor does not exist.

[Steven Hardy (shardy)]

So, I can kinda see both sides on this one.

On the one hand, folks shouldn't put defaults in templates if they want them to be portable (they should go in the parameters section of an environment file instead)

On the other hand, it's just a *default*, so if you're passing an actual parameter value, the default value is irrelevant.

So we have two options:

1. Rework tripleo-heat-templates so no parameter defaults are included (instead, have a parameters-default.yaml with a parameters environment section)

2. Allow parameter override at create/update (we'd still validate the default and fail if someone does template-validate, but not on stack-create if a valid parameter exists in the parameters/environment)

Actually, there's a third option which involves making defaults not validated at all for custom contstraints (because they should only ever really be validated at runtime, since static validation makes no sense when you're validating against an external service whose responses may change)

None of these are particularly simple, and I'm not sure what the least-bad option is atm.

Certainly changing this inside heat is possible, but not trivial (I've already started a patch).

[Steven Hardy (shardy)]

Note re (2), I think we'd want to change this:

https://github.com/openstack/heat/blob/master/heat/engine/parameters.py#L226

So we only validate value() which will validate the default in template-validate and the actual value when passed to stack-create

The other option would appear to be to override _validate_default in the CustomConstraint class, so that defaults are not validated in that case.

I'm not sure what the most preferable approach is atm.

I understand StevenK is now working on a patch, so I'll assign this to him and review when it's posted :)

[Steve Kowalik (stevenk)]

I'm also not sure what the best approach is, so I'd prefer this was assigned to someone else until we have a clear direction we'd like to take.

[Steven Hardy (shardy)]

@stevenk: Fair enough, reassigning to me if your patch isn't imminent.

What are your thoughts re moving the defaults in the tripleo templates?

That is looking like the quickest/simplest solution to me atm, so I may knock up a patch which we can discuss and potentially compare with the risk and complexity associated with changing the behaviour in heat.

[Steve Kowalik (stevenk)]

I'm happy enough to blow apart one of my patches against -incubator to allow specifying all flavors and having the onus for the default be within -incubator which allows us to completly drop the defaults in -heat-templates with no break in backwards compat.

[Angus Salkeld (asalkeld)]

Steve I run you stack and it works fine.

heat stack-create param_ex -f test_parm.yaml -P "key_name=heat_key"
+--------------------------------------+------------+-----------------+----------------------+
| id | stack_name | stack_status | creation_time |
+--------------------------------------+------------+-----------------+----------------------+
| 7a14722c-ac51-4eb4-87ad-26780ddb76c2 | param_ex | CREATE_COMPLETE | 2015-03-26T01:49:26Z |
+--------------------------------------+------------+-----------------+----------------------+

I think it's been fixed. https://github.com/openstack/heat/commit/7d09bc1c1228f2b5382fda15ca243fa80d2e97de