<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 17 April 2015 at 21:35, Jeremy Stanley <span dir="ltr"><<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.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="">On 2015-04-17 11:49:23 -0700 (-0700), Kevin Benton wrote:<br>
> I definitely understand that. But what is the major complaint from<br>
> operators? I understood that quote to imply it was around<br>
> Neutron's model of self-service networking.<br>
<br>
</span>My takeaway from Tom's message was that there was a concern about<br>
"complexity" in all forms (not just of the API but also due to the<br>
lack of maturity, documentation and debuggability of the underlying<br>
technology), and that the self-service networking model was simply<br>
one example of that. Perhaps I was reading between the lines too<br>
much because of prior threads on both the operators and developers<br>
mailing lists. Anyway, I'm sure Tom will clarify what he meant if<br>
necessary.<br>
<span class=""><br>
> If the main reason the remaining Nova-net operators don't want to<br>
> use Neutron is due to the fact that they don't want to deal with<br>
> the Neutron API, swapping some implementation defaults isn't<br>
> really going to get us anywhere on that front.<br>
<br>
</span>This is where I think the subthread has definitely wandered off<br>
topic too. Swapping implementation defaults in DevStack because it's<br>
quicker and easier to get running on the typical<br>
all-in-one/single-node setup and faster to debug problems with<br>
(particularly when you're trying to work on non-network-related bits<br>
and just need to observe the network communication between your<br>
services) doesn't seem like it should have a lot to do with the<br>
recommended default configuration for a large production deployment.<br>
One size definitely does not fit all.<br>
<span class=""><br>
> It's an important distinction because it determines what<br>
> actionable items we can take (e.g. what Salvatore mentioned in his<br>
> email about defaults). Does that make sense?<br>
<br>
</span>It makes sense in the context of the Neutron/Nova network parity<br>
topic, but not so much in the context of the DevStack default<br>
settings topic. DevStack needs a simple default that just works, and<br>
doesn't need the kitchen sink. You can turn on more complex options<br>
as you need to test them out. In some ways this has parallels to the<br>
complexity concerns the operator community has over Neutron and OVS,<br>
but I think they're still relatively distinct topics.<br></blockquote><div><br></div><div>I think this is the crux of this thread, which is drifting off in the wrong direction.</div><div>For devstack defaults, I'd say even with OVS "it just works" imho, but my opinion is partial and also I've been using OVS for 4 years now. So I don't count.</div><div>I accept the desire to default to a data plane technology whose stability is proven by decades of use in production systems, and has probably still a wider adoption compared with OVS.</div><div><br></div><div>The discussion about simple networking with neutron, whether the operator needs or not to provide self-service networking, and whether OVS is good or yet another piece of software junk, is super interesting. However it does not belong to this thread.</div><div><br></div><div>I believe there are a few fairly valid reasons for which devstack is less likely to fail with default params using linux bridge rather than OVS - then let's default to linux bridge. At the end of the day I believe users interested in OVS will find in a simple way in the documentation - possibly even in the README file, a way for enabling it. We might even ship a local.conf.ovs file with a ready to use alternate, ovs-based configuration.</div><div><br></div><div>Salvatore</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">--<br>
Jeremy Stanley<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>
</div></div></blockquote></div><br></div></div>