Re: [openstack-dev] How should we go about removing legacy VIF types in Queens?

[Kevin Benton]

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 
wrote:

> On Thu, 2017-07-13 at 07:54 -0600, Kevin Benton wrote:
> > On Thu, Jul 13, 2017 at 7:26 AM, Stephen Finucane 
> 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=nope==
> [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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] How should we go about removing legacy VIF types in Queens?

[Stephen Finucane]

On Thu, 2017-07-13 at 07:54 -0600, Kevin Benton wrote:
> On Thu, Jul 13, 2017 at 7:26 AM, Stephen Finucane 
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=nope==
[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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] How should we go about removing legacy VIF types in Queens?

[Kevin Benton]

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?


On Thu, Jul 13, 2017 at 7:26 AM, Stephen Finucane 
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.
>
> Cheers,
> Stephen
>
> [1] https://github.com/openstack/nova/blob/6205a3f8c/nova/virt/
> libvirt/vif.py#L
> 599-L764
> [2] https://github.com/openstack/nova/blob/6205a3f8c/nova/
> network/os_vif_util.p
> y#L346-L403
> [3] https://github.com/Juniper/contrail-nova-vif-driver
> [4] https://bugs.launchpad.net/networking-bigswitch/+bug/1704129
>
> __
> 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] How should we go about removing legacy VIF types in Queens?

[Stephen Finucane]

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.

Cheers,
Stephen

[1] https://github.com/openstack/nova/blob/6205a3f8c/nova/virt/libvirt/vif.py#L
599-L764
[2] https://github.com/openstack/nova/blob/6205a3f8c/nova/network/os_vif_util.p
y#L346-L403
[3] https://github.com/Juniper/contrail-nova-vif-driver
[4] https://bugs.launchpad.net/networking-bigswitch/+bug/1704129

__
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