Usage of cluster-up/virtctl.sh

Daniel Hiller

unread,

Sep 20, 2024, 6:59:46 AM9/20/24

to kubevirt-dev

Hey folks,

while I was working on [1] (moving cluster-up folder from kubevirtci into it's own folder) I noticed that there's a deep coupling of kubevirtci to kubevirt present, which manifests in the script cluster-up/virtctl.sh [2] expecting the virtctl binary to be present in path `_out/virtctl/virtctl`. (issue [3]) .

While I figured that this is a leftover of the move from kubevirtci into it's own repository, I was also wondering where that script might be used in our codebase - a GitHub search fortunately yielded only a couple of results. Most of these are from k/kubevirt, which are tackled by this commit [4] , which effectively creates it's own virtctl.sh inside hack/ folder.

Other repos that show such calls:

* kubevirt/containerized-data-importer

* kubevirt/common-instancetypes

* kubevirt/community

* kubevirt/machine-remediation (likely one of the repos ready to archive - last change was 4 years ago)

* kubevirt/user-guide

My stance on this would be to remove the virtctl.sh script from kubevirtci, but before we do that I'd like to ask which usages I might have missed - especially since there's a nasty delegation from cluster-up/kubectl.sh in place [5] [6] .

Thank you for your help!

Happy Friday, best

Daniel

[1]: https://github.com/kubevirt/kubevirt/pull/12872

[2]: https://github.com/kubevirt/kubevirtci/blob/main/cluster-up/virtctl.sh

[3]: https://github.com/kubevirt/kubevirtci/issues/1277

[4]: https://github.com/kubevirt/kubevirt/pull/12872/commits/a12552da5217bc2b511a99d1ead8f6e4d3c9e875

[5]: https://github.com/kubevirt/kubevirtci/blob/d1426386b781cd35e2387ea599fa2bb6c9d5006c/cluster-up/kubectl.sh#L34

[6]: https://github.com/kubevirt/kubevirtci/blob/d1426386b781cd35e2387ea599fa2bb6c9d5006c/cluster-up/kubectl.sh#L37

--

Kind regards,

Daniel Hiller

He / Him / His

Senior Software Engineer, KubeVirt CI, OpenShift Virtualization

Red Hat

dhi...@redhat.com

Red Hat GmbH, Registered seat: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Germany  
Commercial register: Amtsgericht München/Munich, HRB 153243,
Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross

Luboslav Pivarc

unread,

Sep 20, 2024, 9:13:30 AM9/20/24

to Daniel Hiller, kubevirt-dev

On Fri, Sep 20, 2024 at 12:59 PM Daniel Hiller <dhi...@redhat.com> wrote:

Hey folks,

while I was working on [1] (moving cluster-up folder from kubevirtci into it's own folder) I noticed that there's a deep coupling of kubevirtci to kubevirt present, which manifests in the script cluster-up/virtctl.sh [2] expecting the virtctl binary to be present in path `_out/virtctl/virtctl`. (issue [3]) .

While I figured that this is a leftover of the move from kubevirtci into it's own repository, I was also wondering where that script might be used in our codebase - a GitHub search fortunately yielded only a couple of results. Most of these are from k/kubevirt, which are tackled by this commit [4] , which effectively creates it's own virtctl.sh inside hack/ folder.

Other repos that show such calls:
* kubevirt/containerized-data-importer
* kubevirt/common-instancetypes
* kubevirt/community
* kubevirt/machine-remediation (likely one of the repos ready to archive - last change was 4 years ago)
* kubevirt/user-guide

My stance on this would be to remove the virtctl.sh script from kubevirtci, but before we do that I'd like to ask which usages I might have missed - especially since there's a nasty delegation from cluster-up/kubectl.sh in place [5] [6] .

+1 Self containing kubevirtci. We can always just do it and see who breaks ;) (if you don't get any feedback)

-Lubo

Thank you for your help!

Happy Friday, best
Daniel

[1]: https://github.com/kubevirt/kubevirt/pull/12872
[2]: https://github.com/kubevirt/kubevirtci/blob/main/cluster-up/virtctl.sh
[3]: https://github.com/kubevirt/kubevirtci/issues/1277
[4]: https://github.com/kubevirt/kubevirt/pull/12872/commits/a12552da5217bc2b511a99d1ead8f6e4d3c9e875
[5]: https://github.com/kubevirt/kubevirtci/blob/d1426386b781cd35e2387ea599fa2bb6c9d5006c/cluster-up/kubectl.sh#L34
[6]: https://github.com/kubevirt/kubevirtci/blob/d1426386b781cd35e2387ea599fa2bb6c9d5006c/cluster-up/kubectl.sh#L37
--
Kind regards,

Daniel Hiller
He / Him / His
Senior Software Engineer, KubeVirt CI, OpenShift Virtualization
Red Hat
dhi...@redhat.com
Red Hat GmbH, Registered seat: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Germany  
Commercial register: Amtsgericht München/Munich, HRB 153243,
Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross 

--
You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubevirt-dev/CAK%2BeyL5YLGcqf9upZQbE%3DQ7Q9nO%2BRh199YMpCr7%3DXPfQ3w40EA%40mail.gmail.com.

Felix Matouschek

unread,

Sep 20, 2024, 9:29:46 AM9/20/24

to Daniel Hiller, kubevirt-dev

From what I can tell, it shouldn't be a problem for common-instancetypes.

The places where virtctl is still used are only remains of the early functests implementation of this repository.