Open Stack

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.

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