Skip to content

[cmd/opampsupervisor] Implement Package Upgrades in the Supervisor #47272

Description

@dpaasman00

Component(s)

No response

Is your feature request related to a problem? Please describe.

This issue is for implementing the collector upgrades feature that is part of the OpAMP Supervisor roadmap.

Describe the solution you'd like

The OpAMP Supervisor should implement package upgrades as defined in the OpAMP spec. In this issue I'll describe at a high level the design requirements and PRs that will follow that build on each other to implement this functionality.

As these PRs are reviewed, it's very possible that the design requirements and PR structures may change.

Design Requirements

These are a list of some key requirements needed in order for this functionality to meet the needs of the community. Some of these requirements spawned from review left on the original PR.

  • Compatibility with official OTel releases: This issue covers implementing this functionality such that it is compatible with releases generated by the official OTel release repository. This means using the Cosign signing verification procedure.
  • Rollback on failure: If the new collector binary fails to start, the old binary should be restored and the upgrade failed.
  • Extensible Verification: It is recognized that not all users will want to use the Cosign package verification process. Therefore the configuration for this functionality and code should be written in a way that allows for seamless additions of new verification procedures. New additions should not result in breaking changes to the supervisor's configuration.
  • Archive Extraction: In a similar vein to verification, this functionality should be compatible with official OTel releases. However, not all users may want to use packages that are archived in the same way. The process by which the supervisor handles the archive should be extensible to allow future options be added without introducing breaking changes.

PR structure

The following PRs will be opened in sequential order to gradually build this functionality without overwhelming reviewers. This functionality should be blocked from actual use until the final PR when the full functionality is reviewed and approved.

  1. Capabilities, Guarding, and Docs: This PR will consist of allowing the packages capabilities, checks to prevent usage of these capabilities, package manager skeleton, and adding documentation for this functionality.
  2. Config Surface, Archive & Verification interfaces: This PR will consist of adding the new configuration organization and structs that will be needed to handle verification and un-packaging.
  3. Cosign Verification: This PR will implement the Verification interface for the Cosign procedure.
  4. tar.gz Archive: This PR will implement the Archive verification for ".tar.gz" packages - the default used by official OTel releases.
  5. Package Manager: This PR will fully implement the function stubs defined in the first PR. It will make use of the configured Verification and Archive interfaces.
  6. Binary Update Orchestration: This PR will wire in the package manager into the supervisor lifecycle. This will be the PR that implements the rollback functionality as well.
  7. E2E tests & Finalization: Finally, add E2E tests that fully validate this functionality and remove the checks added in PR-1 to allow this full functionality to be used.

Issue Tracker

Content Issue #
Capabilities, guarding, & docs #47298
Config surface, archive & verification interfaces #48791
Cosign verification
tar.gz archive
Package manager
Binary update orchestration
e2e tests & finalization

Additional context

This is a new issue to track this feature. It replaces other issues that have been closed (#34734, #33947) and the PRs that follow will replace the existing PR that has grown too much in size.

Tip

React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions