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-requ...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
