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
KubeVirt CSI Driver Integration #1733
KubeVirt CSI Driver Integration #1733
Conversation
2418a3d
to
6e3475d
Compare
6e3475d
to
0e9106c
Compare
This should be good to go now that the kubevirt-csi-driver is in the 4.12 release payload. kubevirt test lanes pass. |
control-plane-operator/controllers/hostedcontrolplane/csi/kubevirt/files/controller.yaml
Show resolved
Hide resolved
metadata: | ||
name: kubevirt-csi-controller-cr | ||
rules: | ||
# Allow listing and creating CRDs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
which new CRDs are needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
they aren't anymore. I removed this and fixed it upstream as well.
crclient "sigs.k8s.io/controller-runtime/pkg/client" | ||
) | ||
|
||
//go:embed files/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we either put this into support/ as in https://github.com/openshift/hypershift/pull/1698/files#diff-091a3abbf9e278c6f5cd74ca5fb7094a370f2a57c8c13c3f6568a6cc049ed8ea
Also why particular reason why using yaml here vs golang?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These yamls are a slightly modified version of the yamls sourced from the deploy yaml in the kubevirt-csi repo. I'll be modifying the kubevirt-csi repo yamls to match what we had to do for hypershift, so eventually they should be a 1:1 reflection of one another. The idea would be that when we test kubevirt-csi upstream, we'd be using the same yamls that get sourced into hypershift... but we're not 100% there yet.
In the medium term, we're looking to converge with the CSO which will involve sourcing yaml similar to what we're doing here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we use yamls the must*
functions already exists in olm/assets, please move them to support/assets and reuse them.
And you need to make sure to call SetDefaults()
over it, see https://github.com/openshift/hypershift/pull/1698/files#r987870941
Also we'd preferably want to follow the same approach for all components, i.e. atm that's golang though I can see the benefit for this case as we are mirroring.
control-plane-operator/controllers/hostedcontrolplane/csi/kubevirt/kubevirt.go
Show resolved
Hide resolved
func (r *HostedControlPlaneReconciler) reconcileCSIDriver(ctx context.Context, hcp *hyperv1.HostedControlPlane, releaseImage *releaseinfo.ReleaseImage, createOrUpdate upsert.CreateOrUpdateFN) error { | ||
switch hcp.Spec.Platform.Type { | ||
case hyperv1.KubevirtPlatform: | ||
err := kubevirtcsi.ReconcileInfra(r.Client, hcp, ctx, createOrUpdate, releaseImage.ComponentImages()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are other platforms expected to reconcile here too or should the storage operator do that?
Does this need to be clarified here https://github.com/openshift/enhancements/blob/master/enhancements/storage/storage-hypershift.md?
How does this PR interacts with #1698?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are other platforms expected to reconcile here too or should the storage operator do that? Does this need to be clarified here
most likely other drivers should be laid down by the cso and not the hcp or hcco. KubeVirt is a little different at the moment though.
How does this PR interacts with #1698?
We started planning kubevirt csi driver integration before the CSO started their reference implementation with aws. Essentially both our kubevirt csi integration effort and the CSO's effort occurred in parallel. We understood this was happening and plan to (attempt to) converge with the CSO in 4.13 once they have an established pattern for deploying into the HCP that we can follow.
Converging with the CSO might be slightly challenging though, which is something we'll be investigating soon. Due to the nested nature of the driver (requiring api access to both mgmt and guest clusters) kubevirt csi has some unique requirements that other csi drivers (like aws) do not have.
For now, we'd like to be able to begin exercising the KubeVirt csi driver using the integration method we have here. A decision about how to handle this long term will be addressed before KubeVirt goes GA (4.13+)
can we please conflate commits in to a single one? |
thanks @davidvossel looks great, dropped some questions. |
Signed-off-by: David Vossel <davidvossel@gmail.com> Co-authored-by: isaacdorfman <isaac.i.dorfman@gmail.com>
0e9106c
to
420b758
Compare
yes
@enxebre, thanks for the review. All your comments should be addressed now |
containers: | ||
- name: csi-driver | ||
imagePullPolicy: Always | ||
image: quay.io/dvossel/kubevirt-csi-driver:latest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we please update this image to come from the payload?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fyi for anyone reviewing this. the images are all overwritten in these yaml files using the release payload
privileged: true | ||
allowPrivilegeEscalation: true | ||
imagePullPolicy: Always | ||
image: quay.io/dvossel/kubevirt-csi-driver:latest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we please update this image to come from the payload?
- name: csi-node-driver-registrar | ||
securityContext: | ||
privileged: true | ||
image: quay.io/openshift/origin-csi-node-driver-registrar:latest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can not use latest here, since the hcp is versioned we must use tagged versions
for i, container := range controller.Spec.Template.Spec.Containers { | ||
switch container.Name { | ||
case "csi-driver": | ||
controller.Spec.Template.Spec.Containers[i].Image = csiDriverImage | ||
case "csi-provisioner": | ||
controller.Spec.Template.Spec.Containers[i].Image = csiProvisionerImage | ||
case "csi-attacher": | ||
controller.Spec.Template.Spec.Containers[i].Image = csiAttacherImage | ||
case "csi-liveness-probe": | ||
controller.Spec.Template.Spec.Containers[i].Image = csiLivenessProbeImage | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@enxebre the images in the yaml are overwritten using images from the release payload here.
for i, container := range ds.Spec.Template.Spec.Containers { | ||
switch container.Name { | ||
case "csi-driver": | ||
ds.Spec.Template.Spec.Containers[i].Image = csiDriverImage | ||
case "csi-node-driver-registrar": | ||
ds.Spec.Template.Spec.Containers[i].Image = csiNodeDriverRegistrarImage | ||
case "csi-liveness-probe": | ||
ds.Spec.Template.Spec.Containers[i].Image = csiLivenessProbeImage | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and daemonset images are overwritten here.
I think this still needs to be addressed?
|
@enxebre That was already done. Look at the
Then ApplyTo is called when the controller deployment is created. |
/test e2e-aws |
1 similar comment
/test e2e-aws |
/lgtm Code paths are isolated to kubevirt platform and this is a blocker to get e2e signal on that platform. If there is an undiscovered issue with the reconciliation in PR, it will also block kubevirt e2e from pass and will have to be fixed at that time. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: davidvossel, sjenning The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@davidvossel: 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/test-infra repository. I understand the commands that are listed here. |
There are two components for CSI drivers, the "controller" deployment, which works at the cluster level, and the "node" daemonset which works on the individual node level. In general this driver works by mirroring usage of storage classes in the infra cluster to the guest cluster.
The "controller" deployment is laid down by the CPO within the hosted control plane namespace. We put this in the hosted control plane namespace because the "controller" needs access to both the guest and infra clusters in order to mirror PVCs.
The "node" daemonset portion is laid down within the guest cluster by the HCCO. This component requires no access to the infra cluster and works purely within the guest cluster.
It's possible we will transition the KubeVirt CSI Driver's installation to the cluster-storage-operator (CSO) in the future, but given our unique scenario where infra access is required for our driver to work, we have included the integration into the CPO and HCCO for now.
This work supersedes the WIP pr #1733