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... 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 > -- Rackspace Australia __________________________________________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170220/acf7379c/attachment.html>