Open Stack

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 ;)

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

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

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.

cheers,
Zane.


[1] https://en.wikipedia.org/wiki/COMEFROM