proposed solution for #447

[valeria-frckova]

#447 my proposed solution after consultation with @MartinKolarik :

1. communication
   OPTION 1 - before the probe is ready to be used, there will be a new event, in which probe will send info about its supported IP versions, class StatusManager will have extra attribute 'IPversion' - there will be 2 instances of StatusManager for each probe; ProbeMetadata query object might be used as well
   OPTION 2 - socket.data.probe (object returned from buildProbe()) -> the atribute 'status' will split into two statuses independent of each other - 'IPv6status' and 'IPv4status'
   a) handler 'probe:status:update' will manage both IPv4 and IPv6 statuses
   b) handler 'probe:status:update' will split into two handlers 'probe:IPv6status:update' and 'probe:IPv4status:update', each handling one status

• pingTest() will run for both IPv4 and IPv6 statuses every 10 mins (for both OPTIONS 1 and 2)

I suggest option 2b), since in OPTION 1 class StatusManager would have to be duplicated or redesign completely and we cannot rely on the fact that the initial supported ip status won't change over time

2. for figuring out whether a probe runs on dual stack, IPv4 only or IPv6 only there are two options:
   OPTION 1

• function os.networkInterfaces() returns all available network interfaces
• from those non-loopback ones will be filtered
• if any of those interfaces have at least one IPv4 address, it supports IPv4 (analogically for IPv6)
• this will be done once in the beginning or every 10mins in status check
  OPTION 2
• in status check - every 10mins, ping command will be tested for reliable IPv6 addresses (similar as implemented for IPv4 addresses)

I suggest OPTION 2, since OPTION 1 doesn't guarantee that the network is able to reach IPv6/IPv4 address even if it's available within network interfaces (e.g. given IP version is not enabled on the router)

3. there are 2 possibilities of tracking IPV4 and IPv6 statuses on API side
   OPTION 1 in Probe attribute 'status' ('statusIPv4' and 'statusIPv6')
   OPTION 2 in Probe 'stats'

Even though in 'stats' there is a good precedent when tracking number of cores (it is checked every 10mins, however it is not prone to change very often), I suggest tracking it in 'status', because it is more specific for this purpose and IPv4 status is already being tracked this way, so it wouldn't be met with a lot of resistance

[MartinKolarik]

@alexey-yarmosh wdyt? I'm leaning towards using two independent statuses with independent checks (so 1.2 and 2.2, and 3.1 on the API side).

[alexey-yarmosh]

Points are good with me. Just not sure about 2 separate fields. Right now status may also be 'initializing' | 'unbuffer-missing' | 'sigterm' | 'offline' which doesn't make sense to be duplicated in both new fields. Like if I want to find all offline probes what field of two should I use?

Instead, near the status I'd rather add mode: 'both' | 'ipV4Only' | 'ipV6Only' | 'none'. mode may be 'both' | 'ipV4Only' | 'ipV6Only' when status is ready and is none for all other.

[MartinKolarik]

Ok, I suppose that might be a little messier on the probe side but cleaner on the API side and overall makes sense.