[openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
fungi at yuggoth.org
Fri Apr 17 19:35:07 UTC 2015
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
> 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.
More information about the OpenStack-dev