[openstack-dev] [Neutron][os-vif] Expanding vif capability for wiring trunk ports

Gary Kotton gkotton at vmware.com
Tue Jun 14 04:06:01 UTC 2016


That is already supported in stable/mitaka – please see https://review.openstack.org/#/c/260700/
I agree with Kevin

From: Kevin Benton <kevin at benton.pub>
Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
Date: Monday, June 13, 2016 at 11:59 PM
To: OpenStack List <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron][os-vif] Expanding vif capability for wiring trunk ports

+1. Neutron should already be able to tell Nova which bridge to use for an OVS port.[1] For the Linux bridge implementation it's a matter of creating vlan interfaces and plugging them into bridges like regular VM ports, which is all the responsibility of the L2 agent. We shouldn't need any changes from Nova or os-vif from what I can see.



1. https://github.com/openstack/nova/blob/6e2e1dc912199e057e5c3a5e07d39f26cbbbdd5b/nova/network/neutronv2/api.py#L1618<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_nova_blob_6e2e1dc912199e057e5c3a5e07d39f26cbbbdd5b_nova_network_neutronv2_api.py-23L1618&d=CwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=aLF644Euno1BNoUIMh7bFndKIXDcBjRS2_4IRRAOPd8&s=rZ57uFzphC8svGsKNC-YKhhE9VTkLoNxuEu4oOkJEAQ&e=>

On Mon, Jun 13, 2016 at 5:26 AM, Mooney, Sean K <sean.k.mooney at intel.com<mailto:sean.k.mooney at intel.com>> wrote:


> -----Original Message-----
> From: Daniel P. Berrange [mailto:berrange at redhat.com<mailto:berrange at redhat.com>]
> Sent: Monday, June 13, 2016 1:12 PM
> To: Armando M. <armamig at gmail.com<mailto:armamig at gmail.com>>
> Cc: Carl Baldwin <carl at ecbaldwin.net<mailto:carl at ecbaldwin.net>>; OpenStack Development Mailing
> List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>; Jay Pipes
> <jaypipes at gmail.com<mailto:jaypipes at gmail.com>>; Maxime Leroy <maxime.leroy at 6wind.com<mailto:maxime.leroy at 6wind.com>>; Moshe Levi
> <moshele at mellanox.com<mailto:moshele at mellanox.com>>; Russell Bryant <rbryant at redhat.com<mailto:rbryant at redhat.com>>; sahid
> <sahid.ferdjaoui at redhat.com<mailto:sahid.ferdjaoui at redhat.com>>; Mooney, Sean K <sean.k.mooney at intel.com<mailto:sean.k.mooney at intel.com>>
> Subject: Re: [Neutron][os-vif] Expanding vif capability for wiring trunk
> ports
>
> On Mon, Jun 13, 2016 at 02:08:30PM +0200, Armando M. wrote:
> > On 13 June 2016 at 10:35, Daniel P. Berrange <berrange at redhat.com<mailto:berrange at redhat.com>>
> wrote:
> >
> > > On Thu, Jun 09, 2016 at 05:31:13PM -0600, Carl Baldwin wrote:
> > > > Hi,
> > > >
> > > > You may or may not be aware of the vlan-aware-vms effort [1] in
> > > > Neutron.  If not, there is a spec and a fair number of patches in
> > > > progress for this.  Essentially, the goal is to allow a VM to
> > > > connect to multiple Neutron networks by tagging traffic on a
> > > > single port with VLAN tags.
> > > >
> > > > This effort will have some effect on vif plugging because the
> > > > datapath will include some changes that will effect how vif
> > > > plugging is done today.
> > > >
> > > > The design proposal for trunk ports with OVS adds a new bridge for
> > > > each trunk port.  This bridge will demux the traffic and then
> > > > connect to br-int with patch ports for each of the networks.
> > > > Rawlin Peters has some ideas for expanding the vif capability to
> > > > include this wiring.
> > > >
> > > > There is also a proposal for connecting to linux bridges by using
> > > > kernel vlan interfaces.
> > > >
> > > > This effort is pretty important to Neutron in the Newton
> > > > timeframe.  I wanted to send this out to start rounding up the
> > > > reviewers and other participants we need to see how we can start
> > > > putting together a plan for nova integration of this feature (via
> os-vif?).
> > >
> > > I've not taken a look at the proposal, but on the timing side of
> > > things it is really way to late to start this email thread asking
> > > for design input from os-vif or nova. We're way past the spec
> > > proposal deadline for Nova in the Newton cycle, so nothing is going
> > > to happen until the Ocata cycle no matter what Neutron want  in
> Newton.
> >
> >
> > For sake of clarity, does this mean that the management of the os-vif
> > project matches exactly Nova's, e.g. same deadlines and processes
> > apply, even though the core team and its release model are different
> from Nova's?
> > I may have erroneously implied that it wasn't, also from past talks I
> > had with johnthetubaguy.
>
> No, we don't intend to force ourselves to only release at milestones
> like nova does. We'll release the os-vif library whenever there is new
> functionality in its code that we need to make available to
> nova/neutron.
> This could be as frequently as once every few weeks.
[Mooney, Sean K]
I have been tracking contributing to the vlan aware vm work in
neutron since the Vancouver summit so I am quite familiar with what would have
to be modified to support the vlan trucking. Provided the modifications do not
delay the conversion to os-vif in nova this cycle I would be happy to review
and help develop the code to support this use case.

In the ovs case at lease which we have been discussing here
https://review.openstack.org/#/c/318317/4/doc/source/devref/openvswitch_agent.rst
no changes should be required for nova and all changes will be confined to the ovs
plugin. In is essence check if bridge exists, if not create it with port id,
Then plug as normal.

Again though I do agree that we should focus on completing the initial nova integration
But I don't think that mean we have to exclude other feature enhancements as long as they
do not prevent us achieving that goal.


>
> Regards,
> Daniel
> --
> |: http://berrange.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__berrange.com&d=CwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=aLF644Euno1BNoUIMh7bFndKIXDcBjRS2_4IRRAOPd8&s=Go-7xVc1yP_Ym6LjZZFuyvobsnfiVgda_2Us677ccLA&e=>      -o-
> http://www.flickr.com/photos/dberrange/<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.flickr.com_photos_dberrange_&d=CwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=aLF644Euno1BNoUIMh7bFndKIXDcBjRS2_4IRRAOPd8&s=x9UIEEQ0B4Q8T50x_aQiGAyEv3IHMP7ZSlhBBzct2yQ&e=> :|
> |: http://libvirt.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__libvirt.org&d=CwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=aLF644Euno1BNoUIMh7bFndKIXDcBjRS2_4IRRAOPd8&s=PX17BlN9dq54FyxHlpEFj0tAZNAANmwbCz-_7v243_s&e=>              -o-             http://virt-<https://urldefense.proofpoint.com/v2/url?u=http-3A__virt-2D&d=CwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=aLF644Euno1BNoUIMh7bFndKIXDcBjRS2_4IRRAOPd8&s=zSw6evbd50kY6qXOLbmvIYaNSHhdGWjvrqWagekvd6k&e=>
> manager.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__manager.org&d=CwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=aLF644Euno1BNoUIMh7bFndKIXDcBjRS2_4IRRAOPd8&s=fuoQA8upm3D0d8nTwaGFu_rw8B_ncN24rYJiDgEIOpI&e=> :|
> |: http://autobuild.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__autobuild.org&d=CwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=aLF644Euno1BNoUIMh7bFndKIXDcBjRS2_4IRRAOPd8&s=Jkbd2nsHuyiRWxnMzvK6439_a7J1XyVHAGa2iHX7zHY&e=>       -o-
> http://search.cpan.org/~danberr/<https://urldefense.proofpoint.com/v2/url?u=http-3A__search.cpan.org_-7Edanberr_&d=CwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=aLF644Euno1BNoUIMh7bFndKIXDcBjRS2_4IRRAOPd8&s=KJaO0DvEmEZVq54kkc88G6Akd8zHs5tS-ES_prK1sOw&e=> :|
> |: http://entangle-photo.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__entangle-2Dphoto.org&d=CwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=aLF644Euno1BNoUIMh7bFndKIXDcBjRS2_4IRRAOPd8&s=9mu6yY4fxrHFgL-YNWyYRmwNiLgE7ca_qR7me58PO4w&e=>       -o-       http://live.gnome.org/gtk-<https://urldefense.proofpoint.com/v2/url?u=http-3A__live.gnome.org_gtk-2D&d=CwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=aLF644Euno1BNoUIMh7bFndKIXDcBjRS2_4IRRAOPd8&s=3pQQ3-RX4l-Zo-432pIrqbmgiZY_z8gR3xESlKFhj8A&e=>
> vnc :|
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160614/77ff479e/attachment-0001.html>


More information about the OpenStack-dev mailing list