Open Stack

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.
>
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.