<div dir="ltr">Nicola, i would add some words to Alexandre repsonse.<div><br></div><div>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.</div><div>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.</div><div><br></div><div>I hope you will clarify this question (Alexandre referred to the patch with explicit elimination of device names for images).</div><div><br></div><div>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.</div><div><br></div><div>[1] <a href="https://bugs.launchpad.net/nova/+bug/1370177" target="_blank">https://bugs.launchpad.net/nova/+bug/1370177</a></div><div>[2] <a href="https://bugs.launchpad.net/nova/+bug/1370265" target="_blank">https://bugs.launchpad.net/nova/+bug/1370265</a></div><div>[3] <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-May/063769.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-May/063769.html</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 27, 2015 at 8:55 PM, Nikola Đipanov <span dir="ltr"><<a href="mailto:ndipanov@redhat.com" target="_blank">ndipanov@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05/27/2015 09:47 AM, Alexandre Levine wrote:<br>
> Hi all,<br>
><br>
> I'd like to bring up this matter again, although it was at some extent<br>
> discussed during the recent summit.<br>
><br>
> The problem arises from the fact that the functionality exposing device<br>
> names for usage through public APIs is deteriorating in nova. It's being<br>
> deliberately removed because as I understand, it doesn't universally and<br>
> consistently work in all of the backends. It happens  since IceHouse and<br>
> introduction of bdm v2. The following very recent review is one of the<br>
> ongoing efforts in this direction:<br>
> <a href="https://review.openstack.org/#/c/185438/" target="_blank">https://review.openstack.org/#/c/185438/</a><br>
><br>
<br>
</span>I've abandoned the change as it is clear we need to discuss how to go<br>
about this some more.<br>
<br>
But first let me try to give a bit more detailed explanation and<br>
background to what the deal is with device names. Supplying device names<br>
that will be honoured by the guests is really only possible with Xen PV<br>
guests (meaning the guest needs to be running PV-enabled kernel and<br>
drivers).<br>
<br>
Back in Havana, when we were working on [1] (see [2] for more details)<br>
the basic idea was that we will still accept device names because<br>
removing them from the public API is not likely to happen (mostly<br>
because of the EC2 compatibility), but in case of libvirt driver, we<br>
will treat them as hints only, and provide our own (by mostly<br>
replicating the logic libvirt uses to order devices [3]). We also<br>
allowed for device names to not be specified by the user as this is<br>
really what anyone not using the EC2 API should be doing (users using<br>
the EC2 API do however need to be aware the fact that i may not be<br>
honoured).<br>
<br>
[1]<br>
<a href="https://blueprints.launchpad.net/nova/+spec/improve-block-device-handling" target="_blank">https://blueprints.launchpad.net/nova/+spec/improve-block-device-handling</a><br>
[2] <a href="https://wiki.openstack.org/wiki/BlockDeviceConfig" target="_blank">https://wiki.openstack.org/wiki/BlockDeviceConfig</a><br>
[3]<br>
<a href="https://github.com/openstack/nova/blob/master/nova/virt/libvirt/blockinfo.py" target="_blank">https://github.com/openstack/nova/blob/master/nova/virt/libvirt/blockinfo.py</a><br>
<span class=""><br>
> The reason for my concern is that EC2 API have some important cases<br>
> relying on this information (some of them have no workarounds). Namely:<br>
> 1. Change of parameters set by image for instance booting.<br>
> 2. Showing instance's devices information by euca2ools.<br>
> 3. Providing additional volumes for instance booting<br>
> 4. Attaching volume<br>
> etc...<br>
><br>
<br>
</span>So based on the above - it seems to me that you think we are removing<br>
the information about device names completely. That's not the case -<br>
currently it is simply not mandatory for the Nova boot API call (it was<br>
never mandatory for volume attach afaict) - you can still pass it in,<br>
though libvirt may not honour it. It will still be tracked by the Nova<br>
DB and available for users to refer to.<br>
<span class=""><br>
> Related to device names and additional related features we have troubles<br>
> with now:<br>
> 1. All device name related features<br>
<br>
</span>As I said - they are not removed, in addition, you can still completely<br>
disregard the BDMv2 syntax as Nova should transparently handle old-style<br>
syntax when passed in (actually since BDM info is stored with images<br>
when snapshotting and it may have been v1 syntax - it is likely that we<br>
will never remove this support). If you are seeing some bugs related to<br>
this - please report them.<br>
<span class=""><br>
> 2. Modification of deleteOnTermination flag<br>
<br>
</span>I don't have enough details on this but if some behaviour has changed<br>
when using the old syntax - it is likely a bug so please report it.<br>
<span class=""><br>
> 3. Modification of parameters for instance booting<br>
<br>
</span>Again - I am not sure what this is related to exactly - but none of the<br>
parameters have changed really (only new ones were added). It would be<br>
good to get more information on this (preferably a bug report).<br>
<span class=""><br>
> 4. deleteOnTermination and size of volume aren't stored into instance<br>
> snapshots now.<br>
><br>
<br>
</span>This does sound like a bug - and hopefully an easy to fix one.<br>
<span class=""><br>
> Discussions during the summit on the matter were complicated because<br>
> nobody present really understood in details why and what is happening<br>
> with this functionality in nova. It was decided though, that overall<br>
> direction would be to add necessary features or restore them unless<br>
> there is something really showstopping:<br>
> <a href="https://etherpad.openstack.org/p/YVR-nova-contributor-meetup" target="_blank">https://etherpad.openstack.org/p/YVR-nova-contributor-meetup</a><br>
><br>
> As I understand, Nikola Depanov is the one working on the matter for<br>
> some time obviously is the best person who can help to resolve the<br>
> situation. Nikola, if possible, could you help with it and clarify the<br>
> issue.<br>
><br>
> My suggestion, based on my limited knowledge at the moment, still is to<br>
> restore back or add all of the necessary APIs and provide tickets or<br>
> known issues for the cases where the functionality is suffering from the<br>
> backend limitations.<br>
><br>
> Please let me know what you think.<br>
><br>
<br>
</span>As explained above - nothing was intentionally removed, and if something<br>
broke - it's a bug that we should fix, so I urge the team behind the EC2<br>
API on stackforge to report those, and I will try to at least look into<br>
them, if not fix them. We might want to have a tag for EC2 related bugs<br>
in LP (I seem to remember there being such a thing before).<br>
<br>
Device names though are not something we can easily resolve without<br>
having the users of the EC2 API be aware that they may be talking to a<br>
Nova deployment, however I am unsure how much of a problem this is in<br>
practice, as I believe most users would have to be anyway.<br>
<br>
Hope this lifts some of the mystery around the topic - and I look<br>
forward to helping the EC2 efforts - but we really need to make sure we<br>
have the issues written down first :)<br>
<span class="HOEnZb"><font color="#888888"><br>
N.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>