Open Stack

Steve Baker <sbaker at redhat.com> wrote on 20.11.2013 09:51:34:
> From: Steve Baker <sbaker at redhat.com>
> To: openstack-dev at lists.openstack.org,
> 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 <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.
> >>
> > 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>