Open Stack

Excerpts from Steve Baker's message on 19.11.2013 21:40:54:
> From: Steve Baker <sbaker at redhat.com>
> To: openstack-dev at lists.openstack.org,
> 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>