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
As is, when registering a subscriber in /etc/tsp-controller/network, the operator is burdened with having to know the correct value of the "dedup" attribute. This "dedup" attribute translates to aggregator's "DropRepeats" setting.
However, practice suggests that "DropRepeats" is subscriber's internal detail. It would be better if the subscriber had a way of communicating its value back to aggregator without any extra human involvement.
One way of doing it would be to provide better specification for the "version" command. For example:
If the response to the "version" command begins with open-curly "{", then it is assumed to be a JSON object that contains overrides for the "Relay" settings, for example:
>>> version
<<< {"DropRepeats": false}
If the "version" command produces any other response, then the subscriber is assumed to be OpenTSDB, and therefore sets DropRepeats to true.
This approach has two nice benefits down the road. Firstly, it finally provides clear semantics for the "version" command, which currently has unacceptably ad hoc handling in the source code. Secondly, it paves the way for potential subscriber-supplied aggregator-side filtering rules, e.g.:
>>> version
<<< {"Filter": [{"Match": "foo", "Block": true}]}
But one must be careful to allow subscriber to override only some of its Relay settings. All other settings should be presumed immutable becase of reliability/security.
The text was updated successfully, but these errors were encountered:
As is, when registering a subscriber in /etc/tsp-controller/network, the operator is burdened with having to know the correct value of the "dedup" attribute. This "dedup" attribute translates to aggregator's "DropRepeats" setting.
However, practice suggests that "DropRepeats" is subscriber's internal detail. It would be better if the subscriber had a way of communicating its value back to aggregator without any extra human involvement.
One way of doing it would be to provide better specification for the "version" command. For example:
This approach has two nice benefits down the road. Firstly, it finally provides clear semantics for the "version" command, which currently has unacceptably ad hoc handling in the source code. Secondly, it paves the way for potential subscriber-supplied aggregator-side filtering rules, e.g.:
But one must be careful to allow subscriber to override only some of its Relay settings. All other settings should be presumed immutable becase of reliability/security.
The text was updated successfully, but these errors were encountered: