Open Stack

> I had originally been thinking of it like slagle describes, from the
> child up to the parent as well. What I like about that approach is that
> it achieves a more pluggable model when you think about extensions that
> aren't accepted or applicable in TripleO upstream.
>
> If someone comes along and adds a new ControllerConfig to your above
> example, they have to edit whatever environment you're talking about
> that defines the constraints (I'm call it overcloud-something.yaml for
> now).
>
> This becomes a problem from a packaging point of view, especially when
> you factor in non-TripleO integrators (without revealing too much inside
> baseball, think partner integrations). How do I add in an extra package
> (RPM, DEB, whatever) that provides that ControllerConfig and have it
> picked up as a valid option?
>
> We don't want to be editing the overcloud-something.yaml because it's
> owned by another package and there's the potential for conflicts if
> multiple extra implementations start stepping on each other.
>
> An interface/discovery sort of mechanism, which I agree is more complex,
> would be easier to work with in those cases.

I'm effectively replying to my own e-mail here, but I've expressed these 
thoughts on the spec and it'd probably be better to continue this train 
of thought there:

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