<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. </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>