Open Stack

On Tue, Oct 29, 2013 at 01:50:59PM +0100, Zane Bitter wrote:
> On 28/10/13 14:53, Steven Hardy wrote:
> >On Sun, Oct 27, 2013 at 11:23:20PM -0400, Lakshminaraya Renganarayana wrote:
> >>A few us at IBM studied Steve Baker's proposal on HOT Software
> >>Configuration. Overall the proposed constructs and syntax are great -- we
> >>really like the clean syntax and concise specification of components. We
> >>would like to propose a few minor extensions that help with better
> >>expression of dependencies among components and resources, and in-turn
> >>enable cross-vm coordination. We have captured our thoughts on this on the
> >>following Wiki page
> >>
> >>https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-ibm-response
> >
> >Thanks for putting this together.  I'll post inline below with cut/paste
> >from the wiki followed by my response/question:
> >
> >>E2: Allow usage of component outputs (similar to resources):
> >>There are fundamental differences between components and resources...
> >
> >So... lately I've been thinking this is not actually true, and that
> >components are really just another type of resource.  If we can implement
> >the software-config functionality without inventing a new template
> >abstraction, IMO a lot of the issues described in your wiki page no longer
> >exist.
> >
> >Can anyone provide me with a clear argument for what the "fundamental
> >differences" actually are?
> 
> Here's an argument: Component deployments exist within a server
> resource, so the dependencies don't work in the same way. The static
> part of the configuration has to happen before the server is
> created, but the actual runtime part is created after. So the
> dependencies are inherently circular.

So, good point, but I've been thinking about it from the other perspective:
- Server gets created
- SoftwareConfig is applied to server

So the dependencies need not be circular, you have a SoftwareConfig
resource, which references the Server and the SoftwareConfig definition.

I guess this links back to stevebaker's previous comment tha the thing
applying the software config would need a hosted_on property rather than
OS::Nova::Server specifying a list of configs to apply.

> >My opinion is we could do the following:
> >- Implement software config "components" as ordinary resources, using the
> >   existing interfaces (perhaps with some enhancements to dependency
> >   declaration)
> >- Give OS::Nova::Server a components property, which simply takes a list of
> >   resources which describe the software configuration(s) to be applied
> 
> I think to overcome the problem described above, we would also need
> to create a third type of resource. So we'd have a Configuration, a
> Server and a Deployment. (In dependency terms, these are analogous
> to WaitConditionHandle, Server and WaitCondition, or possibly EIP,
> Server and EIPAssociation.) The deployment would reference the
> server and the configuration, you could pass parameters into it get
> attributes out of it, add explicit dependencies on it &c.

Yep, so that's what I've been thinking too, Angus and I were chatting about
ie earlier, and it seems like aligning with the existing pattern, used by
EIP's and volumes would potentially solve the problem.

However, you can cut out the "ConfigAttachment/ConfigApplier" resource, if
you move to the hosted_on pattern suggested by Steve;

> What I'm not clear on in this model is how much of the configuration
> needs to be built to go onto the server (in the UserData?) before
> the server is created, and how that would be represented in such a
> way as to inherently create the correct dependency relationship
> (i.e. get the _Server_ as well as the Deployment to depend on the
> configuration).

Yeah, so I think at some point, folks will have to make a choice about
their preferred CM tool, and map things in their environment, such that the
server gets built with the stuff required to e.g install the puppet agent
into the instance, which then listens for the config from the config
applier (which would know how to push the config to a puppet master I
guess).

So your environment could be:

resource_registry:
    OS::Heat::Server: OS::Heat::PuppetSlaveServer
    OS::Heat::SoftwareConfig: OS::Heat::PuppetSoftwareConfig

OS::Heat::PuppetSlaveServer could just be a provider resource, which
creates a OS::Nova::Server and installs/configures the puppet client
agents (or chef/salt/whatever).

We could still maintain the status-quo by making the default to use
heat-cfntools, where the initial UserData configures the things needed to
make cfn-hup work, then cfn-hup polls for metadata updates which specify
the config to be applied.

The config you want to deploy could be defined via a (config tool
agnositic) OS::Heat::SoftwareConfig resource, and the server it's applied
to is either explicitly specified (via a parameter to the SoftwareConfig
resource), or derived via allowing constraints to be specified for
resources, similar to parameters (Randall talked about this in Portland
IIRC)

Hopefully that makes some sense ;)

Steve