Clarify excess config behavior preserves running aggregator#329
Conversation
When multiple FluentdConfig or SyslogNGConfig resources exist in the same namespace, the documentation now clearly states that: - The previously-associated config continues to operate normally - Log forwarding remains uninterrupted while resolving the conflict - Users should delete the excess config to resolve the issue Also standardized SyslogNGConfig capitalization. Related: kube-logging/logging-operator#2232
| ``` | ||
|
|
||
| If there is a conflict, the controller adds a problem to both resources so that both the operations team and the tenant users can notice the problem. For example, if a `FluentdConfig` is already registered to a `Logging` resource and you create another `FluentdConfig` resource in the same namespace, then the first `FluentdConfig` is left intact, while the second one should have the following status: | ||
| If there is a conflict, the controller adds a problem to both resources so that both the operations team and the tenant users can notice the problem. The previously-associated `FluentdConfig` continues to operate normally, and log forwarding remains uninterrupted while you resolve the excess configuration. |
There was a problem hiding this comment.
Added clarification that the aggregator keeps running based on PR #2232 which fixes the bug where creating a second FluentdConfig would tear down the running aggregator. The fix in repository.go preserves the previously-associated configuration recorded in Logging.Status.FluentdConfigName.
| ``` | ||
|
|
||
| If there is a conflict, the controller adds a problem to both resources so that both the operations team and the tenant users can notice the problem. For example, if a `syslogNGConfig` is already registered to a `Logging` resource and you create another `syslogNGConfig` resource in the same namespace, then the first `syslogNGConfig` is left intact, while the second one should have the following status: | ||
| If there is a conflict, the controller adds a problem to both resources so that both the operations team and the tenant users can notice the problem. The previously-associated `SyslogNGConfig` continues to operate normally, and log forwarding remains uninterrupted while you resolve the excess configuration. |
There was a problem hiding this comment.
Added clarification that the aggregator keeps running based on PR #2232 which fixes the bug where creating a second SyslogNGConfig would tear down the running aggregator. The fix in repository.go preserves the previously-associated configuration recorded in Logging.Status.SyslogNGConfigName.
|
Just a reminder: I review PR comments by default. If you want me to ignore a specific comment, start it with |
Open this suggestion in Promptless to view citations and reasoning process
Documents that when multiple FluentdConfig or SyslogNGConfig resources exist in the same namespace, the previously-associated config continues operating normally and log forwarding remains uninterrupted. Adds resolution guidance to delete excess configs.
Trigger Events
Tip: Use Vale? Add your vale.ini when setting up your Docs Collection.