-
Notifications
You must be signed in to change notification settings - Fork 333
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
operator constanly tries to reconcile fluentbitagent because it tries to update daemonset labels #1837
Comments
@siimaus thanks for the report and sorry for the long delay! Have you tried to set |
@siimaus sorry I was mixing things up. Can you please provide your logging resource as well? If you let the resource to be recreated what is the difference between the original and the recreated resource exactly? |
@pepov I'm also seeing this happening when I have multiple loggings, and consequently multiple fluentbitagents. If I enable spec.enableRecreateWorkloadOnImmutableFieldChange it recreates the Daemonset with a different spec.selector, specifically setting selector.Matchlabels["app.kubernetes.io/managed-by:"] to the other FluentBitAgent, not the one which is actually responsible for this Daemonset. |
Do you use loggingRef to isolate your fluentbitagents? Can you describe your setup a bit more in general? |
Bug here is that there is multiple implementations how loggingRef is gotten for comparisons in go code, or in k8s via selector, or in actual logic like hostnames. In some cases value is from loggingRef value, name, empty or default. These use logginRef in both directions, logging-operator/controllers/logging/logging_controller.go Lines 640 to 643 in c6bf514
and logging-operator/controllers/logging/logging_controller.go Lines 546 to 565 in c6bf514
But secrets have their own implementation, logging-operator/controllers/logging/logging_controller.go Lines 572 to 585 in c6bf514
ClusterFlow and ClusterOutput use loggingRef, logging-operator/pkg/resources/model/repository.go Lines 151 to 159 in c6bf514
logging-operator/pkg/resources/model/repository.go Lines 171 to 179 in c6bf514
As does FluentbitAgent, logging-operator/pkg/resources/model/repository.go Lines 326 to 334 in c6bf514
LoggingRoutes use source and loggingRef logging-operator/pkg/resources/model/repository.go Lines 428 to 436 in c6bf514
Fluentd uses name instead of loggingRef logging-operator/pkg/sdk/logging/api/v1beta1/logging_types.go Lines 556 to 563 in c6bf514
logging-operator/pkg/sdk/logging/api/v1beta1/logging_types.go Lines 604 to 605 in c6bf514
ServiceMonitor uses name, logging-operator/pkg/resources/fluentbit/service.go Lines 60 to 76 in c6bf514
Secrets use loggingRef or "default" logging-operator/pkg/resources/fluentd/outputsecret.go Lines 35 to 39 in c6bf514
Main uses loggingRef if set Lines 333 to 334 in c6bf514
Fluentbit uses name logging-operator/pkg/resources/fluentbit/fluentbit.go Lines 54 to 65 in c6bf514
|
Yes, unfortunately this has been handled differently throughout the code and haven't been fixed since. I think it will be non-trivial to fix in a compatible manner. For now can someone give as a reproducible example? |
@pepov having
|
I had the same problem. Changin |
Logging operator constantly reports following error:
When I enable workloads recreation as mentioned in logs by setting logging objects
spec.enableRecreateWorkloadOnImmutableFieldChange: true
then operator constantly recreates fluentbit agent daemonsets either based on some schedule or when operator is restarted etc. Deletion of CRD and recreating anew does not solve issue.
Error seems to stem from attempt to change daemonset selector but I am not familiar enough with operator code to say why it tries to change selector.
Describe the bug:
Operator constantly tries to recreate fluentbit daemonsets because it fails reconcilation
Expected behaviour:
No attempts at recreation of daemonsets unless FluentbitAgent CRD has changed.
Steps to reproduce the bug:
Additional context:
Add any other context about the problem here.
Environment details:
/kind bug
The text was updated successfully, but these errors were encountered: