Zane Bitter <zbit...@redhat.com> wrote on 30.10.2013 22:33:31: > From: Zane Bitter <zbit...@redhat.com> > To: openstack-dev@lists.openstack.org, > Date: 30.10.2013 22:36 > Subject: Re: [openstack-dev] [Heat] Comments on Steve Baker's > Proposal on HOT Software Config > > On 30/10/13 20:35, Lakshminaraya Renganarayana wrote: > > >I'd like to see some more detail about how > > > inputs/outputs would be exposed in the configuration management systems > > > - or, more specifically, how the user can extend this to arbitrary > > > configuration management systems. > > > > The way inputs/outputs are exposed in a CM system > > would depend on its conventions. In our use with Chef, we expose these > > inputs and outputs as a Chef's node attributes, i.e., via the node[][] > > hash. I could imagine a similar scheme for Puppet. For a shell type of > > CM provider the inputs/outputs can be exposed as Shell environment > > variables. To avoid name conflicts, these inputs/outputs can be prefixed > > by a namespace, say Heat. > > Right, so who writes the code that exposes the inputs/outputs to the CM > system in that way? If it is the user, where does that code go and how > does it work? And if it's not the user, how would the user accommodate a > CM system that has not been envisioned by their provider? That's what > I'm trying to get at with this question.
I think it is not the user who writes this binding code / glue code, but I envision a handful of component providers for the most common CM systems that implement the logic to (1) take data from Heat, (2) pass them to the CM system invocation, (3) wait for the CM system to report completion, (4) parse return data and pass it to Heat. So this is basically like an adapter, and for each such adapter it would have to be documented like the automation must be writen to work with it. E.g. in bash scripts the user can access all input as environment variables etc, or for Chef there mapping is like Lakshmi described it above. We have something like this implemented internally and I think such an implementation could be added to Heat. For any kind of custom CM system where we do not provide such an adapter, the user would have to write a plugin to handle the same logic. > > cheers, > Zane. > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
