Open Stack

On Thu, 2015-11-19 at 16:16 +0000, Steven Hardy wrote:
> On Mon, Nov 16, 2015 at 08:15:48PM +0100, Giulio Fidente wrote:
> > On 11/16/2015 04:25 PM, Steven Hardy wrote:
> > > 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).
> > 
> > [...]
> > 
> > > How do people feel about this example, and others like it, where
> > > we're
> > > enabling common, but not mandatory functionality?
> > 
> > At first I was thinking about something as simple as: "don't use
> > top-level
> > params for resources which the registry doesn't enable by default".
> > 
> > It seems to be somewhat what we tried to do with the existing
> > pluggable
> > resources.
> > 
> > Also, not to hijack the thread but I wanted to add another question
> > related
> > to a similar issue:
> > 
> >   Is there a reason to prefer use of parameters: instead of
> > parameter_defaults: in the environment files?
> > 
> > It looks to me that by defaulting to parameter_defaults: users
> > won't need to
> > update their environment files in case the parameter is moved from
> > top-level
> > into a specific nested stack so I'm inclined to prefer this. Are
> > there
> > reasons not to?
> 
> The main reason is scope - if you use "parameters", you know the data
> flow
> happens via the parent template (e.g overcloud-without-mergepy) and
> you
> never have to worry about naming collisions outside of that template.
> 
> But if you use parameter_defaults, all parameters values defined that
> way
> are effectively global, and you then have to be much more careful
> that you
> never shadow a parameter name and get an unexpected value passed in
> to it.
> 
> Here's another example of why we need to decide this btw:
> 
> https://review.openstack.org/#/c/229471/
> 
> Here, we have some workers parameters, going only into
> controller.yaml -
> this is fine, but the new options are completely invisible to users
> who
> look at the overcloud_without_mergepy parameters schema as their
> interface
> (in particular I'm thinking of any UI here).
> 
> My personal preference is to say:
> 
> 1. Any templates which are included in the default environment (e.g
> overcloud-resource-registry-puppet.yaml), must expose their
> parameters
> via overcloud-without-mergepy.yaml
> 
> 2. Any templates which are included in the default environment, but
> via a
> "noop" implementation *may* expose their parameters provided they are
> common and not implementation/vendor specific.
> 
> 3. Any templates exposing vendor specific interfaces (e.g at least
> anything
> related to the OS::TripleO::*ExtraConfig* interfaces) must not expose
> any
> parameters via the top level template.
> 
> How does this sound?

I'd be fine adding these rules into a HACKING document in tripleo-heat-
templates. Perhaps some of these rules fall into "recommendations"
though as there may be exceptions where we want to break things out.

With the new composable roles stuff I was actually going to try to add
all parameters for each available role to the top level template. See
how that might look here:

https://review.openstack.org/#/c/237370/7/overcloud-without-mergepy.yam
l,cm

This would mean a lot more top level parameters... however I think they
will be grouped nicely so they make sense. The compute.yaml and
controller.yaml templates would be much leaner and when it is all
finished just contain parameters related to creation of the baremetal
server and network settings.

Dan


> 
> This does mean we suffer some template bloat from (1) and (2), but it
> makes
> the job of any UI or other tool requiring user input much easier, I
> think?
> 
> Steve
> 
> _____________________________________________________________________
> _____
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev