It puzzles me why we would want to have it configurable. Having it = 0
is just plain bad (it breaks a floating IP roaming around HA routers),
having it = 1 may be unsafe if clients miss the update, having it more
than 3 (the default) is probably wasteful. That makes me think that
maybe we should not have it in the first place.
The patch that introduced the option also introduced the feature itself,
and does not provide any clue around why we would need it:
I125dbc57b90027dc5e99ff0a5d6877843a0b02a5
Maybe the option is in the tree because, in Assaf Muller's words, "we're
a bunch of lazy developers that like to shift the responsibility to our
poor users that have to deal with thousands of configuration options".
I suggest we just move with deprecation and removal here.
Reviewed: https:/ /review. openstack. org/394552 /git.openstack. org/cgit/ openstack/ neutron/ commit/ ?id=6b59cc72a4e ec9fabaf90f0a0a 86b4781a68df17
Committed: https:/
Submitter: Jenkins
Branch: master
commit 6b59cc72a4eec9f abaf90f0a0a86b4 781a68df17
Author: Ihar Hrachyshka <email address hidden>
Date: Mon Nov 7 17:30:18 2016 +0000
Deprecate send_arp_for_ha option
It puzzles me why we would want to have it configurable. Having it = 0
is just plain bad (it breaks a floating IP roaming around HA routers),
having it = 1 may be unsafe if clients miss the update, having it more
than 3 (the default) is probably wasteful. That makes me think that
maybe we should not have it in the first place.
The patch that introduced the option also introduced the feature itself, 0027dc5e99ff0a5 d6877843a0b02a5
and does not provide any clue around why we would need it:
I125dbc57b9
Maybe the option is in the tree because, in Assaf Muller's words, "we're
a bunch of lazy developers that like to shift the responsibility to our
poor users that have to deal with thousands of configuration options".
I suggest we just move with deprecation and removal here.
Change-Id: I9d12b8f4c25ddf 91312153f236915 c0c14302e2d
Related-Bug: #1639879