Open Stack

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.rao at 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:email at daviey.com]
> Sent: Monday, April 27, 2015 2:35 PM
> To: Bhaskar Rao
> Cc: openstack-qa at lists.openstack.org; openstack at lists.openstack.org
> Subject: Re: [Openstack] config drive on opentack label query
>
>
>
>
> On 27 Apr 2015 09:32, "Bhaskar Rao" <bhaskar.rao at 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 at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>



-- 
Rackspace Australia