The name "config-2" (always lowercase) is hard coded in nova/virt/configdrive.py. It would change if we came up with a new format for the config drive, which I think is unlikely at this point in time. A conversion to uppercase is presumably a VFAT thing, and outside the control of nova.
So, if you make your volume name check case insensitive, you should be ok. Michael On Mon, Apr 27, 2015 at 7:10 PM, Bhaskar Rao <bhaskar....@citrix.com> wrote: > Hi Dave, > > > > When we try to boot our VM we mount the label config-2 and access its > contents, > > But it is seen that in some customer deployments, the label has different > name (ex: CONFIG-2), hence our code breaks. > > We want to make sure, if it is always config-2 ?? on what basis it can > change ?? or is it set at some location in Openstack config files ?? > > > > Thanks > > Bhaskar > > > > > > > > > > From: Dave Walker [mailto:em...@daviey.com] > Sent: Monday, April 27, 2015 2:35 PM > To: Bhaskar Rao > Cc: openstack...@lists.openstack.org; openstack@lists.openstack.org > Subject: Re: [Openstack] config drive on opentack label query > > > > > On 27 Apr 2015 09:32, "Bhaskar Rao" <bhaskar....@citrix.com> wrote: >> >> Hi All, >> >> >> >> With help of user data files, we can provide instance specific details >> (like IP address, Gateway etc.) to VM booting in OpenStack environment. >> >> This user data file gets attached with VM as part of specific label for >> example config-2. >> >> >> >> We want to know how this labeling mechanism works? Who decides to give >> name ‘config-2’ to use for supplied info? >> >> Is there any possibility that instead of ‘config-2’, it can use another >> name e.g. ‘config-x’? >> >> >> >> Thanks, >> >> Bhaskar >> > > Hi, > > The name is specifically crafted for config-drive version 2. The reference > consumer of this is cloud-init (on linux), but other projects such as > cloudbase-init (on windows), also consume this standard. This standard was > originally written for OpenStack. > > Version 2 was created due to short fallings with the original spec, and both > of these consumers specifically match on the device being named 'config-v2' > to avoid miss-parsing the wrong device. Therefore changing the name in the > hard coded portion of nova would break the consumers. > > To flip the topic slightly, why would you want to use a different named > device? What are you trying to do? > > -- > Kind Regards, > Dave Walker > > > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > -- Rackspace Australia _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
