openstack team mailing list archive

[Andrew Bogott <abogott@xxxxxxxxxxxxx>]

Andrew --

Thanks for your comments.  I'm going to start with a screenshot for context:

http://bogott.net/misc/osmpuppet.png

That's what it looks like when you configure an instance using Open 
Stack Manager, which is WikiMedia's VM management interface.  My main 
priority for adding puppet support to Nova is to facilitate the creation 
and control of a GUI much like that one.

On 1/26/12 5:03 PM, Andrew Clay Shafer wrote:
> I'd also like to see more of a service oriented approach and avoid 
> adding tables to nova if possible.
>
> I'm not sure the best solution is to come up with a generic service 
> for $configuration_manager for nova core. I'd rather see these 
> implemented as optional first class extensions.
This sounds intriguing, but I'll plead ignorance here; can you tell me 
more about what this would look like, or direct me to an existing 
analogous service?

> What are you going to inject into the instances exactly? Where does 
> the site.pp live?
This is the question I'm hoping to get feedback on.  Either nova can 
generate a fully-formed site.pp and inject that, or it can pass config 
information as metadata, in which case an agent would need to be running 
on the guest which would do the work of generating the site.pp.  I 
certainly prefer the former but I'm not yet clear on whether or not file 
injection is widely supported.

> I haven't thought about this that much yet, but off the top of my 
> head, but if the instances already have puppet clients and are 
> configured for the puppet master, then the only thing you should need 
> to interact with is the puppet master.

It's definitely the case that all of this could be done via LDAP or the 
puppet master and involve no Nova action at all; that's how WikiMedia's 
system works now.  My aim is to consolidate the many ways we currently 
interact with instances so that we delegate as much authority to Nova as 
possible.  That strikes me as generally worthwhile, but you're welcome 
to disagree :)

> I'm not a fan of the Available, Unavailable, Default, particularly 
> because you are managing state of something that may not be true on 
> the puppet master.
I may be misunderstanding you, or my blueprint may be unclear.  
Available, Unavailable, and Default don't refer to the availability of 
classes on the puppet master; rather, they refer to whether or not a 
class is made available to a nova user for a given instance.  An 
'available' class would appear in the checklist in my screenshot.  An 
Unavailable class would not.  A 'default' class would appear, and be 
pre-checked.  In all three cases the class is presumed to be present on 
the puppet master.

> I also think managing a site.pp is going to be inferior to providing 
> an endpoint that can act as an eternal node tool for the puppet master.
> http://docs.puppetlabs.com/guides/external_nodes.html
In which case nova would interact directly with the puppet master for 
configuration purposes?  (I don't hate that idea, just asking for 
clarification.)

> One other point, that you might have thought of, but I don't see 
> anywhere on the wiki is how to handle the ca/certs for the instances.
I believe this (and your subsequent question) falls under the heading of 
" Instances are presumed to know any puppet config info they need at 
creation time (e.g. how to contact the puppet master). "  Important, but 
outside the scope of this design :)

> Just to reiterate, I'd love to see deeper configuration management 
> integrations (because I think managing instances without them is it's 
> own hell), but I'm not convinced it should be part of core nova per se.
So that I understand your terminology... are extensions like the quotas 
or floating ips considered 'core nova'?

Thanks again for your input!  Clearly it would be best to hash this out 
at the design summit, but I'm hoping to get at least a bit of coding 
done before April :)

-Andrew