Open Stack

On Mon, Jun 29, 2015 at 04:42:00PM -0400, Jay Dobies wrote:
> >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/

Thanks for all the great feedback!

So, based on your (and others) feedback, I've revised it to more of a
discovery based model, where we add an optional new annotation to HOT:

 resource_type_mapping:
   resource_type: OS::TripleO::Controller

This is analogous to the "subsitution_mappings" section defined in TOSCA,
but renamed to make it a bit more HOT-ish:

This would then be discoverable via heatclient, e.g:

heat resource-find-template OS::TripleO::Controller

which might return:

puppet/controller.yaml
docker/controller.yaml
...

And heat would enforce type->mapping when validating the resource_registry.

We could make heatclient support discovering via local filesystem, URL and
Swift bucket (it already supports getting templates via all these).

I've also taken a first-pass at the recursive validation spec discussed in
my other thread:

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

Thanks for the help defining this so far, any further feedback or ideas
much appreciated! :)

Steve