Open Stack

Excerpts from Zane Bitter's message of 2013-10-16 06:16:33 -0700:
> On 16/10/13 00:48, Steve Baker wrote:
> > I've just written some proposals to address Heat's HOT software
> > configuration needs, and I'd like to use this thread to get some feedback:
> > https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config
> > https://wiki.openstack.org/wiki/Heat/Blueprints/native-tools-bootstrap-config
> 
> Wow, nice job, thanks for writing all of this up :)
> 
> > Please read the proposals and reply to the list with any comments or
> > suggestions.
> 
> For me the crucial question is, how do we define the interface for 
> synchronising and passing data from and to arbitrary applications 
> running under an arbitrary configuration management system?
> 
> Compared to this, defining the actual format in which software 
> applications are specified in HOT seems like a Simple Matter of 
> Bikeshedding ;)
> 

Agreed. This is one area where juju excels (making cross-node message
passing simple). So perhaps we should take a look at what works from the
juju model and copy it.

> (BTW +1 for not having the relationships, hosted_on always reminded me 
> uncomfortably of INTERCAL[1]. We already have DependsOn for resources 
> though, and might well need it here too.)
>

Also agreed. The way the new proposal has it, it feels more like
composing a workflow.

> I'm not a big fan of having Heat::Puppet, Heat::CloudInit, Heat::Ansible 
> &c. component types insofar as they require your cloud provider to 
> support your preferred configuration management system before you can 
> use it. (In contrast, it's much easier to teach your configuration 
> management system about Heat because you control it yourself, and 
> configuration management systems are already designed for plugging in 
> arbitrary applications.)
> 

Also agree. Having Heat know too much about anything that has many
implementations is a bit of a layer violation. Heat has an interface,
and we should make it really easy for the popular tools to consume
said interface. I could see us having a separate set of shims, like
heat-puppet, and heat-salt, that are helpers for those systems to consume
data from Heat more smoothly.

> I'd love to be able to put this control in the user's hands by just 
> using provider templates - i.e. you designate PuppetServer.yaml as the 
> provider for an OS::Nova::Server in your template and it knows how to 
> configure Puppet and handle the various components. We could make 
> available a library of such provider templates, but users wouldn't be 
> limited to only using those.
> 

This I don't think I understand well enough to pass judgement on. My
understanding of providers is that they are meant to make templates more
portable between clouds that have different capabilities. Mapping that
onto different CM systems feels like a stretch and presents a few
questions for me. How do I have two OS::Nova::Server's using different
CM systems when I decide to deploy something that uses salt instead of
chef?

As long as components can be composed of other components, then it seems
to me that you would just want the CM system to be a component. If you
find yourself including the same set of components constantly.. just
make a bigger component out of them.