Decide on initial priorities for prototyping

[tigrannajaryan]

The OpAMP spec defines a number of features which do not have to be implemented all at once. We can implement them gradually. It is important to define priorities so that we can deliver the most value in shortest amount of time.

I will post one comment per capability in this thread. Please vote with a +1 (thumb up) for the capability you believe is more important than others. Feel free to also add a comment if you would like expand on why you voted that way.

[tigrannajaryan]

Remote Configuration - ability for the Server to push config to the Agent.

[tigrannajaryan]

Own Telemetry Reporting - ability for the Server to tell the Agent where and how to report its own telemetry.

[tigrannajaryan]

Basic Status Reporting (need a better name for this) - reporting of its identity and properties and probably also of basic current state (healthy?) from Agent to Server. This one is likely a pre-requisite since the rest of the features will want to know the Agent’s identity.

[tigrannajaryan]

Agent’s Connection Settings - management of connection credentials (access tokens, client certificates) used by the Agent.

[tigrannajaryan]

Auto-updates - automatic updates of Agent executable directed by the Server.

[tigrannajaryan]

Addons/Plugins management - pushing of addons to the Agent.

[tigrannajaryan]

@kumoroku FYI.

[jmacd]

Re: #5 (comment)

One way to handle Basic Status Reporting is to specify semantic conventions for monitoring agents, through conventional spans, metrics, and logs. If OpAMP gives control over where the agent sends its telemetry, I think that should be enough, and the rest should be accomplished by specifying how to instrument an agent.

[tigrannajaryan]

Re: #5 (comment)

One way to handle Basic Status Reporting is to specify semantic conventions for monitoring agents, through conventional spans, metrics, and logs. If OpAMP gives control over where the agent sends its telemetry, I think that should be enough, and the rest should be accomplished by specifying how to instrument an agent.

This is true if the goal is to send telemetry: spans, metrics and logs. However, in addition to that telemetry we want the Agent to report its identity (type, version, OS kind/version, etc) without being forced to send any spans, metrics or logs.

In theory we could do it by sending an OTLP Resource that identifies the Agent without including any spans/metrics/logs. However, I think it is not desirable for a couple reasons:

• A lone Resource will look weird without any other spans/logs/metrics looks strange. From the top of my head I don't even know if the Collector will forward such a Resource intact, the OTLP does not define this behavior.
• It is useful to decouple identity reporting from telemetry reporting. The Agent may not report any telemetry (it is an optional capability), but still report identity since other capabilities can be affected by the identity (e.g. server sends a different config to different agent types). It is easy to support sending a list key/value pairs via OpAMP without requiring the Agent to support full telemetry reporting via OTLP.

[tigrannajaryan]

Initial prototyping is done. Closing this.