Github user ProjectMoon commented on the issue:
https://github.com/apache/cloudstack/pull/1908
We have been testing this PR internally for some time now, and we have seen
some strange `arping` issues. We have seen that `/etc/cloudstack/ips.json` on
the router has IPs on them that aren't cleaned up. Since #1908 is now merged,
I'm worried that the changes in this PR will not play well with #1908.
Specifically, we have seen that IPs left over in the `ips.json` file can be
stuck on `"add": true` even if the IP is no longer on the account.
Thus, the code that was added in PR 1907 concerns me:
```
if not address['add'] and not ip.configured():
logging.info("Skipping %s as the add flag is set to %s " %
(address['public_ip'], address['add']))
continue
```
The `if` condition fails in a case we've been investigating. Because our IP
is `"add": true`, but `configured()` returns `False`, the IP gets reconfigured
anyway. This doesn't add the IP to the router's interface, but it _does_ run an
`arping` command (see CsAddress.py). Essentially, if this PR is merged as-is,
we might wind up with a regression on CLOUDSTACK-9500.
I will do a bit of manual testing combining both #1908 and #1907 to see
what happens. It may just be that after restarting the network (and thus
cleaning the router), these issues will vanish.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
