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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Coincidentally mtreinish and I were talking today about some Tempest tests that attach/detach a volume and do ssh operations in between. He pointed out that the test_stamp_pattern scenario test has been skipped forever because the device_name is not reliable on the BDM. And that's using a hard-coded device name in tempest.conf [1].
So this would actually fix that test if we updated the test to just get the BDM device information after the attach and use that rather than the hard-coded config option in Tempest that is not likely to work - arguably the test should have been written more dynamically to start with since you're not required to provide a device name when attaching a volume.
[1] http://git.openstack.org/cgit/openstack/tempest/tree/tempest/scenario/test_stamp_pattern.py#n105
-- Thanks, Matt Riedemann __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
