[openstack-dev] [TripleO][Heat] Tuskar v. Heat responsibilities

Jay Dobies jason.dobies at redhat.com
Mon Jun 29 20:42:00 UTC 2015

> 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:


More information about the OpenStack-dev mailing list