Multi IP handling

[MartinKolarik]

A side effect of #447 is that probes are now able to switch between multiple IP addresses based on network conditions. This may interfere with our adoption logic in two ways:

• adoption is more complex as the user must enter the correct IP and doesn't know which one that is,
• adopted probes may switch the IP and disappear from the account.

The existing UUIDs are not enough to solve this as they don't survive restarts. Several ideas for solving this:

• have the probe report all of its IPs and identify them by "at least one IP matches" comparison - requires some dash and API changes but solves the problem and might be useful in general,
• make the UUIDs persistent - very easy change but works only for software probes; hardware probes reset their storage and would lose the value after restart, unless we also add support for this in the FW (easy but doesn't work for existing probes),
• base the UUIDs on something that doesn't change - MAC addresses?

We could also reduce the amount of switching by a node setting or entirely disable it and force IPv4 when supported but not sure if that's a good idea.

[jimaek]

have the probe report all of its IPs and identify them by "at least one IP matches" comparison - requires some dash and API changes but solves the problem and might be useful in general,

This is the best option for me. Simple and nice UX

[MartinKolarik]

Simple, not really. It's definitely the hardest of those options, but also the only one that covers all cases, so I'm leaning towards it as well. We might even combine it, as adding persistence to the UUIDs is a nice and easy improvement on top.

[alexey-yarmosh]

E.g. probe supports both IPv4 and IPv6. Yesterday it had IPv4 IP and was used for measurementA. Today it has IPv6 IP and was used for measurementB.

Now we are running two new measurements based on pervious: measurementA' and measurementB'. Ideally we want both new measurements refer to the probe. But since repeated measurements are filtering by IP, IPv4 result will be offline.

To fix this, storing of both IPs of the probe is required. So looks like it need to be implemented anyway.

[MartinKolarik]

Indeed, repeating measurements is also affected by this, but it's the same problem of probe "identity", the UUIDs could be used here as well.

[alexey-yarmosh]

UUIDs refer to device, for example laptop, which I may bring to office and back home every day and change the network. I think in repeating measurement we want to compare networks, which are identified by IPs.

[MartinKolarik]

That's an interesting thought because for the user, it's going to be the same probe in that case, but I agree for measurements, it makes sense to consider them as different.