- Version: main
- Operating System: N/A
- Discuss Forum URL: N/A
- Steps to Reproduce:
Summary
When an OpAMP client (e.g. OTel Collector) sends an AgentToServer message
after initial enrollment with an updated AgentDescription sub-message,
fleet-server silently ignores it. The stored agent document keeps whatever
IdentifyingAttributes / NonIdentifyingAttributes / hostname / version
were captured at enrollment time.
Why this is a bug
The OpAMP specification explicitly allows AgentDescription to change, and
defines a compression rule where the client omits unchanged sub-messages:
"The Client MAY compress the AgentToServer message by omitting the
sub-messages that have not changed since that particular data was reported
last time."
"This field SHOULD be unset if this information is unchanged since the last
AgentToServer message."
In other words, when AgentDescription is present on a non-initial message,
it means the client is signaling a change, and the server is expected to
update its view of the agent.
Today, internal/pkg/api/handleOpAMP.go:updateAgent() does not look at
aToS.AgentDescription at all — only enrollAgent() does. As a result:
- Hostname / OS / agent version changes are never reflected.
NonIdentifyingAttributes and IdentifyingAttributes in .fleet-agents
remain frozen at enroll-time values.
- Any top-level fields derived from these attributes (e.g. tags promoted from
a non-identifying attribute) will also go stale as soon as a user edits
their collector config.
Steps to Reproduce
- Enroll an OTel Collector against fleet-server via OpAMP with
non_identifying_attributes containing host.name: "host-a".
- Confirm the agent document in
.fleet-agents has host.hostname: "host-a"
in its local metadata, and that host.name appears in the stored
NonIdentifyingAttributes.
- Stop the collector, change the config to
host.name: "host-b", restart it.
- Observe that subsequent
AgentToServer messages include the updated
AgentDescription, but the .fleet-agents document still shows
host.hostname: "host-a" and the old NonIdentifyingAttributes blob.
Proposed fix
Extract the AgentDescription parsing logic from enrollAgent() into a
helper, and call it from updateAgent() as well when
aToS.AgentDescription != nil. Update the relevant fields on the existing
agent document (local metadata, identifying/non-identifying attributes,
and any derived top-level fields) via the bulker.
Related
Summary
When an OpAMP client (e.g. OTel Collector) sends an
AgentToServermessageafter initial enrollment with an updated
AgentDescriptionsub-message,fleet-server silently ignores it. The stored agent document keeps whatever
IdentifyingAttributes/NonIdentifyingAttributes/ hostname / versionwere captured at enrollment time.
Why this is a bug
The OpAMP specification explicitly allows
AgentDescriptionto change, anddefines a compression rule where the client omits unchanged sub-messages:
In other words, when
AgentDescriptionis present on a non-initial message,it means the client is signaling a change, and the server is expected to
update its view of the agent.
Today,
internal/pkg/api/handleOpAMP.go:updateAgent()does not look ataToS.AgentDescriptionat all — onlyenrollAgent()does. As a result:NonIdentifyingAttributesandIdentifyingAttributesin.fleet-agentsremain frozen at enroll-time values.
a non-identifying attribute) will also go stale as soon as a user edits
their collector config.
Steps to Reproduce
non_identifying_attributescontaininghost.name: "host-a"..fleet-agentshashost.hostname: "host-a"in its local metadata, and that
host.nameappears in the storedNonIdentifyingAttributes.host.name: "host-b", restart it.AgentToServermessages include the updatedAgentDescription, but the.fleet-agentsdocument still showshost.hostname: "host-a"and the oldNonIdentifyingAttributesblob.Proposed fix
Extract the
AgentDescriptionparsing logic fromenrollAgent()into ahelper, and call it from
updateAgent()as well whenaToS.AgentDescription != nil. Update the relevant fields on the existingagent document (local metadata, identifying/non-identifying attributes,
and any derived top-level fields) via the bulker.
Related