← Back to team overview

openstack team mailing list archive

Re: nova/puppet blueprint, and some questions

 

Ya, I would agree strongly with this.
Making openstack puppet specific seems bad in the long run (not everyone wants/needs puppet).
This especially is apparent with having puppet tables in the nova database.
Something more generic maybe can be thought about?

On 1/26/12 11:30 AM, "Tim Bell" <Tim.Bell@xxxxxxx> wrote:



Looks interesting.

I wonder if it can be made more generic so that it would satisfy a similar
set of requirements for Chef (or whatever else comes along).  I would
suspect that the general requirements for tables etc. are not puppet
specific, although the implementations may vary.

I would hope for, at minimum, an implementation for Xen and KVM with, if
appropriate, something for lxc too.

Tim

-----Original Message-----
From: openstack-bounces+tim.bell=cern.ch@xxxxxxxxxxxxxxxxxxx
[mailto:openstack-bounces+tim.bell=cern.ch@xxxxxxxxxxxxxxxxxxx] On Behalf Of
Andrew Bogott
Sent: 26 January 2012 19:26
To: openstack@xxxxxxxxxxxxxxxxxxx
Subject: [Openstack] nova/puppet blueprint, and some questions

Happy tag day, everyone!

     The next thing I'm going to work on (for Nova/Folsom) is adding an API
to assist with Puppet configuration on nova instances.  The blueprint for
that is here:

http://wiki.openstack.org/PuppetConfigForNova

     I welcome comments on that proposal.

     There's a fair bit of hand-waving in the Implementation section when it
comes to the question of how exactly Nova will communicate puppet config to
an instance.  Ideally I would like to use file injection to drop a site.pp
file directly onto the instance.  My fear, though, is that file injection is
not supported widely enough for me to rely on it.  Is that right?  Are there
plans to support file injection on non-Xen hypervisors (most importantly, on
KVM?)
     If I can't rely on file injection, then I probably need to use metadata
instead.  Is metadata injection more widely supported than file injection?
And, is there any kind of 'standard' pattern for instance daemons that
notice and respond to metadata changes (e.g. the guest agents module), or
would I just adlib that part?

Thanks!

-Andrew


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp


References