Re: [openstack-dev] [nova] Thoughts on deprecating the legacy bdm v1 API support
On Tue, May 17, 2016 at 09:48:02AM -0500, Matt Riedemann wrote: > In the live migration meeting today mdbooth and I were chatting about how > hard it is to follow the various BDM code through nova, because you have the > three block_device modules: > > * nova.block_device - dict that does some translation magic > * nova.objects.block_device - contains the BDM(List) objects for RPC and DB > access > * nova.virt.block_device - dict that wraps a BDM object, used for attaching > volumes to instances, updates the BDM.connection_info field in the DB via > the wrapper on the BDM object. This module also has translation logic in it. > > The BDM v1 extension translates that type of request to the BDM v2 model > before it gets to server create, and then passed down to the > nova.compute.api. But there is still a lot of legacy bdm v1 translation > logic spread through the code. > > So I'd like to propose that we deprecate the v1 BDM API in the same vein > that we're deprecating other untested things, like agent-builds, cloudpipe, > certificates, and the proxy APIs. We can't remove the code, but we can > signal to users to not use the API and eventually when we raise the minimum > required microversion >= the deprecation, we can drop that code. Since > that's a long ways off, the earlier we start a deprecation clock on this the > better - if we're going to do it. Given that actual deletion of the code is a long way off regardless, can we at least figure out how to isolate the BDM v1 support so that it only exists in the very top most API entrypoint, and gets immediately converted to v2. That way 95% of nova would not have to know / care about it, even if we don't finally drop v1 for 10 more years. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ 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
Re: [openstack-dev] [nova] Thoughts on deprecating the legacy bdm v1 API support
> -Original Message- > From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com] > Sent: 17 May 2016 15:48 > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Subject: [openstack-dev] [nova] Thoughts on deprecating the legacy bdm v1 > API support > > In the live migration meeting today mdbooth and I were chatting about how > hard it is to follow the various BDM code through nova, because you have > the three block_device modules: > > * nova.block_device - dict that does some translation magic > * nova.objects.block_device - contains the BDM(List) objects for RPC and DB > access > * nova.virt.block_device - dict that wraps a BDM object, used for attaching > volumes to instances, updates the BDM.connection_info field in the DB via > the wrapper on the BDM object. This module also has translation logic in it. > > The BDM v1 extension translates that type of request to the BDM v2 model > before it gets to server create, and then passed down to the > nova.compute.api. But there is still a lot of legacy bdm v1 translation logic > spread through the code. > > So I'd like to propose that we deprecate the v1 BDM API in the same vein > that we're deprecating other untested things, like agent-builds, cloudpipe, > certificates, and the proxy APIs. We can't remove the code, but we can signal > to users to not use the API and eventually when we raise the minimum > required microversion >= the deprecation, we can drop that code. Since > that's a long ways off, the earlier we start a deprecation clock on this the > better - if we're going to do it. > > Does anyone have any issues with this? > No issues, let's do it. Paul Murray > -- > > Thanks, > > Matt Riedemann > > > __ > > 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 __ 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
[openstack-dev] [nova] Thoughts on deprecating the legacy bdm v1 API support
In the live migration meeting today mdbooth and I were chatting about how hard it is to follow the various BDM code through nova, because you have the three block_device modules: * nova.block_device - dict that does some translation magic * nova.objects.block_device - contains the BDM(List) objects for RPC and DB access * nova.virt.block_device - dict that wraps a BDM object, used for attaching volumes to instances, updates the BDM.connection_info field in the DB via the wrapper on the BDM object. This module also has translation logic in it. The BDM v1 extension translates that type of request to the BDM v2 model before it gets to server create, and then passed down to the nova.compute.api. But there is still a lot of legacy bdm v1 translation logic spread through the code. So I'd like to propose that we deprecate the v1 BDM API in the same vein that we're deprecating other untested things, like agent-builds, cloudpipe, certificates, and the proxy APIs. We can't remove the code, but we can signal to users to not use the API and eventually when we raise the minimum required microversion >= the deprecation, we can drop that code. Since that's a long ways off, the earlier we start a deprecation clock on this the better - if we're going to do it. Does anyone have any issues with this? -- Thanks, Matt Riedemann __ 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
