----- Original Message -----
> From: "Jeremy Stanley" <fu...@yuggoth.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Sent: Friday, April 17, 2015 9:35:07 PM
> Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in
> DevStack [was: Status of the nova-network
> to Neutron migration work]
>
> 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.
>
IMHO the OVS is less complex than netfilter (iptables, *tables),
if someone able to deal with reading the netfilter rules
he should be able to deal with OVS as well.
OVS has debugging tools for internal operations, I guess you are looking
for something else.
I do not have any `good debugging` tool for net-filter either.
The way how openstack/neutron/devstack by default uses OVS is simpler,
than most small (non openstack related) OVS example trying to explain.
I kind of agree with the lack of documentation part.
A documentation which explains howto use OVS
in same way as neutron does would be helpfull for new comers.
> > 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.
> --
> Jeremy Stanley
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
