Set instance_uid by Server on conflict or request for generation

[pmm-sumo]

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

[tigrannajaryan]

There's a gap with multiplexed websocket connections

Yeah, this is unfortunate. To avoid this problem perhaps we can do slightly differently. Instead of using empty instance_uid field in AgentToServer message as an indication of a request to assign a new instance_uid we can have an explicit flag in AgentToServer to indicate it. In that case the instance_uid field in AgentToServer message may still be set to some temporary value by the Agent until it gets the new instance_uid value from the Server.

Another approach is for the terminating proxy to NOT multiplex connections with empty incoming instance_uid field with other connections. So the initial assignment of instance_uid will require a dedicated outgoing connection from the proxy to the Server. After the assignment of the instance_uid the dedicated connection can be dropped and the multiplexing can start.

which perhaps could be handled by adding Agent capability flag indicating if overrides can be accepted or not

I am not sure how this will solve the problem. Can you expand?

[pmm-sumo]

There's a gap with multiplexed websocket connections

Yeah, this is unfortunate. To avoid this problem perhaps we can do slightly differently. Instead of using empty instance_uid field in AgentToServer message as an indication of a request to assign a new instance_uid we can have an explicit flag in AgentToServer to indicate it. In that case the instance_uid field in AgentToServer message may still be set to some temporary value by the Agent until it gets the new instance_uid value from the Server.

I thought about it and I am leaning towards that approach. Will update the PR

which perhaps could be handled by adding Agent capability flag indicating if overrides can be accepted or not

I am not sure how this will solve the problem. Can you expand?

This would merely inform that it is not possible to override the agent instance_id. I think the idea proposed above (temporary id's and explicit flag) is a better one

[pmm-sumo]

I think that "new_instance_uid" would be too specific field and wanted something with a bit broader scope so I thought about "AgentIdentification", though also wondering about "AgentIdentifcationOverride", "AgentIdentificationOffer" or so. If you had anything else in mind @tigrannajaryan I will gladly accept it

[tigrannajaryan]

Is there anything else that we may want to add to AgentIdentification message in the future?

[pmm-sumo]

Is there anything else that we may want to add to AgentIdentification message in the future?

I don't have anything on my mind right now though I'm actually wondering if instead creating AgentIdentification, a model used in AgentDescription could be followed (so repeated KeyValue). I don't really have a strong use case but wondering if this would give an opportunity for the server to send some attributes back (both identifying and non-identifying) that would be persisted by the agent. Not sure if it makes much sense though (since server could always attach them later itself if needed)

[tigrannajaryan]

We can add keyvalue list as an additional field later if needed. I think what we have for now is fine.

[tigrannajaryan]

@pmm-sumo will you be able to submit a corresponding change in opamp-go client and server implementations?

[pmm-sumo]

@pmm-sumo will you be able to submit a corresponding change in opamp-go client and server implementations?

@tigrannajaryan sure thing, will have it later today