[openstack-dev] [nova] Availability of device names for operations with volumes and BDM and other features.

Nikola Đipanov ndipanov at redhat.com
Fri May 29 20:32:44 UTC 2015


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
> [1]), 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 images.
> Other bug which we filed by results of bdm v2 implementation [2] 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 [3], but no
> one answered me. It would be great if you clarify that question too.
> 
> [1] https://bugs.launchpad.net/nova/+bug/1370177
> [2] https://bugs.launchpad.net/nova/+bug/1370265
> [3] http://lists.openstack.org/pipermail/openstack-dev/2015-May/063769.html
> 

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
week.

Help with testing (while patches are in review) would be hugely appreciated!

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.
>
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html
>
> 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
> exactly.
>
> 3. DescribeInstances and DescribeInstanceAttributes to return BDM with
> device names ideally corresponding to actual device naming in instance.
>
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html
>
>
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstanceAttribute.html
>
>
> 4. DescribeImages and DescribeImageAttributes to return BDM with device
> names ideally corresponding to the ones in instance before snapshotting.
>
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeImages.html
>
>
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeImageAttribute.html
>

I think all of the above is pretty much covered by
https://bugs.launchpad.net/nova/+bug/1370177

>
> 5. AttachVolume with the specified device name.
>
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AttachVolume.html
>
> 6. ModifyInstanceAttribute with BDM as parameter.
>
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyInstanceAttribute.html
>
>
> 7. ModifyImageAttribute with BDM as parameter.
>
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyImageAttribute.html

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.

N.



More information about the OpenStack-dev mailing list