Open Stack

Hi all,

So I'm following up on a discussion that started here:

https://review.openstack.org/#/c/356240

Basically I recently suggested[1] that relaxing the restriction where a
parameter can only exist in exactly one parameter_group would be a way to
help work around some pain-points we have in TripleO atm.

Let me start with the the problems we're trying to solve, because I think
they are common to many Heat users, not just TripleO:

1. When doing nested validation to discover parameter schema, it's
impossible to tell if a parameter will be provided by the parent

This is a known issue from when nested validation was first implemented,
and we never figured out a satisfactory fix, basically because you can't
possibly tell without actually creating things whether an indirectly
provided parameter (e.g a reference to another resource in a parent
template) will resolve to a valid value.

So when you build a bunch of templates where there are some parameters
which form part of an internal interface (e.g they are always provided by
the parent and thus should not be exposed to end users) and some which are
extra (and should always be provided, or at least exposed to end users) you
have no way to differentiate them.

Example of this here:

https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/heat-api.yaml#L7

ServiceNetMap, DefaultPasswords and EndpointMap are internal interfaces,
and the remainder are options for the service that should be exposed to the
user.

One option would be to add internal interfaces to a parameter_group
"internal", but that then means we can never categorize a parameter as
anything else (such as "deprecated" for example, see below).

2. When you ship a template containing parameters, it's impossible to ever
deprecate the parameter names

The problem here is twofold:
 - We don't provide any means to tag a parameter as deprecated (so that,
   for example, a UI or CLI tool could output an annoying warning to
    encourage not using it)
 - There's no way to map an old (deprecated) name to a new one unless you
   do hacks inside the template such as overwriting one parameter with
   another via str_replace (which won't work for all parameter types, and
   you still can't ever remove the old parameter because there's no channel
   to warn users)

So, one option here is to add a parameter_group called "deprecated" that's
then introspected by the client during the validation phase, and outputs a
warning when deprecated parameters are used.

3. No way to subcategorize more than once

The assumption in the current parameter_group interface is that a UI will
always be built on the assumption that parameters should only ever be in
one group, which may be true in Horizon, but it's not the only Ux design
pattern.

Particularly when dealing with filtering lots of nested templates (which
all accept parameters which may exist in some subcategory, such as
"network", "passwords", "advanced" etc.  There's no way to subcategorize
parameters in the heat templates, so we're having to wire in hard-coded
translations outside of heat, because tripleo-ui doesn't work the same as
Horizon (it allows you to browse the nested parameters, and there are a lot
so some subcategories are basically needed here, the horizon flat list
approach won't work).

Any ideas on the most acceptable path forward here would be appreciated -
Randall mentioned enabling per-parameter tags which is certainly an
option, and having some means to handle deprecation would also be very
good, I'm just not sure on the least impactful way to do this.

Thanks!

Steve


[1] http://eavesdrop.openstack.org/meetings/heat/2016/heat.2016-08-10-08.00.log.html