-
Notifications
You must be signed in to change notification settings - Fork 334
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
Gem::ConflictError when applying ClusterFlow #1251
Comments
@sebastiangaiser, thanks for the report. Could you recheck it with ghcr.io/kube-logging/fluentd:v1.14.6 ? |
Same error for the FluentD pod(s)... |
@sebastiangaiser Thanks. Please check with v1.14.6-build.51 and send the logging output definition as well. (without the sensitive data. ;) ) |
|
@sebastiangaiser it's |
Sorry for the late reply:
Same error:
The ClusterOutput:
|
I just ran this both with the latest My manifest:
The container is running although it is unable to connect to the host, so I guess it passes the error @sebastiangaiser mentioned:
|
My error occurs earlier than your The only difference I can see, you are using normal Flow and Output resources. I did it with ClusterFlow and ClusterOutput but I will try to make a minimal example as you did and paste the result here because I was using https://github.com/kube-logging/helm-charts/tree/main/charts/logging-operator-logging for deploying the CRs. |
Same error with these manifests and operator 4.X (
|
@pepov it seams to work now with logging-operator Have you changed something to the images? In case, is there a best practice for pinning the image version for the logging-operator. I remember such a image version pinning for rook-ceph with the recommendation to pin it to a build date (for production environments). |
We don't change the operator image version, so you don't have to worry about that 4.1.0 will stay the same. We have a different build and release setup for the And to answer you question I beleive the updates in the elasticsearch/opensearch plugins fixed the conflict issue:
uken/fluent-plugin-elasticsearch@1e817c9 |
Thank you for the support. The question about the tagging was more in the direction for the fluentd images like |
Describe the bug:
FluentD leads to crashloopbackoff and FluentD-configcheck fails
Expected behaviour:
FluentD is not crashing :D
Steps to reproduce the bug:
Additional context:
Environment details:
Output of
kubectl logs -f -n logging logging-operator-logging-fluentd-configcheck-dcbaaaf3
FluentD spec (also
v1.15
tested) taken from Logging:/kind bug
The text was updated successfully, but these errors were encountered: