Proposal for Add-On Configuration Support in OSS OpAMP Specification

[pavankrish123]

Description: The current OpAMP specification provides comprehensive guidelines on handling packages and their downloads. However, it lacks a clear stance on how the packages/add-ons themselves should be configured. This feature request proposes the inclusion of a standardized approach for add-on configuration within the specification.

Rationale:

• Lack of Knowledge by Main Agent: The main agent may not possess detailed knowledge about the customer-implemented add-ons.

• Independent Add-On Lifecycle: Add-ons may have a lifecycle that operates independently of the main agent. Allowing add-ons to be configured separately ensures that their lifecycle can be managed without unnecessary intervention from the main agent.

Counterarguments

• Unified Configuration Management: In this scenario, add-on configurations would be incorporated into the agent's configuration, potentially reducing complexity in managing multiple configuration sources. However, implementing this is much easier (consider validation etc) if the addon configuration semantics are known before hand.

Proposal/Ask

1. Add-On Configuration Schema: Define a standardized schema for add-on configurations. This schema should be flexible enough to accommodate various types of add-ons while ensuring consistency.
2. Configuration Management Interface: Introduce an interface within the specification that allows for the independent management of add-on configurations. This interface should support operations such as retrieval, update, and validation of add-on configurations.
3. Lifecycle Management Guidelines: Provide guidelines on how the lifecycle of add-ons should be managed in relation to the main agent. This includes installation, updates, and decommissioning of add-ons.

Incorporating a standardized approach for add-on configuration within the OpAMP specification will enhance the flexibility, modularity, and overall manageability of the system.

[tigrannajaryan]

What would this look like in practice in its simplest form? Will we add "config" fields to PackageAvailable message? Do we also need to allow agents to report effective config for packages via PackageStatus, mirroring the functionality we have in AgentRemoteConfig/EffectiveConfig for main agent config?

[tigrannajaryan]

Add-On Configuration Schema: Define a standardized schema for add-on configurations. This schema should be flexible enough to accommodate various types of add-ons while ensuring consistency.

Can you expand on this?

Configuration Management Interface: Introduce an interface within the specification that allows for the independent management of add-on configurations. This interface should support operations such as retrieval, update, and validation of add-on configurations.

Same here, please provide more details.

Lifecycle Management Guidelines: Provide guidelines on how the lifecycle of add-ons should be managed in relation to the main agent. This includes installation, updates, and decommissioning of add-ons.

What are the parts that are missing? We have certain elements on this (e.g. in PackageStatus).