Allow timestamping gnmi notifications locally #8420
Conversation
sjwang90
added
feat
|
No worries. Looks quite good already. :-) |
|
ok, I updated the docs, I'll let you know when I have an update on the CCLA. That will probably be next week. |
|
Code looks good. Waiting for the administrative requirements... :-) |
Sometimes it can be useful to use a local, on receive timestamp for gnmi notifications. This is the case for sample subscriptions. The gnmi spec requires that the update timestamps are the time when the value from the underlying data source (e.g. counter hardware) changed. This value might not change for a long time, resulting in a timestamp way back in the past. For such situations, it can be useful to use the current time on the server, turning the semantics of the timestamp into "This was the value on the device at time T according to the collector" from "This was when the value last changed on the device." Fixes influxdata#8411
|
the CCLA from Arista and my personal CCL are now all submitted, I gave the changes a rebase + conflict resolution just now to the latest telegraph master |
srebhan
added
the
ready for final review
|
gentle bump? |
|
I'm wondering if this should just be a processor plugin. This comes up many times across a lot of different plugins. |
|
@rski you've not been forgotten. :-) The guys are about to release 1.17 and PRs merges are held back until the release is done AFAIK. |
|
@srebhan hello, several of us are looking forward for this merge :-) |
sjwang90
removed
the
ready for final review
|
If anyone is looking for this feature on gnmi specifically, pleas use the builds from above. I would like to close this for now. If anyone would like to work on #8689 for local timestamping to be used across plugins more generally we would gladly welcome a PR. |
Sometimes it can be useful to use a local, on receive timestamp for
gnmi notifications. This is the case for sample subscriptions. The
gnmi spec requires that the update timestamps are the time when the
value from the underlying data source (e.g. counter hardware) changed.
This value might not change for a long time, resulting in a timestamp
way back in the past. For such situations, it can be useful to use the
current time on the server, turning the semantics of the timestamp
into "This was the value on the device at time T according to the
collector" from "This was when the value last changed on the device."
Fixes #8411
Required for all PRs: