Yeah, if one clearly belongs to a single vendor moving is definitely the way to go.
OVS itself is a good example of one that is used by lots of drivers. Since it's in os-vif maybe we should do the same for any others without a clear association (e.g. vif_type='tap' is about as vendor agnostic as you can get). On Wed, Jul 19, 2017 at 3:31 AM, Stephen Finucane <[email protected]> wrote: > On Thu, 2017-07-13 at 07:54 -0600, Kevin Benton wrote: > > On Thu, Jul 13, 2017 at 7:26 AM, Stephen Finucane <[email protected]> > 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 >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
