Avoid sending SIGUSR1 when ComputeDomain update only removes nodes

[AkshatDudeja77]

While reading IMEXDaemonUpdateLoopWithDNSNames in compute-domain-daemon/main.go, I noticed the TODO suggesting that we might skip sending SIGUSR1 to the IMEX daemon when the updated daemon set only removes nodes:

// TODO: review skipping this also if the new set of IP addresses only strictly removes
// addresses compared to the old set (then we don't need to force the daemon to re-resolve & re-connect).

Currently UpdateDNSNameMappings() only returns a boolean indicating whether the mapping changed, so the caller cannot distinguish between:

• nodes being added
• nodes being removed
• both

As a result the loop always sends SIGUSR1 whenever the mapping changes.

One possible approach could be extending UpdateDNSNameMappings() to compute the diff between the previous and new ipToDNSName maps, allowing the caller to detect additions vs removals and skip the signal when the update only removes nodes.

Before experimenting with a change here, I wanted to check whether this optimization is still desirable, or if there are reasons the current behavior is preferred.

[jgehrcke]

I wanted to check whether this optimization is still desirable

Yeah, but it might be slightly pointless-ish in itself.

The inverse perspective may be more important in the long run: when we know that IMEX daemons must re-connect to their remote ends (re-resolve DNS names) then we should find a way to guarantee that (and the 5-second signal handler rate limit in the IMEX daemon plays a role here). What I just described is a different task which needs to be thought about with care. When done properly, it would also take care of this 'todo' item that you've centered this issue around.

[AkshatDudeja77]

@jgehrcke Got it, so this is more of a "nice to have" than something that actually matters on its own.

The rate-limit angle is interesting though, hadn't thought about that side of it. I'll look into the reconnection guarantee problem separately