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

Armando M. armamig at gmail.com
Thu Jun 16 04:16:22 UTC 2016

On 16 June 2016 at 03:33, Matt Riedemann <mriedem at linux.vnet.ibm.com> wrote:

> On 6/13/2016 3:35 AM, Daniel P. Berrange 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.
>> Regards,
>> Daniel
> +1. Nova is past non-priority spec approval freeze for Newton. With
> respect to os-vif it's a priority to integrate that into Nova in Newton [1].
> We're also working on refactoring how we allocate and bind ports when
> creating a server [2]. This is a dependency for the routed networks work
> and it's also going to bump up against the changes I'm making in nova for
> get-me-a-network in Newton (which is another priority).
> So if vlan-aware-vms changes how nova allocates/binds ports, that's going
> to be dependent on this also, and will have to be worked into the Ocata
> release from Nova's POV.

If my understanding is correct, everything that was required in Nova was
done in the context of [1], which completed in Mitaka. What's left is the
os-vif part: if os-vif is not tied to the Nova release cycle or the
spec/blueprint approval and freeze process and the change in question is
trivial, then I hope we can make an effort to pull it off. After all, the
review effort required would be roughly the same to the one involved to pay
participate to this thread.

Now, if the review process unveiled loose ends and changes that are indeed
required to Nova, then I'd agree we should not change priorities.


[1] https://blueprints.launchpad.net/nova/+spec/neutron-ovs-bridge-name

> [1]
> https://specs.openstack.org/openstack/nova-specs/priorities/newton-priorities.html#os-vif-integration
> [2]
> http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/prep-for-network-aware-scheduling.html
> --
> Thanks,
> Matt Riedemann
> __________________________________________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160616/4be4a2ff/attachment-0001.html>

More information about the OpenStack-dev mailing list