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

Nikola Đipanov ndipanov at redhat.com
Wed Jul 15 16:23:33 UTC 2015

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/

More information about the OpenStack-dev mailing list