openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #06416
Re: Metadata and File Injection
> -----Original Message-----
> From: openstack-bounces+ewan.mellor=citrix.com@xxxxxxxxxxxxxxxxxxx
> [mailto:openstack-bounces+ewan.mellor=citrix.com@xxxxxxxxxxxxxxxxxxx]
> On Behalf Of Jesse Andrews
> Sent: 15 December 2011 00:34
> To: Jay Pipes
> Cc: openstack@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Openstack] Metadata and File Injection
>
> Great question.
>
> Right now there are 3 approaches to metadata/runtime config:
>
> * ec2 metadata service - http://169.254.169.254/ (used by ubuntu's
> cloud-init for example)
> * config drive - added in diablo
> * xenstore via openstack agent - https://launchpad.net/openstack-
> guest-agents
> * injecting files into the filesystem prior to launch - on some
> hypervisors / filesystems combinations
>
> There are issues with each approach currently:
>
> * metadata service - requires that cloud uses DHCP to configure
> network
> * config drive - only sets values at runtime and no support from any
> guests
> * xenstore approach - hypervisor specific.
> * injecting into filesystem - brittle as it requires the host to
> support arbitrary filesystems
>
> If we assume that instance networking can be configured by DHCP, then
> a metadata service is probably our best choice for simplicity of
> implementation and user experience.
>
> Given that Rackspace Public Cloud is the only openstack developer/user
> (I know of) that doesn't use DHCP for network configuration of
> instances, I reached out to the team to see if DHCP would be an
> option. They are researching either a way use DHCP _or_ propose an
> approach to initial network configuration that can be executed by the
> openstack guest agent.
Rackspace aren't the only people to have problems with DHCP. I have encountered a number of enterprises where DHCP is expressly forbidden inside the datacenter (for good reasons or stupid ones, that's not important). As OpenStack becomes more popular as a private cloud, this could be an issue.
You could compromise by saying that network configuration could be done by XenStore / config drive / file injection, but go no further than network configuration. Everything else can then be done with a metadata service. With that scheme, if you're using DHCP then you only need the metadata service, and if you're not then you have just this one niggle to sort out. At least all the richer stuff would be done off the metadata service then.
The only downside to that plan is it would be preferable if customer support operations (reset root password, maybe others) could be done on a live system without relying on networking being configured correctly. With a root password and a text console you should be able to fix anything else on a live system. Anything deader than that is going to need a reboot into a rescue image anyway. So maybe I'd put reset root password in the "niggle" category too.
Ewan.
>
> Based on those conversations we've been writing a proposal that would
> recommend guests use a (currently non-existing) openstack metadata api
> - http://wiki.openstack.org/guest-configuration
>
> Hope this helps.
>
> Thoughts on the optimal experience for essex?
>
> On Wed, Dec 14, 2011 at 9:28 AM, Jay Pipes <jaypipes@xxxxxxxxx> wrote:
> > On Wed, Dec 14, 2011 at 9:04 AM, McNally, Dave <dave.mcnally@xxxxxx>
> wrote:
> >> Hi,
> >>
> >> I've recently been looking at file and metadata injection in Nova
> and I have
> >> a question relating to it.
> >>
> >> (BTW this is based off what I have seen in nova/virt/disk.py)
> >>
> >> I notice that for key/value pairs specified as metadata during boot
> of an
> >> instance these values are injected into a file /meta.js in the
> instance.
> >> However if a file (and corresponding injection location) are
> specified when
> >> booting the instance the file does not get injected.
> >
> > Not on libvirt/KVM. It works on Xen, though:
> >
> > https://bugs.launchpad.net/nova/+bug/755168
> >
> >> I was wondering if there was an intentional decision not to use a
> similar
> >> method to that used when injecting meta.js to inject other files?
> Because it
> >> seems to me the addition of such functionality would be fairly
> >> straightforward.
> >
> > I'm interested in the answer to this question as well...
> >
> >> Also on a vaguely related note why is the metadata injected into a
> file
> >> rather than stored in a location where it can be retrieved from the
> metadata
> >> service?
> >
> > No idea. :(
> >
> > Cheers,
> > -jay
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~openstack
> > More help : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
Follow ups
References