Comment 14 for bug 1721223

On 12 October 2017 at 17:31, Robie Basak <email address hidden> wrote:
> What about server use cases that do not have networkd installed? There
> are complex network setups out there, such as HA with
> corosync/pacemaker, OpenStack Neutron, and that kind of thing. If this
> fix were SRU'd, will all of these things in the wild cope with this
> sysctl change?
>
> 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.
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?

> not, is it possible to refrain from tweaking this sysctl knob except for
> users affected by this bug (networkd users using DHCP)?

No, as that is racy.

Code wise it is a lot more risk-prone -> will require rewritting
networkd state machine.

Promoting secondary addresses has been around since 2.6.12 and I'm not
sure why that is not the default, given that if one wants to flush a
subset of ip addresses one can do so using the flush command. And
interent seems to be full of posts where people are surpised that
secondary ip addresses are removed when one removes the oldest one.
There is no kernel API to promote secondary ip address to primary; or
to have multiple primary ip addresses (such that removal / expiry of
one, doesn't affect others that happen to be from the same subnet) or
to explicitly add a secondary ip address.

--
Regards,

Dimitri.