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`
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 :/
Not for nothing did C.A.R. Hoare call allowing null references "the
billion dollar mistake'. OTOH I don't recall him suggesting an
alternative. Anybody got any ideas?
cheers,
Zane.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
