← Back to team overview

openstack team mailing list archive

Re: nova/puppet blueprint, and some questions

 

I would love to see a first class puppet integration with nova instances.

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.

I'm also not clear on how you think this should work with for Puppet.

What are you going to inject into the instances exactly? Where does the
site.pp live?

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.

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. Unless you are going to have a deeper integration with a puppet
master, I think it is better to just declare the classes you want applied.
If you want a 'default' class, make that in puppet and add it.

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

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 also have a question about how you want to handle multi-tenant
environments? Meta data about the puppet master seems like the thing you
need to configure dynamically on the client, then handle all the class,
variables and CA stuff on the appropriate master.

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.

probably over the 0.02 limit for now, but I'm happy to expand or explore
these ideas to see where they lead.


On Thu, Jan 26, 2012 at 4:29 PM, Andrew Bogott <abogott@xxxxxxxxxxxxx>wrote:

> Oh, and regarding this:
>
>
> On 1/26/12 11:30 AM, Tim Bell wrote:
>
>> I would hope for, at minimum, an implementation for Xen and KVM with, if
>> appropriate, something for lxc too.
>>
>
> That relates directly to the second question in my email:  what
> communication method should I use to pass information between nova and the
> guest OS?  Is there not One True Injector that is currently supported (or
> has plans to be supported) across all hypervisors?
>
>
> -Andrew
>
>
> ______________________________**_________________
> Mailing list: https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~**openstack<https://launchpad.net/~openstack>
> More help   : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>

Follow ups

References