Open Stack

On 16/10/13 21:02, Clint Byrum wrote:
> Excerpts from Zane Bitter's message of 2013-10-16 06:16:33 -0700:
>> >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.

That's certainly one use, and the main one we've been concentrating on. 
One of the cool things about providers IMHO is that it's a completely 
generic feature, not tied to one particular use case, so it's 
potentially very powerful, possibly in ways that we haven't even thought 
of yet.

So the idea here would be that you have a 
[Puppet|Chef|Salt|Ansible|CFEngine]Server provider template that 
contains an OS::Nova::Server resource with the UserData filled in to 
configure the CM system to start and e.g. grab the component configs 
from the metadata. You then use this template as the provider for one or 
more of your servers, link the components somehow and off you go.

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

You can specify a provider for an individual resource, you don't have to 
map a whole resource type to it in the environment (although you can). 
Even if you did, you could just make up your own resource types (say, 
OS::Custom::ChefServer and OS::Custom::SaltServer).

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

This is a good point, and may well be the way to go. I was thinking that 
the CM system had to be effectively one step higher in the chain than 
the components that run under it, but maybe that's really only true of 
cloud-init.

(BTW I agree with Steve B here, addressing the problem is much more 
important to me than any particular solution.)

cheers,
Zane.