Comment 15 for bug 1721223

On Fri, Oct 13, 2017 at 01:22:23AM -0000, Dimitri John Ledkov wrote:
> > Can networkd be made to work without relying on this sysctl tweak? If
>
> No, as the alternative is what isc-dhcp /sbin/dhcp-client does that is
> flush current dhcp lease IP and add a new IP, meaning that networking
> is dropped =/
> Which to me is horrifying.

This is not an SRU justification, however, as we have been doing this
for decades and it is not a problem in practice, nor a regression from
previous releases.

> Promotion of secondary addresses should actually reduce split-brain
> situations. I don't buy the HA/Neutron argument, as in HA environment
> the underlying nodes have static ip addresses and the management of
> floating ip addresses is not managed by DHCP leases, given the DHCP
> timings and fragility. Are you implying that HA and Neutron rely on
> DHCP lease renew/rebind which can be initiated and spoofed by the
> clients arbitrary?

I think you misunderstand my concern. I'm not talking about DHCP in my
HA use case. I'm talking about whether tweaking the particular sysctl
knob will cause any adverse affects in use cases unrelated to this bug.
All use cases that do unusual things with (layer 3) network
configuration need to be considered or eliminated.

I'm not claiming any particular regression. I'm trying to identify
unknown unknowns ("Regression Potential") here which might happen as a
consequence of tweaking a global sysctl value to change behaviour for
*all* existing users and corresponding use cases in a stable release.