kubevirtci
kubevirtci copied to clipboard
add ability to deploy kwok when KUBEVIRT_DEPLOY_KWOK is set to true
What this PR does / why we need it: Running the following command will install kwok enabled with the ability to fake VMIs
KUBEVIRT_DEPLOY_KWOK=true make cluster-up
With this, e2e test could be written to leverage fake nodes and fake VMIs
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 https://github.com/kubevirt/kubevirt/issues/11128
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.
- [ ] Design: A design document was considered and is present (link) or not required
- [ ] PR: The PR description is expressive enough and will help future contributors
- [ ] Code: Write code that humans can understand and Keep it simple
- [ ] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
- [ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
- [ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
- [ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
- [ ] Community: Announcement to kubevirt-dev was considered
Release note:
None
cc @brianmcarey
Is there a way to test the changes in CI?
replaces https://github.com/kubevirt/kubevirt/pull/11131
Thanks What about a script instead having it integral part of kubevirtci ?
@oshoval can you elaborate more about the script? Where will it live? How will it be invoked in CI?
@oshoval can you elaborate more about the script? Where will it live? How will it be invoked in CI?
script like this https://github.com/kubevirt/cluster-network-addons-operator/blob/main/hack/deploy-kubevirt.sh that will be part of kubevirt hack folder for example
i see you tried https://github.com/kubevirt/kubevirt/pull/11131 question is if it can be done all in a standalone file, with manifests downloaded ad hoc according version ? imho if so, kubevirt fits better but i see there was discussion about it already
@oshoval it is not desirable to have a script in kubevirt since these manifests don't age well. Instead this was the preferred option. Adding @brianmcarey for now thoughts on this.
question is if it can be done all in a standalone file, with manifests downloaded ad hoc according version ? imho if so, kubevirt fits better but i see there was discussion about it already
No not all files can be downloaded. There are kubevirt specific manifest files which are not available anywhere else @oshoval
@oshoval it is not desirable to have a script in kubevirt since these manifests don't age well. Instead this was the preferred option. Adding @brianmcarey for now thoughts on this.
Thanks for this @alaypatel07 - I think this is the correct place for it as it will follow the same pattern as what we do for deploying the prometheus stack in kubevirtci clusters.
Can you copy the manifests for the the k8s-1.30 & k8s-1.28 providers too please as they could be useful there as well?
/cc
@brianmcarey apologies for latency. Added 1.28 and 1.30 providers.
Also would it make sense to KUBEVIRT_DEPLOY_KWOK=true to check-cluster-up.sh as it is done here for prometheus -
@brianmcarey I have added a separate commit to set this variable to true. I could probably drop it later once the changes have been tested
/test check-provision-k8s-1.30
@brianmcarey addressed both the comments, PTAL
/lgtm cancel
the check-provision jobs have kustomize errors - https://prow.ci.kubevirt.io/view/gs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirtci/1178/check-provision-k8s-1.28/1793607771317342208#1:build-log.txt%3A2556
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: brianmcarey
The full list of commands accepted by this bot can be found here.
The pull request process is described here
- ~~OWNERS~~ [brianmcarey]
Approvers can indicate their approval by writing /approve
in a comment
Approvers can cancel approval by writing /approve cancel
in a comment
/lgtm
@alaypatel07: The following test failed, say /retest
to rerun all failed tests or /retest-required
to rerun all mandatory failed tests:
Test name | Commit | Details | Required | Rerun command |
---|---|---|---|---|
check-up-kind-1.27-vgpu | a42c7b2be67c4de19ddd5b45de3f4480f580fab8 | link | false | /test check-up-kind-1.27-vgpu |
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.
not sure why the 1.30 job continuously fails. Seems unrelated to the changes in the PR