-
-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposed solution for #447 #499
Comments
@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). |
Points are good with me. Just not sure about 2 separate fields. Right now Instead, near the |
Ok, I suppose that might be a little messier on the probe side but cleaner on the API side and overall makes sense. |
#447 my proposed solution after consultation with @MartinKolarik :
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
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
OPTION 1
os.networkInterfaces()
returns all available network interfacesOPTION 2
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)
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
The text was updated successfully, but these errors were encountered: