<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 16 June 2016 at 03:33, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div>On 6/13/2016 3:35 AM, Daniel P. Berrange wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
On Thu, Jun 09, 2016 at 05:31:13PM -0600, Carl Baldwin wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Hi,<br>
<br>
You may or may not be aware of the vlan-aware-vms effort [1] in<br>
Neutron.  If not, there is a spec and a fair number of patches in<br>
progress for this.  Essentially, the goal is to allow a VM to connect<br>
to multiple Neutron networks by tagging traffic on a single port with<br>
VLAN tags.<br>
<br>
This effort will have some effect on vif plugging because the datapath<br>
will include some changes that will effect how vif plugging is done<br>
today.<br>
<br>
The design proposal for trunk ports with OVS adds a new bridge for<br>
each trunk port.  This bridge will demux the traffic and then connect<br>
to br-int with patch ports for each of the networks.  Rawlin Peters<br>
has some ideas for expanding the vif capability to include this<br>
wiring.<br>
<br>
There is also a proposal for connecting to linux bridges by using<br>
kernel vlan interfaces.<br>
<br>
This effort is pretty important to Neutron in the Newton timeframe.  I<br>
wanted to send this out to start rounding up the reviewers and other<br>
participants we need to see how we can start putting together a plan<br>
for nova integration of this feature (via os-vif?).<br>
</blockquote>
<br>
I've not taken a look at the proposal, but on the timing side of things<br>
it is really way to late to start this email thread asking for design<br>
input from os-vif or nova. We're way past the spec proposal deadline<br>
for Nova in the Newton cycle, so nothing is going to happen until the<br>
Ocata cycle no matter what Neutron want  in Newton. For os-vif our<br>
focus right now is exclusively on getting existing functionality ported<br>
over, and integrated into Nova in Newton. So again we're not really looking<br>
to spend time on further os-vif design work right now.<br>
<br>
In the Ocata cycle we'll be looking to integrate os-vif into Neutron to<br>
let it directly serialize VIF objects and send them over to Nova, instead<br>
of using the ad-hoc port-binding dicts.  From the Nova side, we're not<br>
likely to want to support any new functionality that affects port-binding<br>
data until after Neutron is converted to os-vif. So Ocata at the earliest,<br>
but probably more like Pxxxx, unless the Neutron conversion to os-vif gets<br>
completed unexpectedly quickly.<br>
<br>
Regards,<br>
Daniel<br>
<br>
</blockquote>
<br></div></div>
+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].<br>
<br>
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).<br>
<br>
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.<br></blockquote><div><br></div>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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Thanks,</div><div class="gmail_quote">Armando<br><div><br></div><div>[1] <a href="https://blueprints.launchpad.net/nova/+spec/neutron-ovs-bridge-name" target="_blank">https://blueprints.launchpad.net/nova/+spec/neutron-ovs-bridge-name</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
[1] <a href="https://specs.openstack.org/openstack/nova-specs/priorities/newton-priorities.html#os-vif-integration" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/nova-specs/priorities/newton-priorities.html#os-vif-integration</a><br>
[2] <a href="http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/prep-for-network-aware-scheduling.html" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/prep-for-network-aware-scheduling.html</a><span><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann</font></span><div><div><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>