fix(vm): track USB ResourceClaimTemplate spec via hash annotation#2623
Open
danilrwx wants to merge 2 commits into
Open
fix(vm): track USB ResourceClaimTemplate spec via hash annotation#2623danilrwx wants to merge 2 commits into
danilrwx wants to merge 2 commits into
Conversation
Comparing the stored spec with the rendered one via DeepEqual breaks as soon as the API server defaults any field absent from the rendered spec: the comparison never converges and the handler deletes and recreates the template on every reconcile. The USB template spec is especially exposed because it embeds ObjectMeta with annotations. Stamp the rendered spec hash into an annotation and compare hashes instead, following the tolerations-hash pattern. A template without the annotation counts as outdated and is recreated once. Signed-off-by: Daniil Antoshin <daniil.antoshin@flant.com>
… hash Templates created before the hash annotation existed would otherwise be recreated once on controller upgrade. Compare their stored spec directly instead; they migrate to the hash on their next legitimate recreation. Signed-off-by: Daniil Antoshin <daniil.antoshin@flant.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Description
The controller decides whether the DRA claim template of a
USBDeviceis still up to date by comparing its stored spec with a freshly rendered one. Anything that mutates the stored spec on write — a new defaulted field in a future Kubernetes release, or a mutating admission policy in the user's cluster — makes that comparison permanently false: the controller then deletes and recreates the template on every reconcile, forever, producing constant API churn and event spam that never converges.Each template now carries a fingerprint of the spec it was rendered from, and the controller compares fingerprints instead of live objects (the same approach already used for tolerations). Templates created before this change keep the old direct comparison until they are legitimately recreated, so nothing is churned on upgrade.
Why do we need it, and what problem does it solve?
This is a latent-bug fix: today the comparison holds because the controller explicitly sets every field the API server currently defaults. The first Kubernetes release that defaults a new field in claim specs — or any cluster-side mutating policy touching claim templates — would silently put every
USBDeviceinto an endless recreate loop.What is the expected result?
USBDevice; its claim template is created with an internal spec-fingerprint annotation and stays untouched across reconciles.Checklist
Changelog entries