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.
- 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.
- 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.
- Cosign Verification: This PR will implement the Verification interface for the Cosign procedure.
- tar.gz Archive: This PR will implement the Archive verification for ".tar.gz" packages - the default used by official OTel releases.
- 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.
- 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.
- 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.
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.
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.
Issue Tracker
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
+1orme too, to help us triage it. Learn more here.