Remove binding from the smon status, if the ref workload is deleted#7795
Remove binding from the smon status, if the ref workload is deleted#7795simonpasquier merged 6 commits intoprometheus-operator:mainfrom
Conversation
|
@simonpasquier review request |
|
For this one, I'd expect that we leverage the FinalizerSyncer. It should be its responsibility to remove the bindings (maybe with help from the controller?) and then remove the finalizer only after everything's cleaned up. |
|
RemoveBinding requires many helper functions and structs from controller, also finalizerSyncer responsiblity is to add/remove finalizer, adding/removing status is done by controller sync function |
|
@simonpasquier PTAL! |
pkg/prometheus/server/operator.go
Outdated
|
|
||
| finalizersChanged, err := c.finalizerSyncer.Sync(ctx, p, logger, c.rr.DeletionInProgress(p)) | ||
| assetStore := assets.NewStoreBuilder(c.kclient.CoreV1(), c.kclient.CoreV1()) | ||
| resources, err := c.getSelectedConfigResources(ctx, logger, p, assetStore) |
There was a problem hiding this comment.
wouldn't it be better to iterate over all config resources and remove bindings which refer to the deleted prometheus? Otherwise we're at risk of missing some config resources.
pkg/prometheus/server/operator.go
Outdated
| } | ||
|
|
||
| // configResStatusCleanup removes prometheus bindings from the selected configuration resources (ServiceMonitor, PodMonitor, ScrapeConfig and PodMonitor). | ||
| // It returns true if another reconciliation is needed to complete the cleanup and and an error if the cleanup fails. |
There was a problem hiding this comment.
like discussed directly I don't think that we need to throttle the updates for now.
|
@simonpasquier PTAL done the changes |
3d04de8
into
prometheus-operator:main
Description
Remove binding from the smon status, if the ref workload is deleted
Closes: #7794
Type of change
What type of changes does your code introduce to the Prometheus operator? Put an
xin the box that apply.CHANGE(fix or feature that would cause existing functionality to not work as expected)FEATURE(non-breaking change which adds functionality)BUGFIX(non-breaking change which fixes an issue)ENHANCEMENT(non-breaking change which improves existing functionality)NONE(if none of the other choices apply. Example, tooling, build system, CI, docs, etc.)Verification
Please check the Prometheus-Operator testing guidelines for recommendations about automated tests.
Changelog entry
Please put a one-line changelog entry below. This will be copied to the changelog file during the release process.