[openstack-dev] [Nova] Device names supplied to the boot request

Nikola Đipanov ndipanov at redhat.com
Thu Jul 16 19:10:45 UTC 2015


On 07/16/2015 06:35 PM, Matt Riedemann wrote:
> 
> 
> On 7/16/2015 11:47 AM, Nikola Đipanov wrote:
>> On 07/16/2015 11:24 AM, Sean Dague wrote:
>>> On 07/15/2015 01:41 PM, Andrew Laski wrote:
>>>> On 07/15/15 at 12:19pm, Matt Riedemann wrote:
>>> <snip>
>>>>> The other part of the discussion is around the API changes, not just
>>>>> for libvirt, but having a microversion that removes the device from
>>>>> the request so it's no longer optional and doesn't provide some false
>>>>> sense that it works properly all of the time.  We talked about this in
>>>>> the nova channel yesterday and I think the thinking was we wanted to
>>>>> get agreement on dropping that with a microversion before moving
>>>>> forward with the libvirt change you have to ignore the requested
>>>>> device name.
>>>>>
>>>>>  From what I recall, this was supposed to really only work reliably
>>>>> for
>>>>> xen but now it actually might not, and would need to be tested again.
>>>>> Seems we could start by checking the xen CI to see if it is running
>>>>> the test_minimum_basic scenario test or anything in
>>>>> test_attach_volume.py in Tempest.
>>>>
>>>> This doesn't really work reliably for xen either, depending on what is
>>>> being done.  For the xenapi driver Nova converts the device name
>>>> provided into an integer based on the trailing letter, so 'vde' becomes
>>>> 4, and asks xen to mount the device based on that int.  Xen does honor
>>>> that integer request so you'll get an 'e' device, but you could be
>>>> asking for hde and get an xvde or vice versa.
>>>
>>> So this sounds like it's basically not working today. For Linux guests
>>> it really can't work without custom in guest code anyway, given how
>>> device enumeration works.
>>>
>>> That feels to me like we remove it from the API with a microversion, and
>>> when we do that just comment that trying to use this before that
>>> microversion is highly unreliable (possibly dangerous) and may just
>>> cause tears.
>>>
>>
>> The problem with outright banning it is that we still have to support
>> people who want to use the older version meaning all of the code would
>> have to support it indefinitely (3.0 is not even on the horizon), given
>> the shady gains, I can't help but feel that this is needless complexity.
> 
> Huh?  That's what the microversion in the v2.1 API is for - we add a
> microversion that drops support for the device name in the API request,
> if you're using a version of the API before that we log a warning that
> it's unreliable and probably shouldn't be used.  With the microversion
> you're opting in to using it.
> 

so are you saying that we don't have to support actually persisting the
user supplied device names for request that ask for version < N? If so
than my change can be accompanied with a version bump and we're good to go.

If we have to support both and somehow notify the compute that it should
persist the requested device names some of the time, then I am very mich
against that.

IMHO microversions should not be used for fixing utter brokenness, it
should just be fixed. Keeping bug compatibility is not something we
should do IMHO but that's a different discussion.

>>
>> Also, not being able to specify device names would make it impossible to
>> implement certain features that EC2 API can provide, such as overriding
>> the image block devices without significant effort.
> 
> Huh? (x2)  With your change you're ignoring the requested device name
> anyway, so how does this matter?  Also, the ec2 API is moving out of
> tree so do we care what that means for the openstack compute API?
>

Please look at the patch and the bug I link in the follow up email
(copied here for your convenience). It should be clearer then which
features cannot possibly work [1][2].

As for supporting the EC2 API - I don't know the answer to that if we
decide we don't care about them - that's cool with me. Even without that
as a consideration, I still think the current proposed patch is the best
way forward.

[1] https://review.openstack.org/#/c/190324/
[2] https://bugs.launchpad.net/nova/+bug/1370250

>>
>>> ...
>>>
>>> On a slight tangent, probably a better way to provide mount stability to
>>> the guest is with FS labels. libvirt is already labeling the filesystems
>>> it creates, and xenserver probably could as well. The infra folks ran
>>> into an issue yesterday
>>> http://status.openstack.org//elastic-recheck/#1475012 where using that
>>> info was their fix.
>>>
>>
>> I think the reason device_names are exposed in the API is that that was
>> the quickest way to provide a sort of an ID of a block device attached
>> to a certain instance that further API calls can then act upon.
>>
>>> It's not the same thing as deterministic devices, but deterministic
>>> devices really aren't a thing on first boot unless you have guest agent
>>> code, or only boot with one disk and hot plug the rest carefully.
>>> Neither are really fun answers.
>>>
>>>     -Sean
>>>
>>
>>
>> __________________________________________________________________________
>>
>> 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