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
>

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