openstack team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

On Thu, 15 Dec 2011, McNally, Dave wrote:

> Thanks for the responses guys.
>
> Jesse I can see how there might be concerns around using file injection
> but it seems as if that was chosen as a method of inserting
> user-specified metadata into an instance which is why I was wondering
> why it wasn't expanded to use the same process to insert files?

The biggest flaw in this is that it expects that the host can read a
filesystem of the guest.  That is simply *guaranteed* to result in a case
where this is broken for future guests (which use btrfs, btrfs2.0 or
smoserFS-1.2).

I'm happy that a network based metadata service is generally seen as the
smartest solution.  This way its up to the guest to fit into the cloud,
no changes to the hypervisors or openstack have to be made to support
specific guests.

>
> Dave
>
> -----Original Message-----
> From: Jesse Andrews [mailto:anotherjesse@xxxxxxxxx]
> Sent: 15 December 2011 08:34
> To: Jay Pipes
> Cc: McNally, Dave; 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.
>
> 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
>
>