-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Support a configurable default agent configuration to be implemented by OpAMP supervisor #32598
Comments
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
This seems very similar to Would |
yes looks like that should work. |
Just to clarify: do we expect I would expect that a "fallback" config that is used in the case the server is unreachable would be different from a config file that is layered on top of the remote config. @pabloem how do you want this to work in your use case? |
Perhaps we make this the "fallback" config? Does it need to be different? |
I think the two use cases are different. My understanding of the intent of the current option is based on the description:
Based on this, my expectation is that this file would supplement/overwrite config provided by the server. I would expect the "fallback" and "extra config" cases to be different. For example in the fallback scenario I may have a specific backend I want to send to. I would be fine just making this a fallback option and only providing a file that is merged with the config from the server if we have user requests for it. I think inlining config from local files inside the server config (e.g. |
This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
This issue has been closed as inactive because it has been stale for 120 days with no activity. |
…ded (#35430) **Description:** <Describe what has changed.> If an empty config map is received, the supervisor does not run the agent. ~The current logic here works fine, but I'm considering adding an option to only do this if the user opts into it. I'm not sure if there's a reason why a user might want to run the collector with the noop config though (maybe for the agent's self-telemetry?)~ I've thought about it some more, and I don't think we need a config option here. If users want the collector to use a noop config, they can send a basic noop config. I think we should also implement #32598 (closed as stale, we'll want to re-open this or open a new issue for it), which would allow users to configure a backup config to use when no config is provided by the server, if they would like. **Link to tracking Issue:** Closes #33680 **Testing:** e2e test added Manually tested with a modified OpAMP server to send an empty config map **Documentation:** Update spec where it seemed applicable to call out this behavior.
…ded (open-telemetry#35430) **Description:** <Describe what has changed.> If an empty config map is received, the supervisor does not run the agent. ~The current logic here works fine, but I'm considering adding an option to only do this if the user opts into it. I'm not sure if there's a reason why a user might want to run the collector with the noop config though (maybe for the agent's self-telemetry?)~ I've thought about it some more, and I don't think we need a config option here. If users want the collector to use a noop config, they can send a basic noop config. I think we should also implement open-telemetry#32598 (closed as stale, we'll want to re-open this or open a new issue for it), which would allow users to configure a backup config to use when no config is provided by the server, if they would like. **Link to tracking Issue:** Closes open-telemetry#33680 **Testing:** e2e test added Manually tested with a modified OpAMP server to send an empty config map **Documentation:** Update spec where it seemed applicable to call out this behavior.
Component(s)
cmd/opampsupervisor
Is your feature request related to a problem? Please describe.
I am implementing the OpAMP protocol across our fleet, and I find that I want agents to implement a default configuration if the supervisor is unable to reach the OpAMP server.
We want most hosts to have a simple default config: Receive OTLP logs in a given port and forward them to our log-processing infrastructure. I want to be sure that this configuration will be enabled even in restricted environments (e.g. environments managing sensitive data - thus blocked by firewalls, etc).
Happy to discuss further.
Describe the solution you'd like
I propose a new parameter
agent.base_config
in the supervisor that points to a base configuration file that is enabled if we can't get another one. Basic implementation is here:#32192
Another feature of the PR above is that it avoids overwriting the
effective.yaml
config to be sure we don't overwrite a config that might have worked in the past.Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: