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