Open Stack

On Monday, June 13, 2016 6:28 AM, Daniel P. Berrange wrote:
> 
> On Mon, Jun 13, 2016 at 07:39:29AM -0400, Assaf Muller wrote:
> > On Mon, Jun 13, 2016 at 4:35 AM, 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 os-vif our focus right now is exclusively on getting
> > > existing functionality ported over, and integrated into Nova in
> > > Newton. So again we're not really looking to spend time on further os-vif
> design work right now.
> > >
> > > In the Ocata cycle we'll be looking to integrate os-vif into Neutron
> > > to let it directly serialize VIF objects and send them over to Nova,
> > > instead of using the ad-hoc port-binding dicts.  From the Nova side,
> > > we're not likely to want to support any new functionality that
> > > affects port-binding data until after Neutron is converted to
> > > os-vif. So Ocata at the earliest, but probably more like Pxxxx,
> > > unless the Neutron conversion to os-vif gets completed unexpectedly
> quickly.
> >
> > In light of this feature being requested by the NFV, container and
> > baremetal communities, and that Neutron's os-vif integration work
> > hasn't begun, does it make sense to block Nova VIF work? Are we
> > comfortable, from a wider OpenStack perspective, to wait until
> > possibly the P release? I think it's our collective responsibility as
> > developers to find creative ways to meet deadlines, not serializing
> > work on features and letting processes block us.
> 
> Everyone has their own personal set of features that are their personal
> priority items. Nova evaluates all the competing demands and decides on
> what the project's priorities are for the given cycle. For Newton Nova's
> priority is to convert existing VIF functionality to use os-vif. Anything else vif
> related takes a backseat to this project priority. This formal modelling of VIFs
> and developing a plugin facility has already been strung out over at least 3
> release cycles now. We're finally in a position to get it completed, and we're
> not going to divert attention away from this, to other new features requests
> until its done as that'll increase the chances of it getting strung out for yet
> another release which is in no ones interests.

I think we are all in agreement that integrating os-vif into Nova during the Newton cycle is the highest priority.

The question is, once os-vif has been integrated into Nova are we going to have any problem augmenting the current os-vif OvsPlugin in order to support vlan-aware-vms in the Newton release? Based upon the current Nova integration patch [1] I believe that any vif-plugging changes required to implement vlan-aware-vms could be entirely localized to the os-vif OvsPlugin, so Nova wouldn't directly need to be involved there.

That said, there are currently a couple of vif-plugging strategies we could go with for wiring trunk ports for OVS, each of them requiring varying levels of os-vif augmentation:
Strategy 1) When Nova is plugging a trunk port, it creates the OVS trunk bridge, attaches the tap to it, and creates one patch port pair from the trunk bridge to br-int.
Strategy 2) Neutron passes a bridge name to Nova, and Nova uses this bridge name to create the OVS trunk bridge and attach the tap to it (no patch port pair plugging into br-int).

Strategy 1 requires the most augmentation to the os-vif OvsPlugin, because it is basically mimicking the current plug_ovs_hybrid strategy that creates a linux bridge and hooks it into br-int using a veth pair. The difference is that it will use an OVS bridge instead of a linux bridge and connect it to br-int using a patch port pair rather than a veth pair. Optionally, Neutron could pass extra information to os-vif to support the "use_veth_interconnection" option and use veth pairs rather than patch port pairs.

Strategy 2 requires less augmentation to the os-vif OvsPlugin, because it will only require creating the specified OVS bridge if it doesn't exist already.

Both strategies have pros and cons to weigh, but Strategy 2's biggest pro is that it's more likely to be accepted into os-vif because it's much simpler. The problem is that it breaks the current "Nova is responsible for plugging new ports into br-int" paradigm, which means that we would have to introduce new functionality into the OVS agent in order to monitor for Nova/os-vif's creation (and deletion) of new trunk bridges. Using strategy 1, we can take advantage of the current L2 agent extension framework to cleanly implement this trunk functionality for the OVS agent, because it will be triggered by the addition of a new port to br-int. See [2] for an idea of how this simpler L2 agent extension would look if we end up going with Strategy 1.

If neither of these strategies would be in danger of not making it into the Newton release, then I think we should definitely opt for Strategy 1 because it leads to a simpler overall solution. If only Strategy 2 is feasible enough to make it into os-vif for Newton, then we need to know ASAP so that we can start implementing the required functionality for the OVS agent to monitor for dynamic trunk bridge creation/deletion.

[1] https://review.openstack.org/#/c/269672
[2] https://review.openstack.org/#/c/328526/1

> 
> 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 :|
> 
> __________________________________________________________
> ________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev