[openstack-dev] [nova] how to address boot from volume failures

Alex Xu soulxu at gmail.com
Thu Oct 1 07:47:44 UTC 2015


2015-10-01 5:45 GMT+08:00 Andrew Laski <andrew at lascii.com>:

> On 09/30/15 at 05:03pm, Sean Dague wrote:
>
>> Today we attempted to branch devstack and grenade for liberty, and are
>> currently blocked because in liberty with openstack client and
>> novaclient, it's not possible to boot a server from volume using just
>> the volume id.
>>
>> That's because of this change in novaclient -
>> https://review.openstack.org/#/c/221525/
>>
>> That was done to resolve the issue that strong schema validation in Nova
>> started rejecting the kinds of calls that novaclient was making for boot
>> from volume, because the bdm 1 and 2 code was sharing common code and
>> got a bit tangled up. So 3 bdm 2 params were being sent on every request.
>>
>> However, https://review.openstack.org/#/c/221525/ removed the ==1 code
>> path. If you pass in just {"vda": "$volume_id"} the code falls through,
>> volume id is lost, and nothing is booted. This is how the devstack
>> exercises and osc recommends booting from volume. I expect other people
>> might be doing that as well.
>>
>> There seem to be a few options going forward:
>>
>> 1) fix the client without a revert
>>
>> This would bring back a ==1 code path, which is basically just setting
>> volume_id, and move on. This means that until people upgrade their
>> client they loose access to this function on the server.
>>
>> 2) revert the client and loose up schema validation
>>
>> If we revert the client to the old code, we also need to accept the fact
>> that novaclient has been sending 3 extra parameters to this API call
>> since as long as people can remember. We'd need a nova schema relax to
>> let those in and just accept that people are going to pass those.
>>
>> 3) fix osc and novaclient cli to not use this code path. This will also
>> require everyone upgrades both of those to not explode in the common
>> case of specifying boot from volume on the command line.
>>
>> I slightly lean towards #2 on a compatibility front, but it's a chunk of
>> change at this point in the cycle, so I don't think there is a clear win
>> path. It would be good to collect opinions here. The bug tracking this
>> is - https://bugs.launchpad.net/python-openstackclient/+bug/1501435
>>
>
> I have a slight preference for #1.  Nova is not buggy here novaclient is
> so I think we should contain the fix there.
>

+1, this is novaclient bug.


>
> Is using the v2 API an option?  That should also allow the 3 extra
> parameters mentioned in #2.
>
>
>
>>         -Sean
>>
>> --
>> Sean Dague
>> http://dague.net
>>
>> __________________________________________________________________________
>> 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
>>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151001/367a01af/attachment.html>


More information about the OpenStack-dev mailing list