Open Stack

Kevin Benton wrote:
> I agree with the mtu setting because there isn't much of a downside to
> enabling it. However, the others do have reasons to be disabled.
> 
> csum - requires runtime detection of support for a feature and then auto
> degradation for systems that don't support it. People were against those so
> we have the whole sanity check framework instead. I wouldn't be opposed to
> revisiting that decision, but it's definitely a blocker right now.

Agree - I think the work that can be done here is to do some
self-discovery to see if the system supports it, and enable it.

> dvr - doesn't work in non-VM cases (e.g. floating IP pointing to allowed
> address pair or bare metal host) and consumes more public IPs than legacy
> or HA.

Yes it does have tradeoffs currently. But I like to think back to
Nova-Network. It was extremely common to run it in multi_host=True mode.

Despite the fact that the default is False.

https://github.com/openstack/nova/blob/da019e89976f9673c4f80575909dda3bab3e1a24/nova/network/rpcapi.py#L31

It's been a little while for me since I looked at nova-network (Essex,
Folsom era) so things may have moved around a bit, but that's at least
what I recall.

I'd like to see some grizzled Nova network veterans chime in, but at
least from the operator standpoint the whole pain point for Neutron
(which endangered Neutron's existence for a long time) was the fact that
we didn't have an equivalent feature to multi_host - hence DVR being
written.

So, even Nova may have a couple things turned off by default probably a
majority of deployers have to consciously turn the knob for.

> l2pop - this one is weird because it's an ML2 driver. It makes no sense to
> have it always enabled because an operator could be using an l2pop
> incompatible backend. We also don't have a notion of a driver enabled by
> default so if we did want to do it, it would take a bunch of changes to
> ML2.

I think in this case, the point is - enable L2Pop for things where it
really makes sense. Meaning if you are using a tunnel protocol for
tenant networking, and you do not have something like vxlan multicast
group configured. I don't think Open vSwitch supports it, so in that
deployment model I think we can bet that it should be enabled.

Linux Bridge supports l2pop and vxlan multicast, so even in that case
I'd say - enable l2pop but put good docs in to say "hey if you have
multicast vxlan set up, switch it over to use that instead" 

> Whenever we have a knob, it usually stems from the fact that we don't use
> runtime feature detection or the feature has a tradeoff that doesn't make
> its use obvious in all cases.

Right, but I think we've been very cautious in the past, where we don't
want to make any decision, so we just turn it all off and force
operators to enable it. In some cases we've decided to do nothing and
the result is forcing everyone to make the decision, where a high % of
people end up making the same decision. Perhaps we can use the user
survey and the ops meetups to find options where "80% of people use this option
and have to be proactive and enable it" - and think about turning them
on by default.

It's not cut and dry, but maybe taking a stab at it will help us clarify
which really options really are a toss up between on/off and which
should be defaults.


-- 
Sean M. Collins