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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
