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

Mooney, Sean K sean.k.mooney at intel.com
Mon Jun 13 12:26:03 UTC 2016



> -----Original Message-----
> From: Daniel P. Berrange [mailto:berrange at redhat.com]
> Sent: Monday, June 13, 2016 1:12 PM
> To: Armando M. <armamig at gmail.com>
> Cc: Carl Baldwin <carl at ecbaldwin.net>; OpenStack Development Mailing
> List <openstack-dev at lists.openstack.org>; Jay Pipes
> <jaypipes at gmail.com>; Maxime Leroy <maxime.leroy at 6wind.com>; Moshe Levi
> <moshele at mellanox.com>; Russell Bryant <rbryant at redhat.com>; sahid
> <sahid.ferdjaoui at redhat.com>; Mooney, Sean K <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>
> 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      -o-
> http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-
> manager.org :|
> |: http://autobuild.org       -o-
> http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-
> vnc :|


More information about the OpenStack-dev mailing list