-
Notifications
You must be signed in to change notification settings - Fork 23
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
Improved pipeline resource cleanup #298
Comments
There was following situation on one cluster which needs to get addressed in the same run: there was a healthy tracepieline till the referenced secret got deleted. The pipeline false in pending state, the collector and config stays unchanged and continues to work healthy. |
This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. |
This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. |
Description
Currently we dont have a proper decision on restarting the services for logging, trace and metrics for corner cases. Eg. see below the corner cases
Logging
When there is a logpipeline which uses a secret and if the secret is deleted then in the reconciliation we remove this logpipeline from the sections configmap and restart the fluentbit. Currently we cannot delete the fluentbit daemonset because the current decision making does not allow deleting the daemonset if the logpipeline is in
pending
statetracing/metrics
Same scenario with trace pipeline we return when dont have a deployable pipelines. Thus we dont update the config and we keep running with config which might not work eventually (as the secret has beed deleted).
Same is the case with metrics as well.
Expected result
When we have logpipeline/tracepipeline/metricpipeline in pending state (which was running but moved to pending because secret has been deleted) then we should not create resources.
Ideally we should think something like this
The text was updated successfully, but these errors were encountered: