-
Notifications
You must be signed in to change notification settings - Fork 35
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
Agent registration process #56
Comments
Following up from the weekly call, we should discuss this next session once @pmm-sumo is back. We'd like to understand more about the scenarios that require the unique ID to be provided by the server. |
Discussed in Workgroup meeting. We can add ability for the Server to command the Agent to use a different UID. We can also make UUID optional in the first message from the Agent. The combination of these 2 features allows to:
|
I promised to prepare a PR with proposal of the spec update, got a bit delayed but should have it this week |
This is a first approach towards #56 It assumes that Agent's `instance_uid` can always be updated by Server (since resolving potential issues with conflicts is important). There's a gap with multiplexed websocket connections which perhaps could be handled by adding Agent capability flag indicating if overrides can be accepted or not
I think #63 resolves this issue. Closing, but feel free to reopen if there is more to do. |
* Add support for detached signatures (open-telemetry#69) Resolves open-telemetry#65 - Added signature field to DownloadableFile message. - Added a short explanation about how the signature field can be used for detached signatures. * Set instance_uid by Server on conflict or request for generation (open-telemetry#63) This is a first approach towards open-telemetry#56 It assumes that Agent's `instance_uid` can always be updated by Server (since resolving potential issues with conflicts is important). There's a gap with multiplexed websocket connections which perhaps could be handled by adding Agent capability flag indicating if overrides can be accepted or not Co-authored-by: Tigran Najaryan <[email protected]> Co-authored-by: Przemek Maciolek <[email protected]>
Currently, OpAMP Client can practically identify itself using two means:
instance_uid
field, included in AgentToServer messageThe UID generation is a concern of the agent, which might limit some use cases where certain formats of UID can be used to identify different groups of agents and as such should be provided by server, also ensuring that two agent instances always use different ID's.
For HTTP authentication, there are different use-cases and sometimes a single set of credentials can be used for a larger group of clients. However, it might be preferred to have an initial, installation-only auth token that is used only to identify the type of the agent and handle the registration after which the agent is provided with a unique token that will be used for any further communication. The unique identifier of the agent can be embedded into such token.
Perhaps there's a room to provide support for agent registration procedure, in which a registration-only token is used to get the agent-unique token that will be persisted and used for future communication?
The text was updated successfully, but these errors were encountered: