<div><br></div><div>I would love to see a first class puppet integration with nova instances.</div><div><br></div><div>I'd also like to see more of a service oriented approach and avoid adding tables to nova if possible.</div>
<div><br></div><div>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.</div><div><br>
</div><div>I'm also not clear on how you think this should work with for Puppet.</div><div><br></div><div>What are you going to inject into the instances exactly? Where does the site.pp live?</div><div><br></div><div>
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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><a href="http://docs.puppetlabs.com/guides/external_nodes.html">http://docs.puppetlabs.com/guides/external_nodes.html</a></div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>probably over the 0.02 limit for now, but I'm happy to expand or explore these ideas to see where they lead.</div><br><br><div class="gmail_quote">On Thu, Jan 26, 2012 at 4:29 PM, Andrew Bogott <span dir="ltr"><<a href="mailto:abogott@wikimedia.org">abogott@wikimedia.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Oh, and regarding this:<div class="im"><br>
<br>
On 1/26/12 11:30 AM, Tim Bell wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would hope for, at minimum, an implementation for Xen and KVM with, if<br>
appropriate, something for lxc too.<br>
</blockquote>
<br></div>
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?<div class="HOEnZb">
<div class="h5"><br>
<br>
-Andrew<br>
<br>
<br>
______________________________<u></u>_________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~<u></u>openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~<u></u>openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/<u></u>ListHelp</a><br>
</div></div></blockquote></div><br>