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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
