> Date: Thu, 16 Jul 2015 20:10:45 +0100 > From: ndipa...@redhat.com > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Nova] Device names supplied to the boot request > > On 07/16/2015 06:35 PM, Matt Riedemann wrote: > > > > > > On 7/16/2015 11:47 AM, Nikola Đipanov wrote: > >> On 07/16/2015 11:24 AM, Sean Dague wrote: > >>> On 07/15/2015 01:41 PM, Andrew Laski wrote: > >>>> On 07/15/15 at 12:19pm, Matt Riedemann wrote: > >>> <snip> > >>>>> 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. > >>>> > >>>> This doesn't really work reliably for xen either, depending on what is > >>>> being done. For the xenapi driver Nova converts the device name > >>>> provided into an integer based on the trailing letter, so 'vde' becomes > >>>> 4, and asks xen to mount the device based on that int. Xen does honor > >>>> that integer request so you'll get an 'e' device, but you could be > >>>> asking for hde and get an xvde or vice versa. > >>> > >>> So this sounds like it's basically not working today. For Linux guests > >>> it really can't work without custom in guest code anyway, given how > >>> device enumeration works. > >>> > >>> That feels to me like we remove it from the API with a microversion, and > >>> when we do that just comment that trying to use this before that > >>> microversion is highly unreliable (possibly dangerous) and may just > >>> cause tears. > >>> > >> > >> Also, not being able to specify device names would make it impossible to > >> implement certain features that EC2 API can provide, such as overriding > >> the image block devices without significant effort. > > > > Huh? (x2) With your change you're ignoring the requested device name > > anyway, so how does this matter? Also, the ec2 API is moving out of > > tree so do we care what that means for the openstack compute API? > > > > Please look at the patch and the bug I link in the follow up email > (copied here for your convenience). It should be clearer then which > features cannot possibly work [1][2]. > > As for supporting the EC2 API - I don't know the answer to that if we > decide we don't care about them - that's cool with me. Even without that > as a consideration, I still think the current proposed patch is the best > way forward. > > [1] https://review.openstack.org/#/c/190324/ > [2] https://bugs.launchpad.net/nova/+bug/1370250 I confirm that your patch for bdm overloading does work correctly. I posted a link into your review on appropriate functional test [1] Nova EC2 is deprecated, but standalone ec2api is actual. Nova team promised: "Where needed, we will work this those projects to extending the Nova API such that its possible to add that functionality on top of the Nova API." [2] This (support of standalone ec2api) is the first reason to keep device names in API. The second reason is that the overloading feature is useful for native Nova users as well.Really if they have a standard image with multiple devices, the overloading feature provides a simpler way to boot an instance with small changes of standard devices. Than to create a new image with modified bdms, run the instance, and then manage the new image (keep it or remove). Or to boot from the image and then detach/create/attach devices (and this doesn't work for swap and ephemerals). Clearly AWS provides the simplest way to do this (adjusting, not only overloading). Perhaps sometime Nova will provide this too. As you mentioned above, device names are the only way to address to device for overloading. The third reason is that at least xen supports them.I know that vdr becomes /dev/xvdr, but:1) I believe the main aim of specifying device name is to easy distinguish among devices. A last char is enough for that. And xen supports that.2) Xen users may use this now.3) We don't know about device name support in VMWare and other hypervisors.4) AWS in its turn also does not warrant that selected name will be the same as requested one [3] So i think Nova could look at a specified device name as at a hint. If a used hypervisor can follow it even partially, Nova honours it.In particular libvirt could sort devices by device name. And obviously i agree with the aim of your patch which persists a true device name. I believe an operator must see true names to have an easy way to associate devices visible from inside guest OS with Cinder volumes and their attributes (like volume type, multiattach ability and so on). [1] https://review.openstack.org/#/c/199172/[2] http://docs.openstack.org/developer/nova/project_scope.html?highlight=proxy#third-party-apis[3] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/block-device-mapping-concepts.html#block-device-mapping-def
__________________________________________________________________________ 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
