Open Stack

On 17 April 2015 at 21:35, Jeremy Stanley <fungi at yuggoth.org> wrote:

> On 2015-04-17 11:49:23 -0700 (-0700), Kevin Benton wrote:
> > I definitely understand that. But what is the major complaint from
> > operators? I understood that quote to imply it was around
> > Neutron's model of self-service networking.
>
> My takeaway from Tom's message was that there was a concern about
> "complexity" in all forms (not just of the API but also due to the
> lack of maturity, documentation and debuggability of the underlying
> technology), and that the self-service networking model was simply
> one example of that. Perhaps I was reading between the lines too
> much because of prior threads on both the operators and developers
> mailing lists. Anyway, I'm sure Tom will clarify what he meant if
> necessary.
>
> > If the main reason the remaining Nova-net operators don't want to
> > use Neutron is due to the fact that they don't want to deal with
> > the Neutron API, swapping some implementation defaults isn't
> > really going to get us anywhere on that front.
>
> This is where I think the subthread has definitely wandered off
> topic too. Swapping implementation defaults in DevStack because it's
> quicker and easier to get running on the typical
> all-in-one/single-node setup and faster to debug problems with
> (particularly when you're trying to work on non-network-related bits
> and just need to observe the network communication between your
> services) doesn't seem like it should have a lot to do with the
> recommended default configuration for a large production deployment.
> One size definitely does not fit all.
>
> > It's an important distinction because it determines what
> > actionable items we can take (e.g. what Salvatore mentioned in his
> > email about defaults). Does that make sense?
>
> It makes sense in the context of the Neutron/Nova network parity
> topic, but not so much in the context of the DevStack default
> settings topic. DevStack needs a simple default that just works, and
> doesn't need the kitchen sink. You can turn on more complex options
> as you need to test them out. In some ways this has parallels to the
> complexity concerns the operator community has over Neutron and OVS,
> but I think they're still relatively distinct topics.
>

I think this is the crux of this thread, which is drifting off in the wrong
direction.
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.
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.

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.

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.

Salvatore


> --
> Jeremy Stanley
>
> __________________________________________________________________________
> 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/20150417/ef48d09d/attachment.html>