Open fabiand opened 5 years ago
This is certainly a thought that crossed my mind also, but this is also a general issue with there not beoing a Cluster API provider. Is this planned? Is this even a realistic usecase?
@fabiand I am not very clear about this issue, do you want to have kubevirt
by default there as part of disk image? My understanding is, we are going to provide minimal setup for openshift and if you want any adition component then add it on top.
Does kubevirt already converted as operator for Openshift?
First - I merely filed this to see how the echo on the idea is :)
@gbraad Well, there is this work https://github.com/kubermatic/machine-controller/pull/420/ which might help
@praveenkumar Well, it's not about installing KubeVirt ontop of OCP4, this issue is about using kubevirt as a backend for the ocp installer.
Well, it's not about installing KubeVirt ontop of OCP4, this issue is about using kubevirt as a backend for the ocp installer.
@fabiand ah, in that case doesn't this should be part of actual installer repo => https://github.com/openshift/installer/issues ?
right, I had the same answer. also, work that should be considered is that the installer does initial deployment of a target infrastructure using Terraform (ATM). After this, the installer targets these nodes with RHCOS and a config, and sets up the cluster. After this is finished, the cluster can be maintained and expanded using the the cluster API.
Maybe the funny thing is that with kubevirt we could deliver OKD on any kubernetes cluster ;) (where kubevirt runs)
@gbraad thanks for this explanation.
I'll close this bug, not sure if opening it on installre will stirr to much noise.
I am pretty sure they will respond it is NOT an installer isue, but rather openshift/os to get RHCOS to support Kubevirt.
Right, KubeVirt should be able to run RHCOS (should be able to do s right now), but then it's still about letting terraform (?) being able to speak to kubevirt to lay out th enodes. Not?
right. terraform is now currently embedded with the libvirt provider, but long term the idea would be to drop terraform. if there is a way to create the VMs in an easy way, abstracted, this might help. you already mentioned the libvirt provider would need to be forked? how different is it?
On Fri, Jan 25, 2019 at 5:26 PM Fabian Deutsch notifications@github.com wrote:
Right, KubeVirt should be able to run RHCOS (should be able to do s right now), but then it's still about letting terraform (?) being able to speak to kubevirt to lay out th enodes. Not?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
--
Gerard Braad | http://gbraad.nl [ Doing Open Source Matters ]
KubeVirt has a different APi than libvirt, obviously. But if you can create a libvirt VM, hten it's pretty trivial to create a KubeVirt VM from it. Images can be reused 1:1 and domxml/definition can be tranformed into a kubevirt ylma (best would be to do it the other way round: domxml from kubevirt yalm).
KubeVirt is like libvirt on a cluster.
Maybe it's easy to clone the libvirt provider to also support KubeVirt.