openstack team mailing list archive

[Belmiro Moreira <moreira.belmiro.email.lists@xxxxxxxxx>]

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 <abogott@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>