Open Stack

On 10/17/2013 02:16 AM, Zane Bitter wrote:
> 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?
>
Agreed, but I wanted to remove that from the scope of these blueprints,
with the hope that what is done here will be an enabler for a new
sync/messaging mechanism - or at least not make it harder.

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

I agree you've identified a problem worth solving. The only thing a
component type does in heat-engine is build cloud-init chunks. I'll have
a think about how this can be implemented as something resembling
component providers.