Remove support for DIMM hotplug #1060
Assignees
Labels
Comments
sharnoff
added
a/tech_debt
sharnoff
added a commit
that referenced
this issue
Sep 9, 2024
This is part 1 of 2 for removing DIMM slots support and completing our transition to using virtio-mem instead (ref #1060). With this change, neonvm-controller will always assume that VMs are using virtio-mem. The only checks exist at the top of the reconcile functions, making sure that this is indeed the case. The fields still exist in the CRD (although the're marked as deprecated), so that rollback of this change is still sound. neonvm-runner also retains support for both memory providers, so that custom neonvm-runner images continue to work for at least one version across the change.
sharnoff
added a commit
that referenced
this issue
Oct 12, 2024
This is part 1 of 2 for removing DIMM slots support and completing our transition to using virtio-mem instead (ref #1060). With this change, neonvm-controller will always assume that VMs are using virtio-mem. The only checks exist at the top of the reconcile functions, making sure that this is indeed the case. The fields still exist in the CRD (although the're marked as deprecated), so that rollback of this change is still sound. neonvm-runner also retains support for both memory providers, so that custom neonvm-runner images continue to work for at least one version across the change.
sharnoff
added a commit
that referenced
this issue
Oct 12, 2024
Part of #1060. Before we stop setting status.memoryProvider, we need to make sure that an empty status.memoryProvider is interpreted as virtio-mem. We *could* do that everywhere status.memoryProvider is used, but it's probably just easier to do it at top, replacing our handling that originally set DIMM slots by default.
sharnoff
added a commit
that referenced
this issue
Oct 12, 2024
This is part 1 of 2 for removing DIMM slots support and completing our transition to using virtio-mem instead (ref #1060). With this change, neonvm-controller will always assume that VMs are using virtio-mem. The only checks exist at the top of the reconcile functions, making sure that this is indeed the case. The fields still exist in the CRD (although the're marked as deprecated), so that rollback of this change is still sound. neonvm-runner also retains support for both memory providers, so that custom neonvm-runner images continue to work for at least one version across the change.
sharnoff
added a commit
that referenced
this issue
Oct 15, 2024
…1110) Part of #1060. Before we stop setting status.memoryProvider, we need to make sure that an empty status.memoryProvider is interpreted as virtio-mem. We *could* do that everywhere status.memoryProvider is used, but it's probably just easier to do it at top, replacing our handling that originally set DIMM slots by default.
|
Update: Waiting on me to rebase #1070. |
sharnoff
added a commit
that referenced
this issue
Nov 18, 2024
This is part 1 of 2 for removing DIMM slots support and completing our transition to using virtio-mem instead (ref #1060). With this change, neonvm-controller will always assume that VMs are using virtio-mem. The only checks exist at the top of the reconcile functions, making sure that this is indeed the case. The fields still exist in the CRD (although the're marked as deprecated), so that rollback of this change is still sound. neonvm-runner also retains support for both memory providers, so that custom neonvm-runner images continue to work for at least one version across the change.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This code is no longer needed since we moved to virtio-mem on all nodes and tested this over a sufficient time. So we should remove it to reduce tech debt and clean up the code.
The text was updated successfully, but these errors were encountered: