You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to think about scenarios where data is missing, so we can't make informed decisions. Some actors already have some fallback mechanism, some don't, but we don't have a place where this is being documented and tracked.
For each major actor we should have go through these steps:
Document the current fallback mechanism, if any. It should include which cases are being considered, for example, when data X is missing, Y is done.
Think if other fallback mechanisms are missing and create issues to implement them.
If some fallback mechanism is missing because of an unimplemented feature, create a feature request to discuss if it is feasible or not.
Data sourcing
TODO
Resampling
The resampler accumulate samples into a buffer, when a resampling period has passed, the samples with a timestamp inside the current window are passed to the resampling function, which produces the final resampled value. If there are no samples in the current window, the resampler produces None as value. So in the case of metric not receiving values for some time (> resampling period) the fallback mechanism is to produce a sample with None as value.
No external dependencies for 2, if we decide to do it there is nothing missing.
Power managing / power distributing
TODO
Config managing
If a configuration file can't be read or has errors, there are no fallback mechanism at the moment (the only fallback will be default values defined by the entities subscribed to the actor).
Possible fallback mechanisms:
Reading the config file could fail. We could have some default configuration passed to the actor a creation time, so that it is sent to the subscribers. Not sure if it provides much more safety than just using the defaults subscribed have configured.
Config update events could be missed if inotify fails (there are known scenarios where it could miss updates). For this case we could save the latest config read, and have a timer to re-read periodically and send updates if it changed.
No external dependencies for 2, if we decide to do it there is nothing missing.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
We need to think about scenarios where data is missing, so we can't make informed decisions. Some actors already have some fallback mechanism, some don't, but we don't have a place where this is being documented and tracked.
For each major actor we should have go through these steps:
Data sourcing
Resampling
None
as value. So in the case of metric not receiving values for some time (> resampling period) the fallback mechanism is to produce a sample withNone
as value.Power managing / power distributing
Config managing
If a configuration file can't be read or has errors, there are no fallback mechanism at the moment (the only fallback will be default values defined by the entities subscribed to the actor).
Possible fallback mechanisms:
No external dependencies for 2, if we decide to do it there is nothing missing.
Beta Was this translation helpful? Give feedback.
All reactions