Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

design-proposal: instancetype.kubevirt.io - Support declarative VirtualMachine management #317

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

lyarwood
Copy link
Member

What this PR does / why we need it:

At present a VirtualMachine using instance types and/or preferences will have runtime derived data such as the name of a ControllerRevision capturing the state of each resource mutated into the core spec during submission.

This breaks declarative management of VirtualMachines as an owner has no way of pre-populating these runtime derived values and will always see changes made to the spec of their VirtualMachine after submission.

This design proposal aims to enable declarative management of VirtualMachines using instance types and/or preferences by using status to track runtime derived data while retaining all existing behavior and lifecycle support of a VirtualMachine using an instance type and/or preference.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Special notes for your reviewer:

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

Release note:

NONE

@kubevirt-bot
Copy link

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign davidvossel for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@kubevirt-bot kubevirt-bot added the dco-signoff: yes Indicates the PR's author has DCO signed all their commits. label Aug 19, 2024
@lyarwood lyarwood marked this pull request as draft August 19, 2024 11:56
@kubevirt-bot kubevirt-bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Aug 19, 2024
@lyarwood lyarwood force-pushed the instancetype-stop-mutating-vm-spec branch 2 times, most recently from 958d028 to e3d305f Compare August 20, 2024 09:37
Copy link
Member

@0xFelix 0xFelix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great idea!

@lyarwood lyarwood force-pushed the instancetype-stop-mutating-vm-spec branch from e3d305f to a976003 Compare September 4, 2024 17:59
@lyarwood lyarwood marked this pull request as ready for review September 4, 2024 17:59
@kubevirt-bot kubevirt-bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Sep 4, 2024

```

If a snapshot is taken of this VirtualMachine however the values from status will be written back into the spec with `inferFromVolume` now removed:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will lead to slightly different behavior of a restored VM. On the original VM the inference can be retriggered, on the restored VM the instancetype/preference will be fixed. Is there a way to keep inferFromVolume and only restore the status?

Copy link
Member Author

@lyarwood lyarwood Sep 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could always move name, kind, RevisionName and controllerRevisionRef into status during restore when inferFromVolume is provided? That's simple enough and would allow the restored VM to retain the same inferFromVolume behaviour.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually that doesn't work, we can't change the spec after submission at all even in this case. I guess if the user wants inferFromVolume to work again this case they will need to clear the other fields in the spec and then use the refresh subresource API etc to infer things once again.

@lyarwood lyarwood force-pushed the instancetype-stop-mutating-vm-spec branch from a976003 to 11ac68f Compare September 6, 2024 15:28
@lyarwood lyarwood force-pushed the instancetype-stop-mutating-vm-spec branch from 11ac68f to 40aa2f4 Compare September 6, 2024 16:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dco-signoff: yes Indicates the PR's author has DCO signed all their commits. size/L
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants