fix: Handle upgrade to logging-operator v4.2.0 #1459
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What problem does this PR solve?:
In the logging-operator
4.2.0
, the fluent-bit daemonsetspec.selector
field was updated which is an immutable field.On upgrade to 2.6, the fluent-bit daemonset is never upgraded because the logging-operator cannot update the DS with the new selectors. The only way to continue is to delete the DS. Unfortunately, since our logging-operator HR is not behind a Kustomization, we don't have a good way of running a job after the operator finishes upgrading so we can't just simply run a
kubectl delete
on the DS.By setting
enableRecreateWorkloadOnImmutableFieldChange
, we allow the operator to recreate resources if required. If this is set, it's recommended to setlogging.spec.fluentbit.spec.positiondb
and a PVC for the fluentd buffer, both of which we have set.Which issue(s) does this PR fix?:
https://d2iq.atlassian.net/browse/D2IQ-98592
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
Checklist