Open Stack

On Mon, Dec 05, 2016 at 04:27:50PM -0500, Zane Bitter wrote:
> Any parameter in a Heat template that has a default other than None is
> considered optional, so the user is not required to pass a value. Otherwise,
> however, the parameter is required and creating the stack will fail pretty
> immediately if the user does not pass a value.
> 
> I've noticed that this presents a giant pain, particularly when trying to
> create what we used to call provider templates. If you do e.g.
> 
> `openstack orchestration resource type show -f yaml --template-type hot
> OS::Nova::Server`


Yes, indeed, this is a giant pain - e.g in TripleO where we make very heavy
use of nested "provider" templates, it's really inconvenient having to work
around spurious validation issues related to get_attr returning None, and
also figuring out what values are passed as parameters via the parent
templates.  So yes, *please* lets fix this :)

> then you get back a template with dozens of parameters, most of which don't
> have defaults (because the corresponding resource properties don't have
> defaults) and are therefore not optional. I consider that a bug, because in
> many cases the corresponding resource properties are *not* required
> (properties have a "required" flag that is independent from the "default"
> value).
> 
> The result is that it's effectively impossible for our users to build
> re-usable child templates; they have to know which properties the parent
> template does and does not want to specify values for.
> 
> Using a default that corresponds to the parameter type ("", [], {}, 0,
> false) doesn't work, I don't think, because there are properties that treat
> None differently to e.g. an empty dict.
> 
> The obvious alternative is to use a different sentinel value, other than
> None, for determining whether a parameter default is provided and then
> allowing users to pass null as default. We could then adjust the properties
> code to treat this sentinel as if no value were specified for the property.
> 
> The difficulty of this is knowing how to handle other places that get_param
> might be used, especially in arguments to other functions. I guess we have
> that problem now in some ways, because get_attr often returns None up to the
> point where the resource it refers to is created. I hoped that we might get
> away from that with the placeholders spec though :/

Maybe I'm oversimplifying but I was expecting as solution similar to you
describe above with a per-type sentinel, but with a reworked base-class for
all intrinsic functions, so that the new sentinel value can be
transparently passed around instead of evaluated?

I guess the tricky part about this is we'd always need a type for any
attributes (e.g including outputs which are currently untyped).

We'd possibly also need to modify parameter contraints evaluation to ensure
the sentinel isn't failed for constraints, but IIRC we disable value
validation for most non-runtime validation anyway?

More thought required here but for sure I'd love to see this fixed and will
be happy to help with testing/reviews on TripleO if anyone has any WIP
patches based on the above ideas :)

Thanks!

Steve