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
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.
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
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
(BTW I agree with Steve B here, addressing the problem is much more
important to me than any particular solution.)
OpenStack-dev mailing list