neonvm: Small changes for stateless scheduler #1194
Merged
Conversation
This file contains 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
6 tasks
No changes to the coverage.
HTML Report |
petuhovskiy
approved these changes
Jan 2, 2025
sharnoff
force-pushed
the
sharnoff/neonvm-touchups-stateless-scheduler
branch
from
a1b55f7 to
42f5c17
Compare
…1194) From now on, during the migration we will have: - Symmetrical owner refs: both VirtualMachine and VirtualMachineMigration will own both source and target pods. - Asymmetrical controller refs: VirtualMachine controls source pod, VirtualMachineMigration controls target pod. Once the migration is complete, neither the VirtualMachine nor the VirtualMachineMigration will control the source pod, but they will still have (non-controlling) owner refs. This allows us to figure out the pod's role in the migration by looking at it's references. Co-authored-by: Oleg Vasilev <[email protected]>
We had some existing, similar helpers in 'pkg/util', but I figured it makes more sense for those to be defined in 'neonvm/apis/...'. This change originated while working on the stateless scheduler prototype, where I found myself wanting a reliable way to determine what role a pod has in a live migration from only the pod's metadata.
We weren't doing this previously, and it means that propagation of labels/annotations can be arbitrarily delayed while the VM starts.
sharnoff
force-pushed
the
sharnoff/neonvm-touchups-stateless-scheduler
branch
from
42f5c17 to
1a8473d
Compare
sharnoff
added a commit
that referenced
this pull request
Jan 6, 2025
…1194) From now on, during the migration we will have: - Symmetrical owner refs: both VirtualMachine and VirtualMachineMigration will own both source and target pods. - Asymmetrical controller refs: VirtualMachine controls source pod, VirtualMachineMigration controls target pod. Once the migration is complete, neither the VirtualMachine nor the VirtualMachineMigration will control the source pod, but they will still have (non-controlling) owner refs. This allows us to figure out the pod's role in the migration by looking at it's references. Co-authored-by: Oleg Vasilev <[email protected]>
sharnoff
added a commit
that referenced
this pull request
Jan 6, 2025
We had some existing, similar helpers in 'pkg/util', but I figured it makes more sense for those to be defined in 'neonvm/apis/...'. This change originated while working on the stateless scheduler prototype, where I found myself wanting a reliable way to determine what role a pod has in a live migration from only the pod's metadata.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Extracted out of #1163, as suggested by #1163 (comment) and #1163 (comment).
These are mostly three unrelated commits among the broader theme of making stronger guarantees about what the Pods look like.
I'm intending to merge via rebase-and-merge to keep these commits separate.