Steve Baker <[email protected]> wrote on 20.11.2013 09:51:34: > From: Steve Baker <[email protected]> > To: [email protected], > Date: 20.11.2013 09:55 > Subject: Re: [openstack-dev] [Heat] HOT software configuration > refined after design summit discussions > > On 11/20/2013 09:29 PM, Clint Byrum wrote: > > Excerpts from Thomas Spatzier's message of 2013-11-19 23:35:40 -0800: > >> 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. > >> > > Note that os-collect-config is intended to be a light-weight generic > > in-instance agent to do exactly this. Watch for Metadata changes, and > > feed them to an underlying tool in a predictable interface. I'd hope > > that any of the appliers would mostly just configure os-collect-config > > to run a wrapper that speaks os-collect-config's interface. > > > > The interface is defined in the README: > > > > https://pypi.python.org/pypi/os-collect-config > > > > It is inevitable that we will extend os-collect-config to be able to > > collect config data from whatever API these config applier resources > > make available. I would suggest then that we not all go off and reinvent > > os-collect-config for each applier, but rather enhance os-collect-config > > as needed and write wrappers for the other config tools which implement > > its interface. > > > > os-apply-config already understands this interface for obvious reasons. > > > > Bash scripts can use os-apply-config to extract individual values, as > > you might see in some of the os-refresh-config scripts that are run as > > part of tripleo. I don't think anything further is really needed there. > > > > For chef, some kind of ohai plugin to read os-collect-config's collected > > data would make sense.
Thanks for all that information, Clint. Fully agree that we should leverage what is already there instead of re-inventing the wheel. > > > I'd definitely start with occ as Clint outlines. It would be nice if occ > only had to be configured to poll metadata for the OS::Nova::Server to > fetch the aggregated data for the currently available SoftwareAppliers. Yep, sounds like a plan. > > > _______________________________________________ > 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
