Open Stack

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 <sfinucan at redhat.com>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170719/941e2d4e/attachment.html>