Open Stack

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.

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