Hi all, I wanted to start some discussion re $subject, because it's been apparrent that we have a lack of clarity on this issue (and have done ever since we started using parameter_defaults).
Some context: - Historically TripleO has provided a fairly comprehensive "top level" parameters interface, where many per-role and common options are specified, then passed in to the respective ResourceGroups on deployment https://git.openstack.org/cgit/openstack/tripleo-heat-templates/tree/overcloud-without-mergepy.yaml#n14 The nice thing about this approach is it gives a consistent API to the operator, e.g the parameters schema for the main overcloud template defines most of the expected inputs to the deployment. The main disadvantage is a degree of template bloat, where we wire dozens of parameters into each ResourceGroup, and from there into whatever nested templates consume them. - When we started adding interfaces (such as all the OS::TripleO::*ExtraConfig* interfaces, there was a need to enable passing arbitrary additional values to nested templates, with no way of knowing what they are (e.g to enable wiring in third-party pieces we have no knowledge of or which require implementation-specific arguments which don't make sense for all deployments. To do this, we made use of the heat parameter_defaults interface, which (unlike normal parameters) have global scope (visible to all nested stacks, without explicitly wiring in the values from the parent): http://docs.openstack.org/developer/heat/template_guide/environment.html#define-defaults-to-parameters The nice thing about this approach is its flexibility, any arbitrary values can be provided without affecting the parent templates, and it can allow for a terser implementation because you only specify the parameter definition where it's actually used. The main disadvantage of this approach is it becomes very much harder to discover an API surface for the operator, e.g the parameters that must be provided on deployment by any CLI/UI tools etc. This has been partially addressed by the new-for-liberty nested validation heat feature, but there's still a bunch of unsolved complexity around how to actually consume that data and build a coherent consolidated API for user interaction: https://github.com/openstack/heat-specs/blob/master/specs/liberty/nested-validation.rst My question is, where do we draw the line on when to use each interface? My position has always been that we should only use parameter_defaults for the ExtraConfig interfaces, where we cannot know what reasonable parameters are. And for all other "core" functionality, we should accept the increased template verbosity and wire arguments in from overcloud-without-mergepy. However we've got some patches which fall into a grey area, e.g this SSL enablement patch: https://review.openstack.org/#/c/231930/46/overcloud-without-mergepy.yaml Here we're actually removing some existing (non functional) top-level parameters, and moving them to parameter_defaults. I can see the logic behind it, it does make the templates a bit cleaner, but at the expense of discoverablility of those (probably not implementation dependent) parameters. How do people feel about this example, and others like it, where we're enabling common, but not mandatory functionality? In particular I'm keen to hear from Mainn and others interested in building UIs on top of TripleO as to which is best from that perspective, and how such arguments may be handled relative to the capabilities mapping proposed here: https://review.openstack.org/#/c/242439/ Thanks! Steve __________________________________________________________________________ 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