>1) fix the client without a revert I prefer to go with this option, since fix already done and pending review.
>This means that until people upgrade their >client they loose access to this function on the server. This applies to any of the proposed options. On Thu, Oct 1, 2015 at 12:03 AM, Sean Dague <s...@dague.net> 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 > > -Sean > > -- > Sean Dague > http://dague.net > > __________________________________________________________________________ > 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 > -- Best regards, Andrey Kurilin.
__________________________________________________________________________ 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