[openstack-dev] [nova] Device tagging: rebuild config drive upon instance reboot to refresh metadata on it

Clint Byrum clint at fewbar.com
Mon Feb 20 14:42:50 UTC 2017


Excerpts from Artom Lifshitz's message of 2017-02-20 08:23:09 -0500:
> Config drive over read-only NFS anyone?
> 
> 
> A shared filesystem so that both Nova and the guest can do IO on it at the
> same time is indeed the proper way to solve this. But I'm afraid of the
> ramifications in terms of live migrations and all other operations we can
> do on VMs...
> 

What makes anyone think this will perform better than the metadata
service?

If we can hand people an address that is NFS-capable, we can hand them
an HTTP(S) URL that doesn't have performance problems.

> 
> Michael
> 
> On Sun, Feb 19, 2017 at 6:12 AM, Steve Gordon <sgordon at redhat.com> wrote:
> 
> > ----- Original Message -----
> > > From: "Artom Lifshitz" <alifshit at redhat.com>
> > > To: "OpenStack Development Mailing List (not for usage questions)" <
> > openstack-dev at lists.openstack.org>
> > > Sent: Saturday, February 18, 2017 8:11:10 AM
> > > Subject: Re: [openstack-dev] [nova] Device tagging: rebuild config drive
> > upon instance reboot to refresh metadata on
> > > it
> > >
> > > In reply to Michael:
> > >
> > > > We have had this discussion several times in the past for other
> > reasons.
> > > > The
> > > > reality is that some people will never deploy the metadata API, so I
> > feel
> > > > like we need a better solution than what we have now.
> > >
> > > Aha, that's definitely a good reason to continue making the config
> > > drive a first-class citizen.
> >
> > The other reason is that the metadata API as it stands isn't an option for
> > folks trying to do IPV6-only IIRC.
> >
> > -Steve
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 



More information about the OpenStack-dev mailing list