[openstack-dev] How should we go about removing legacy VIF types in Queens?
Stephen Finucane
sfinucan at redhat.com
Wed Jul 19 10:31:43 UTC 2017
On Thu, 2017-07-13 at 07:54 -0600, Kevin Benton wrote:
> On Thu, Jul 13, 2017 at 7:26 AM, Stephen Finucane <sfinucan at redhat.com>
wrote:
>
> > os-vif has been integrated into nova since the newton cycle. With the
> > integration of os-vif, the expectation is that all the old, non-os-vif
> > plugging/unplugging code found in [1] will be replaced by code that
> > harnesses
> > os-vif plugins [2]. This has happened for a few of the VIF types, and newer
> > VIFs are being added in this manner [3]. However, there are quite a few
> > VIFs
> > that are still using the legacy path, and I think it's about time we
> > started
> > moving things forward. Doing so allows us to continue to progress on
> > passing
> > os-vif objects from neutron and remove the large swathes of legacy code
> > still
> > found in nova.
> >
> > I've opened a bug against networking-bigswitch [4] for one of these VIF
> > types,
> > IVS, and I'm thinking I'll do the same for a lot of the other VIF types
> > where I
> > can find definite vendors. Is there anything else we can do though? At some
> > point we're going to have to just start deleting code and I'd like to avoid
> > leaving operators in the lurch.
>
> Some of the stuff like '802.1qbh' isn't particularly vendor specific so I'm
> not sure who will host it and a repo just for that seems like a bit much.
> Should we just bite the bullet and convert them in the nova tree or put them
> in os-vif?
That VIF type actually seems to be a CISCO-only option [1][2] but I get what
you're saying. I think we can definitely move some of them, though (IVS, for a
start). Perhaps moving the ones that *do* have clear owners to their respective
packages is the way to go?
Stephen
[1] http://codesearch.openstack.org/?q=802.1qbh&i=nope&files=&repos=
[2] https://git.openstack.org/cgit/openstack/networking-cisco/tree/networking_c
isco/plugins/ml2/drivers/cisco/ucsm/constants.py
More information about the OpenStack-dev
mailing list