Open Stack

On 07/15/15 at 12:19pm, Matt Riedemann wrote:
>
>
>On 7/15/2015 11:23 AM, Nikola Đipanov wrote:
>>I'll keep this email brief since this has been a well known issue for
>>some time now.
>>
>>Problem: Libvirt can't honour device names specified at boot for any
>>volumes requested as part of block_device_mapping. What we currently do
>>is in case they do get specified, we persist them as is, so that we can
>>return them from the API, even though libvirt can't honour them (this
>>leads to a number of issues when we do really on the data in the DB, a
>>very common one comes up when attaching further devices which follow up
>>patches to [1] try to address).
>>
>>There is a proposed patch [1] that will make libvirt disregard what was
>>passed and persist the values it defaults and can honour. This seems
>>contentious because it will change the API behaviour (instance show will
>>potentially return device names other than the ones requested).
>>
>>My take on this is that this is broken and we should fix it. All other
>>ways to fix it, namely:
>>
>>   * reject the request if libvirt is the driver in the API (we can't
>>know where the request will end up really and blocking in the API is
>>bad, plus we would still have to keep backwards compatibility for a long
>>time which means the bug is not really solved, we just have more code
>>for bugs to fester)
>>   * fail the request at the scheduler level (very disruptive , and the
>>question is how do we tell users that this is a legit change, we can't
>>really bump the API version for a compute change)
>>
>>are way more disruptive for little gain.
>>
>>   * There is one more thing we could do that hasn't been discussed - we
>>could store requested_device_name, and always return that from the API.
>>This too adds needless complexity IMO.
>>
>>I think the patch in [1] is a pragmatic solution to a long standing
>>issue that only changes the API behaviour for an already broken
>>interaction. I'd like to avoid needless complexity if it gives us nothing.
>>
>>It would be awesome to get some discussion around this and hopefully get
>>some resolution to this long standing issue. Do let me know if more
>>information/clarification is required.
>>
>>[1] https://review.openstack.org/#/c/189632/
>>
>>__________________________________________________________________________
>>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
>>
>
>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.

>
>I'm not sure about vmware/hyper-v/ironic drivers in nova and how they 
>handle this or if they are just as buggy as the libvirt driver.
>
>-- 
>
>Thanks,
>
>Matt Riedemann
>
>
>__________________________________________________________________________
>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