<div dir="ltr">Just to be clear, we are talking about two different cases of complexity.<div><br></div><div><span style="font-size:12.8000001907349px">"""</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">The biggest disconnect in the model seems to be that Neutron assumes</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">you want self service networking. Most of these deploys don't. Or even</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">more importantly, they live in an organization where that is never</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">going to be an option.</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">"""</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div>This is referring to the complexity of the API model for Neutron. While this is a problem that I hope to address by making things like shared networks more useful, it's not really relevant to this particular discussion because the model complexity does not decrease with the switch to Linux bridge.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 16, 2015 at 5:30 PM, Tom Fifield <span dir="ltr"><<a href="mailto:tom@openstack.org" target="_blank">tom@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 17/04/15 03:09, Assaf Muller wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
----- Original Message -----<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
"if linux bridge was a viable nova-network multi-host HA replacement, you'd<br>
be OK with this change?"<br>
<br>
I'd be much more in favor of it. yes. Though I think its a long way from<br>
being there...<br>
<br>
planet openstack has a nice set of articles on how dvr works right now,<br>
</blockquote>
<br>
Thank you :)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and having read through, I think its going to be very difficult to implement<br>
that way with linuxbridge. It uses flow tables pretty heavily. LinuxBridge<br>
has nothing like that as far as I know.<br>
</blockquote>
<br>
To be brutally honest I think that any solution that tries to implement DVR<br>
with Linux bridge will be shot down by the Neutron community. We're already<br>
struggling to maintain DVR, polish it and have it well tested. Adding more<br>
complexity seems outright insane to me and I suspect that others will share<br>
the sentiment.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Because of that, I would expect that as DVR matures, the LinuxBridge<br>
implementation will wither further on the vine. :/<br>
<br>
Just my 2 cents. Ops will probably need to consider the "complexity"<br>
necessary, just like the linux kernel is "complex" but in the end, the<br>
complexity is well worth it.<br>
</blockquote>
<br>
That's what Neutron developers are likely to say.<br>
</blockquote>
<br></span>
... and so we go around in the circle again, because:<br>
<br>
"""<br>
The biggest disconnect in the model seems to be that Neutron assumes<br>
you want self service networking. Most of these deploys don't. Or even<br>
more importantly, they live in an organization where that is never<br>
going to be an option.<br>
"""<br>
<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2015-March/058801.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-March/058801.html</a><br>
<br>
<br>
So, if ops don't need and/or can't use the features the additional complexity provides, there's no way they'll consider the complexity "necessary", and will keep using nova-network :)<br>
<br>
<br>
In addition - we kinda have part of our mission statement that has the words "simple to implement", so it's very rarely OK to say "just eat up the complexity, kthxbai".<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
To get a truly scalable NaaS, which I think is critical, you need advanced<br>
SDN and I'm not convinced LinuxBridge is advanced enough to work long<br>
term...<br>
<br>
Thanks,<br>
Kevin<br>
<br>
________________________________________<br>
From: Tom Fifield [<a href="mailto:tom@openstack.org" target="_blank">tom@openstack.org</a>]<br>
Sent: Wednesday, April 15, 2015 7:09 PM<br>
To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in<br>
DevStack [was: Status of the nova-network to Neutron migration work]<br>
<br>
On 16/04/15 10:54, Fox, Kevin M wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes, but.... if stuff like dvr is the only viable replacement to<br>
nova-network in production, then learning the non representitive config<br>
of neutron with linuxbridge might be misleading/counter productive since<br>
ovs looks very very different.<br>
</blockquote>
<br>
Sure, though on the other hand, doesn't current discussion seem to<br>
indicate that OVS with DVR is not a viable replacement for nova-network<br>
multi-host HA (eg due to complexity), and this is why folks were working<br>
towards linux bridge?<br>
<br>
In essence: if linux bridge was a viable nova-network multi-host HA<br>
replacement, you'd be OK with this change?<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Kevin *<br>
*<br>
------------------------------------------------------------------------<br>
*From:* Tom Fifield<br>
*Sent:* Wednesday, April 15, 2015 5:58:43 PM<br>
*To:* <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
*Subject:* Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the<br>
default in DevStack [was: Status of the nova-network to Neutron<br>
migration work]<br>
<br>
<br>
<br>
On 14/04/15 23:36, Dean Troyer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Apr 14, 2015 at 7:02 AM, Miguel Angel Ajo Pelayo<br>
<<a href="mailto:mangelajo@redhat.com" target="_blank">mangelajo@redhat.com</a> <mailto:<a href="mailto:mangelajo@redhat.com" target="_blank">mangelajo@redhat.com</a>>> wrote:<br>
<br>
Why would operators install from devstack? that’s not going to be<br>
the case.<br>
<br>
<br>
If they do they need more help than we can give...<br>
</blockquote>
<br>
So, ummm, there is actually a valid use case for ops on devstack: it's<br>
part of the learning process.<br>
<br>
In my rounds, I've had feedback from more than a few whose first<br>
OpenStack experience was to run up a devstack, so they could run ps<br>
aufx, brctl, iptables, etc just to see what was going on under the<br>
covers before moving on to something more 'proper'.<br>
<br>
<br>
While acknowledging that the primary purpose and audience of devstack is<br>
and should remain development and developers, if there is something we<br>
can do to improve the experience for those ops first-timers that doesn't<br>
have a huge impact on devs, it would be kinda nice.<br>
<br>
After all, one of the reasons this thread exists is because of problems<br>
with that ramp up process, no?<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I believe we should have both LB & OVS well tested, if LB is a good<br>
option for<br>
some operators willing to migrate from nova, that’s great, let’s<br>
make sure LB<br>
is perfectly tested upstream.<br>
<br>
<br>
+1<br>
<br>
But by doing such change we can’t let OVS code rot and we would be<br>
neglecting<br>
a big customer base which is now making use of the openvswitch<br>
mechanism.<br>
(may be I’m miss understanding the scope of the change).<br>
<br>
<br>
Changing DevStack's default doesn't remove anything OVS-related, nor<br>
does it by itself remove any OVS jobs. It gives everyone who is happy<br>
with nova-net (or more correctly doesn't think about it) a new default<br>
that changes their experience the least for when nova-net disappears.<br>
<br>
dt<br>
<br>
--<br>
<br>
Dean Troyer<br>
<a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a> <mailto:<a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a>><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" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><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" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>