[openstack-dev] [nova] Thoughts on deprecating the legacy bdm v1 API support

Murray, Paul (HP Cloud) pmurray at hpe.com
Thu May 19 09:33:39 UTC 2016


> -----Original Message-----
> From: Matt Riedemann [mailto:mriedem at linux.vnet.ibm.com]
> Sent: 17 May 2016 15:48
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at 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-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list