Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a field for non-config files to AgentRemoteConfig #184

Open
evan-bradley opened this issue Apr 16, 2024 · 1 comment
Open

Add a field for non-config files to AgentRemoteConfig #184

evan-bradley opened this issue Apr 16, 2024 · 1 comment

Comments

@evan-bradley
Copy link

Summary

When configuring an agent, it may be helpful to provide files to the agent that are specifically designated as files that are related to the agent's configuration, but are not configuration files themselves.

Context

This change could be applicable to any agent, but is currently motivated by the way the Collector works. The Collector allows specifying multiple configuration files passed through its command line arguments, and will merge the resulting files. For example:

otelcol --config=file0.yaml --config=file1.yaml --config=file2.yaml

The Collector also allows specifying pulling in configuration from other sources within config files defined in command line arguments. For example, say file0.yaml above contains the following line:

rules: ${file:ruleset.yaml}

The contents of ruleset.yaml would be substituted into the contents of file0.yaml before the full configuration is parsed by the Collector.

If we want to provide multiple files to the Collector through the command line, but also provide files that are read inside of the Collector's configuration files, we would need to specify the difference between files that are top-level configuration and those that are supplementary to configuration. This could include config fragments as above, but also other files such as certificates, binary files, etc. that may be read by the Collector on startup.

Approaches

Add a new field in ServerToAgent

We could add another AgentRemoteConfig-typed field on ServerToAgent named remote_supplementary_config or similar that contains files intended to aid those in remote_config.

Add a new field in AgentRemoteConfig

We could add another list of files in AgentRemoteConfig that contains supplementary configuration files.

Add a new field in AgentConfigFile that specifies the role of a file

We could add another string field, e.g. config_type on AgentConfigFile that specifies how the server intends for the file to be used by the agent, and rely on semantic conventions for what these types mean. This would be the most flexible approach, but would also require the most processing by the agent.

Alternatives

Using PackagesAvailable to provide supplementary files

We could realistically offer supplementary files as packages, but this would be out-of-band for configuration and would likely be a complicated flow.

Utilize the MIME type of config files

We could alter the MIME type of config files, such as adding a parameter, to include OpAMP-specific information that indicates to the agent how a file should be used. This would also be a flexible option, but would need careful consideration to ensure that the OpAMP annotations don't cause unintended conflicts.

@tigrannajaryan
Copy link
Member

Discuss in workgroup meeting and the consensus seems to be that we want to "Add a new field in AgentConfigFile that specifies the role of a file".

Something like this:

message AgentConfigFile {
    // Config file or section body. The content, format and encoding depends on the Agent
    // type. The content_type field may optionally describe the MIME type of the body.
    bytes body = 1;

    // Optional MIME Content-Type that describes what's in the body field, for
    // example "text/yaml".
    string content_type = 2;

    // Optional role of the file. The values and their semantics are Agent-type specific.
    string file_role = 3;
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants