opamp-matching-service-instance-id.yaml

# Use this changelog template to create an entry for release notes.

# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'
change_type: 'bug_fix'

# The name of the component, or a single word describing the area of concern, (e.g. receiver/filelog)
component: extension/opamp

# A brief description of the change.  Surround your text with quotes ("") if it needs to start with a backtick (`).
note: Decorrelate `service.instance.id` and OpAMP `instance_uid`

# Mandatory: One or more tracking issues related to the change. You can use the PR number here if no issue exists.
issues: [46495]

# (Optional) One or more lines of additional information to render under the primary note.
# These lines will be padded with 2 spaces and then inserted directly into the document.
# Use pipe (|) for multiline entries.
subtext: |
  Previously:
  - the `service.instance.id` reported in the AgentDescription was based on the OpAMP instance UID
  - the instance UID was typically set based on the `service.instance.id` from the Collector resource attributes
  - it could be overriden using the `instance_uid` configuration of the OpAMP extension
  
  This meant that the reported `service.instance.id` did not always match the Collector resource attributes,
  which is a problem for correlation, and that server implementations got used to the typical case of
  `service.instance.id` and `instance_uid` matching, despite there being no guarantee of this.

  Now:
  - the reported value of `service.instance.id` always matches the Collector resource attributes
  - the instance UID is either taken from the `instance_uid` configuration or generated randomly.

  This means that the two values can never be expected to match, unless both configurations are explicitly set to the same value.
  That is what the OpAMP supervisor does, which means its behavior is unaffected.
  

# If your change doesn't affect end users or the exported elements of any package,
# you should instead start your pull request title with [chore] or use the "Skip Changelog" label.
# Optional: The change log or logs in which this entry should be included.
# e.g. '[user]' or '[user, api]'
# Include 'user' if the change is relevant to end users.
# Include 'api' if there is a change to a library API.
# Default: '[user]'
change_logs: [user]