A dhcp resync can be triggered at a number of points, but the actual
resync is done asynchronously by a helper thread. This means by the
time the resync happens, it's hard to establish what actually caused
it.
There have been a number of problems in production systems that cause
excessive resyncs. One is a ipv6/dnsmasq issue (rhbz#1077487) and
another is db corruption with duplicate entries [1]. The resync
triggers a whole lot of logs itself, so it becomes very unclear how to
establish any causality.
This change keeps track of what triggered the resync with some helpful
information. We add a schedule_resync() function to to replace a
explicit set of needs_resync which tracks why it was called.
[1] The logs will contain output like "DBDuplicateEntry
(IntegrityError) (1062, "Duplicate entry
'6d799c6a-7a09-4c1e-bb63-7d30fd052c8a-d3e3ac5b-9962-428a-a9f8-6b2' for
key 'PRIMARY'") ..." in this case
Closes-Bug: #1294445
Change-Id: I9b1c6202f5a6bbad8589a8b64b2a38c9d9edb43b
f199a7b1f0