Roadmap

This doesn’t commit to any timelines and doesn’t provide any guarantees, but it does identify ideas that could be pursued and developed

Agent-based features

Extend Editor

Extend the editor to support additional agent types, covering:

• Multi-agent configuration editor and Vector support - implementation specification for refactoring config-service, adapting the Fluent Bit approach, and adding schema-driven Vector editing to the OpAMP server.
• OpenTelemetry Collector
• Vector
• Elastic Agent
• Elastic Beats (Heartbeat, etc)

Configuration Intelligence

Incorporate a strategy for tracking the configuration versions across multiple agents beyond just Fluent Bit. Plus factor in the new 5.1 Fluent Bit configuration option. The mechanism would need to be at least partially configurable.

Would need to include:

• Best practice analysis for all the different agent types
• OpenTelemetry semantic conventions
• Extend the version-aware documentation scraper, catalog reconciliation, incomplete-page diagnostics, and schema generation workflow to Fluentd. The implementation should retain the source-adapter boundary so later agent types can reuse the same reconciliation and reporting pipeline without inheriting Fluent Bit-specific page assumptions.

Self Monitoring

Implement the ability to accommodate self-monitoring - the Spec identifies a passing target for the OTel backend. Depending upon the client, this maybe a templated approach, and the provided backend is injected into the template.

Supervisor / Observer config helper

Simplify the configuration process for the Supervisor / Observer - this could be via several possible paths:

• Server-side UI editor plugin that generates the config.
• Extend the CLI for a CLI-based configuration process that generates the file in the correct location - makes the config tuneable to a per-deployment model.

Additional agent types

Consider providing support for additional agent types, including:

• OpenObserve
• Datadog
• Remaining Elastic Beats
• OpenObserve Full stack solution
• [Loggie]{https://github.com/loggie-io/loggie} - CNCF listed
• Generic basic agent which each step of the life cycle runs a script

Reference configurations

Reference configurations to illustrate (and use the CLI to launch)

• Self-certification use of TLS (including mTLS)
• Configuration of authentication using Keycloak - with docs to point the way for other authentication

Automation and Deployment

Incorporate a deployment function in the server that will allow the user to:

• SSH to a client and deploy an agent configuration,
• deploy the observer/supervisor,
• trigger the installation or update of the observability too e.g. Fluent Bit
• Deploy the initial container
• Allow the user to embed the feature into the server startup

We should conmsider whether the deployment of the observability tool and its code is provided as a custom command, minimizing what can be done via the SSH tunnel, but also raises the question of permissions for the client side functionality.

Code signing

Look into using sigstore to sign the deployable artefacts.

SBOM refresh

Enhance the CLI tooling so that the version bump also drives:

• the SBOM regeneration
• minification of the UI is actioned
• OpenAPI doc spec generated

PyPI incorporation

Add project to PyPI. Need to consider whether it’s a single PyPI project or several with different parts e.g. Consumer(s), Server, plugs

Uninstall clean

The wheel deinstallation process should also clean up log files and other artefacts that get generated

Automated (multi-cloud) regression setup

Progress the Azure setup, look at OCI implementation as well.

Enhanced Tooling

Incorporate additions to help validate configuration of the agents such as:

• Log Simulator
• New Metrics and traces simulation Complete the remote config process

Introduce to the provider a configuration value called allow-remote-config - this is a boolean configuration value, with a default of true. When allow-remote-config is true, then enable the enhanced part of the configuration tab, and the flag for this agent indicates remote config files are allowed (this will be temporarily hardwired to true)

The Enhanced part of the Configuration tab in the provider UI will provide a list of remote configuration files. If the catalog service is deployed then provide a ‘select configs’ button should be provided. When pressed it will open the catalog UI in a popup window, and will set the callaback to the server to configure this agent’s config files.

The catalog service needs an enhancement so it can be given a callback address which is invoked by a button that is displayed when a callback is provided. The callback will pass back a list of the tickbox selected files in the order in which they where selected. The returned list will then be displayed in the enhanced part of the configuration ui and the catalog is closed.

Complete remote configuration lifecycle coverage

Extend the remote-configuration regression scenarios beyond transport scaffolding and simulated happy paths. Coverage should include:

• configuration-status exchanges, including accepted, applied, rejected, and failed terminal states;
• real configuration-file mutation with validation, atomic backup, restoration, and rollback;
• malformed and unsupported configuration rejection with actionable provider and consumer diagnostics;
• interrupted and partially applied update recovery; and
• at least one real supported agent process in addition to simulator-based coverage.

Enhance the security aspect of the process

• Dependency vulnerability scanning:
  • Python: pip-audit / safety.
  • JavaScript: npm audit plus Dependabot/Renovate updates.
• SAST:
  • Python: bandit, semgrep rules for Quart patterns.
  • JavaScript: eslint (+ security plugin), semgrep JS/DOM/XSS rules.

  Component-Specific Testing Strategy