-
Notifications
You must be signed in to change notification settings - Fork 17
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
Consider merging CX and N use-cases #150
Comments
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with /lifecycle stale |
I'd say that vNUME generally makes sense in CX as well. But even if the two series become functionally equal, I wonder if we should merge them. For higher level tooling - such as UI and automatoin - it can be helpful to know the purpose or intention of the workload. |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with /lifecycle stale |
/remove-lifecycle stale |
Is this a BUG REPORT or FEATURE REQUEST?:
Currently Network (N series) and Compute Exclusive (CX series) differ by only one aspect: vNUMA:
However the network use case also requires vNUMA for it's proper work. For example, DPDK workloads require the CPUs scheduled for the VM to be of the same NUMA node. This is currently done by using the Node Tuning Operator in order to enforce "single-numa-topology".
Please consider joining these two use cases, as it can reduce your maintenance work in this project.
What happened:
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:
virtctl version
):kubectl version
):uname -a
):The text was updated successfully, but these errors were encountered: