Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings
Discussion options

Hi!

I have a use-case where I'd like to run reconciliation when the annotation of a resource has changed. One naive approach to do this would be to add a simple onUpdateFilter to to ControllerConfiguration such as:

class ApiUpdateFilter : OnUpdateFilter<Api> {
        override fun accept(newResource: Api, oldResource: Api): Boolean {
            // or more complex logic to only trigger on specific annotations
            return oldResource.metadata.annotations != newResource.metadata.annotations
        }
    }

However this doesn't work if we don't disable generationAwareEventProcessing as changes to metadata doesn't update the generation version, see https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource

The .metadata.generation value is incremented for all changes, except for changes to .metadata or .status.

With the way our reconciler is implemented it always results in an update and thus the resourceVersion is updated, i.e. if we disable generationAwareEventProcessingwe we end up in an infinite reconciliation loop. One way to fix this would be to reimplement the default onUpdateGenerationAware filter in our customer filter, but then we also need to re-implement the onUpdateFinalizerNeededAndApplied and so on. This seems like the wrong approach.

Do you have some recommendation on how we could run reconciliation on annotation changes without ending up in some infinite loop?

Cheers,
Rickard

You must be logged in to vote

yes, to that is the reason why, it is observedGeneration is used in status, rather than time. To not trigger the reconciliation all the time.

Also maybe you could reconsider changing the annotation, and putting it into spec?

Replies: 1 comment · 3 replies

Comment options

Hi @rickardb

With the way our reconciler is implemented, it always results in an update

So usually this is what is avoided, if it is an update that actually does not change the resource it is fine, that would not result in an event.
Could you tell more why is this needed?

You must be logged in to vote
3 replies
@rickardb
Comment options

The only changes I can see to the resource is the resourceVersion and status.lastTransitionTime which seems to result in a new reconciliation loop running.

@csviri
Comment options

yes, to that is the reason why, it is observedGeneration is used in status, rather than time. To not trigger the reconciliation all the time.

Also maybe you could reconsider changing the annotation, and putting it into spec?

Answer selected by rickardb
@rickardb
Comment options

Right makes sense. We will change to include it in the spec instead of the annotations. Just wanted to make sure I hadn't missed some obvious way to do this. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
🙏
Q&A
Labels
None yet
2 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.