Open Stack

Steve Baker <sbaker at redhat.com> wrote on 18.11.2013 21:52:04:
> From: Steve Baker <sbaker at redhat.com>
> To: openstack-dev at lists.openstack.org,
> Date: 18.11.2013 21:54
> Subject: Re: [openstack-dev] [Heat] HOT software configuration
> refined after design summit discussions
>
> On 11/19/2013 02:22 AM, Thomas Spatzier wrote:
> > Hi all,
> >
> > I have reworked the wiki page [1] I created last week to reflect
> > discussions we had on the mail list and in IRC. From ML discussions
last
> > week it looked like we were all basically on the same page (with some
> > details to be worked out), and I hope the new draft eliminates some
> > confusion that the original draft had.
> >
> > [1]
https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-WIP
> >
> Thanks Thomas, this looks really good. I've actually started on a POC
> which maps to this model.

Good to hear that, Steve :-)
Now that we are converging, should we consolidate the various wiki pages
and just have one? E.g. copy the complete contents of
hot-software-config-WIP to your original hot-software-config, or deprecate
all others and make hot-software-config-WIP the master?

>
> I've used different semantics which you may actually prefer some of,
> please comment below.
>
> Resource types:
> SoftwareConfig -> SoftwareConfig (yay!)
> SoftwareDeployment -> SoftwareApplier - less typing, less mouth-fatigue

I'm ok with SoftwareApplier. If we don't hear objections, I can change it
in the wiki.

>
> SoftwareConfig properties:
> parameters -> inputs - just because parameters is overloaded already.

Makes sense.

> Although if the CM tool has their own semantics for inputs then that
> should be used in that SoftwareConfig resource implementation instead.
> outputs -> outputs
>
> SoftwareApplier properties:
> software_config -> apply_config - because there will sometimes be a
> corresponding remove_config

Makes sense, and the remove_config thought is a very good point!

> server -> server
> parameters -> input_values - to match the 'inputs' schema property in
> SoftwareConfig

Agree on input_values.

>
> Other comments on hot-software-config-WIP:
>
> Regarding apply_config/remove_config, if a SoftwareApplier resource is
> deleted it should trigger any remove_config and wait for the server to
> acknowledge when that is complete. This allows for any
> evacuation/deregistering workloads to be executed.
>
> I'm unclear yet what the SoftwareConfig 'role' is for, unless the role
> specifies the contract for a given inputs and outputs schema? How would
> this be documented or enforced? I'm inclined to leave it out for now.

So about 'role', as I stated in the wiki, my thinking was that there will
be different SoftwareConfig and SoftwareApplier implementations per CM tool
(more on that below), since all CM tools will probably have their specific
metadata and runtime implementation. So in my example I was using Chef, and
'role' is just a Chef concept, i.e. you take a cookbook and configure a
specific Chef role on a server.

>
> It should be possible to write a SoftwareConfig type for a new CM tool
> as a provider template. This has some nice implications for deployers
> and users.

I think provider templates are a good thing to have clean componentization
for re-use. However, I think it still would be good to allow users to
define their SoftwareConfigs inline in a template for simple use cases. I
heard that requirement in several posts on the ML last week.
The question is whether we can live with a single implementation of
SoftwareConfig and SoftwareApplier then (see also below).

>
> My hope is that there will not need to be a different SoftwareApplier
> type written for each CM tool. But maybe there will be one for each
> delivery mechanism. The first implementation will use metadata polling
> and signals, another might use Marconi. Bootstrapping an image to
> consume a given CM tool and applied configuration data is something that
> we need to do, but we can make it beyond the scope of this particular
> proposal.

I was thinking about a single implementation, too. However, I cannot really
imagine how one single implementation could handle both the different
metadata of different CM tools, and different runtime implementation. I
think we would want to support at least a handful of the most favorite
tools, but cannot see at the moment how to cover them all in one
implementation. My thought was that there could be a super-class for common
behavior, and then plugins with specific behavior for each tool.

Anyway, all of that needs to be verified, so working on PoC patches is
definitely the right thing to do. For example, if we work on implementation
for two CM tools (e.g. Chef and simple scripts), we can probably see if one
common implementation is possible or not.
Someone from our team is going to write a provider for Chef to try things
out. I think that can be aligned nicely with your work.

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

>
> cheers
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>