[openstack-dev] [nova] Availability of device names for operations with volumes and BDM and other features.
ndipanov at redhat.com
Thu Jun 11 09:25:53 UTC 2015
On 06/02/2015 01:39 PM, Alexandre Levine wrote:
> Thank you Nikola.
> We'll be adding the required tickets and will follow your reviews,
> however the person working primarily on this subject (Feodor Tersin) is
> out for his vacation for a couple of weeks so some of our responses
> might be delayed until then. Still we'll try to do whatever can be done
> without him at the time being.
> Best regards,
> Alex Levine
Hi guys - I have some fixes posted 
As said below - reviews, and especially testing would be greatly
appreciated (even before they are merged).
NB: there is still some work needed to fix  on your side even if we
decide that my proposed approach is something we want to go with. See
comments on the bug and the related proposed patch for more information.
> On 5/29/15 11:32 PM, Nikola Đipanov wrote:
>> On 05/29/2015 12:55 AM, Feodor Tersin wrote:
>>> Nicola, i would add some words to Alexandre repsonse.
>>> We (standalone ec2api project guys) have filed some bugs (the main is
>>> ), but we don't know how to fix them since the way Nova's device
>>> names are moved on is unclear for us. Neither BP, nor wiki you've
>>> mentioned above don't explain what was happened with device names in
>>> Other bug which we filed by results of bdm v2 implementation  was
>>> resolved, but the fix returns only two devices (even if more than two
>>> volumes are defined in the image) instead of to write device names to
>>> the image and to return full bdm.
>>> I hope you will clarify this question (Alexandre referred to the patch
>>> with explicit elimination of device names for images).
>>> Also you mentioned that we can still use bdm v1. We do it now for
>>> instance launch, but we would like to switch to v2 to use new features
>>> like blank volumes which are provided by AWS as well. However v2 based
>>> launch has a suspicious feature which i asked about in ML , but no
>>> one answered me. It would be great if you clarify that question too.
>>>  https://bugs.launchpad.net/nova/+bug/1370177
>>>  https://bugs.launchpad.net/nova/+bug/1370265
>> Hey Feodor and Alexandre - Thanks for the detailed information!
>> I have already commented on some of the bugs above and provided a small
>> patch that I think fixes one bit of it. As described on the bug - device
>> names might be a bit trickier, but I hope to have something posted next
>> Help with testing (while patches are in review) would be hugely
>> On 05/28/2015 02:24 PM, Alexandre Levine wrote:
>>> 1. RunInstance. Change parameters of devices during instance booting
>>> from image. In Grizzly it worked so we could specify changed BDM in
>>> parameters, it overwrote in nova DB the one coming from image and then
>>> started the instance with new parameters. The only key for addressing
>>> devices in this use case is the very device name. And now we don't have
>>> it for the volumes in BDM coming from the image, because nova stopped
>>> putting this information into the image.
>>> 2. Devices names for Xen-backed instances to work fully. We should be
>>> able to specify required device names during initial instance creation,
>>> they should be stored into an image when the instance is shapshotted, we
>>> can fetch info and change parameters of such volume during subsequent
>>> operations, and the device names inside the instance should be named
>>> 3. DescribeInstances and DescribeInstanceAttributes to return BDM with
>>> device names ideally corresponding to actual device naming in instance.
>>> 4. DescribeImages and DescribeImageAttributes to return BDM with device
>>> names ideally corresponding to the ones in instance before snapshotting.
>> I think all of the above is pretty much covered by
>>> 5. AttachVolume with the specified device name.
>>> 6. ModifyInstanceAttribute with BDM as parameter.
>>> 7. ModifyImageAttribute with BDM as parameter.
>> I am not sure about these 3 cases - would it be possible to actually
>> report bugs for them as I don't think I have enough information this way.
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev