Hi Andrew and others, first of all sorry for my previous email. (seems I sent a unfinished email)
The idea of integrating nova with "configuration management tools" (puppet, chef, ...) is very interesting. But in my opinion we shouldn't have a specific implementation to a single tool or a small set of tools. In general Nova should facilitate the interaction with external tools (not only "configuration management tools"). In my view this could be achieved using: -> consistent contextualization method: The contextualization of new instances per project is crucial. We should have a "easy" way to transfer files into new instances early at boot time. I think documenting the blueprint could be a good start: https://blueprints.launchpad.net/nova/+spec/configuration-drive Because "injecting" files and metadata will always be image dependent. -> API extension: If nova API allowed the execution of "external scripts" when some operations (create, delete, ...) are performed the integration with external tools would be easier. --- What you have in your screenshot is really interesting but it seems very similar to other tools already implemented to manage puppet modules, ex: "Foreman". Belmiro Moreira CERN On Fri, Jan 27, 2012 at 2:56 AM, Andrew Bogott <abog...@wikimedia.org> wrote: > 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 > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
