Handle kubevirt control plane NodePlacement on hypershift clusters #3219
Conversation
Since kubevirt v1.3, the kubevirt control plane components (e.g. virt-controller and virt-api) are getting schdeuled by default on the control-plane/master nodes, not regular worker nodes. In hypershift (Hosted Control Planes) clusters, there are no control plane nodes at all (the control plane is hosted as pods on the management cluster). Therefore, in case there are no control plane nodes, we're setting the kubevirt's node placement as an empty struct to avoid any predefined scheduling/affinity rules that might prevent the pods to be scheduled on the cluster. Signed-off-by: Oren Cohen <ocohen@redhat.com>
kubevirt-bot
added
release-note
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: 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 |
|
Pull Request Test Coverage Report for Build 12414707698Details
💛 - Coveralls |
|
hco-e2e-upgrade-prev-operator-sdk-sno-aws lane succeeded. |
|
@hco-bot: Overrode contexts on behalf of hco-bot: ci/prow/hco-e2e-operator-sdk-sno-azure, ci/prow/hco-e2e-upgrade-prev-operator-sdk-azure, ci/prow/hco-e2e-upgrade-prev-operator-sdk-sno-azure In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
hco-e2e-operator-sdk-aws, hco-e2e-operator-sdk-gcp lanes succeeded. |
|
@hco-bot: Overrode contexts on behalf of hco-bot: ci/prow/hco-e2e-operator-sdk-azure In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
hco-e2e-upgrade-prev-operator-sdk-aws lane succeeded. |
|
@hco-bot: Overrode contexts on behalf of hco-bot: ci/prow/hco-e2e-upgrade-prev-operator-sdk-azure In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
@orenc1: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
hco-e2e-kv-smoke-gcp lane succeeded. |
|
@hco-bot: Overrode contexts on behalf of hco-bot: ci/prow/hco-e2e-kv-smoke-azure In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Since kubevirt v1.3, the kubevirt control plane components (e.g. virt-controller and virt-api) are getting schdeuled by default on the control-plane/master nodes, not regular worker nodes.
In hypershift (Hosted Control Planes) clusters, there are no control plane nodes at all (the control plane is hosted as pods on the management cluster). Therefore, in case there are no control plane nodes, we're setting the kubevirt's node placement as an empty struct to avoid any predefined scheduling/affinity rules that might prevent the pods to be scheduled on the cluster.
What this PR does / why we need it:
Reviewer Checklist
Jira Ticket:
Release note: