Excerpts from Steve Baker's message on 19.11.2013 21:40:54: > From: Steve Baker <[email protected]> > To: [email protected], > Date: 19.11.2013 21:43 > Subject: Re: [openstack-dev] [Heat] HOT software configuration > refined after design summit discussions > <snip> > I think there needs to a CM tool specific agent delivered to the server > which os-collect-config invokes. This agent will transform the config > data (input values, CM script, CM specific specialness) to a CM tool > invocation. > > How to define and deliver this agent is the challenge. Some options are: > 1) install it as part of the image customization/bootstrapping (golden > images or cloud-init) > 2) define a (mustache?) template in the SoftwareConfig which > os-collect-config transforms into the agent script, which > os-collect-config then executes > 3) a CM tool specific implementation of SoftwareApplier builds and > delivers a complete agent to os-collect-config which executes it > > I may be leaning towards 3) at the moment. Hopefully any agent can be > generated with a sufficiently sophisticated base SoftwareApplier type, > plus maybe some richer intrinsic functions.
This is good summary of options; about the same we had in mind. And we were also leaning towards 3. Probably the approach we would take is to get a SoftwareApplier running for one CM tool (e.g. Chef), then look at another tool (base shell scripts), and then see what the generic parts art that can be factored into a base class. > >> The POC I'm working on is actually backed by a REST API which does dumb > >> (but structured) storage of SoftwareConfig and SoftwareApplier entities. > >> This has some interesting implications for managing SoftwareConfig > >> resources outside the context of the stack which uses them, but lets not > >> worry too much about that *yet*. > > Sounds good. We are also defining some blueprints to break down the overall > > software config topic. We plan to share them later this week, and then we > > can consolidate with your plans and see how we can best join forces. > > > > > At this point it would be very helpful to spec out how specific CM tools > are invoked with given inputs, script, and CM tool specific options. That's our plan; and we would probably start with scripts and chef. > > Maybe if you start with shell scripts, cfn-init and chef then we can all > contribute other CM tools like os-config-applier, puppet, ansible, > saltstack. > > Hopefully by then my POC will at least be able to create resources, if > not deliver some data to servers. We've been thinking about getting metadata to the in-instance parts on the server and whether the resources you are building can serve the purpose. I.e. pass and endpoint to the SoftwareConfig resources to the instance and let the instance query the metadata from the resource. Sounds like this is what you had in mind, so that would be a good point for integrating the work. In the meantime, we can think of some shortcuts. > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
