Open Stack

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.

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

SoftwareConfig properties:
parameters -> inputs - just because parameters is overloaded already.
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
server -> server
parameters -> input_values - to match the 'inputs' schema property in
SoftwareConfig

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.

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.

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.

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

cheers