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