Skip to content
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 StorageClass mapping API #2528

Merged
merged 1 commit into from May 25, 2023

Conversation

davidvossel
Copy link
Contributor

@davidvossel davidvossel commented May 5, 2023

The KubeVirt CSI driver allows passthrough of storageclasses within the mgmt/infra cluster (the cluster hosting the VMs) into the guest cluster.

Today, by default people automatically get a kubevirt csi driver storage class in their guest cluster that maps to the default storageclass of the infra cluster.

This PR aims to give users more flexibility over this functionality by allowing users to passthrough multiple infra storageclasses into their guest cluster as well as disabling kubevirt csi entirely.

Examples

Default behavior of passing through default infra storageclass into guest cluster. This works today and will continue to work after this new API is introduced.

apiVersion: hypershift.openshift.io/v1beta1
kind: HostedCluster
.
.
.
  platform:
    type: KubeVirt

Disable kubevirt csi entirely

apiVersion: hypershift.openshift.io/v1beta1
kind: HostedCluster
.
.
.
  platform:
    type: KubeVirt
    kubevirt:
        storageDriver:
            type: None

Mapping infra storageclasses into guest

apiVersion: hypershift.openshift.io/v1beta1
kind: HostedCluster
.
.
.
  platform:
    type: KubeVirt
    kubevirt:
        storageDriver:
            type: Manual
            manual:
                storageClassMapping:
                    - infraStorageClassName: ceph-rdb
                      guestStorageClassName: kubevirt-rdb
                    - infraStorageClassName: ceph-fs
                      guestStorageClassName: kubevirt-fs

@davidvossel davidvossel marked this pull request as draft May 5, 2023 20:02
@openshift-ci openshift-ci bot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. do-not-merge/needs-area labels May 5, 2023
@openshift-ci openshift-ci bot requested review from csrwng and enxebre May 5, 2023 20:03
@openshift-ci openshift-ci bot added area/cli Indicates the PR includes changes for CLI area/documentation Indicates the PR includes changes for documentation labels May 5, 2023
@openshift-ci
Copy link
Contributor

openshift-ci bot commented May 5, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: davidvossel

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added area/hypershift-operator Indicates the PR includes changes for the hypershift operator and API - outside an OCP release approved Indicates a PR has been approved by an approver from all required OWNERS files. and removed do-not-merge/needs-area labels May 5, 2023
@netlify
Copy link

netlify bot commented May 5, 2023

Deploy Preview for hypershift-docs ready!

Name Link
🔨 Latest commit 2e46670
🔍 Latest deploy log https://app.netlify.com/sites/hypershift-docs/deploys/646bb9848a0ed60008981cea
😎 Deploy Preview https://deploy-preview-2528--hypershift-docs.netlify.app/reference/api
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site settings.

Copy link

@mhenriks mhenriks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other than the json naming I think it's probably fine as is but some minor suggestions mostly about naming.

// Defaults to false
// +optional
// +kubebuilder:validation:Optional
Disable bool `json:"Disable,omitempty"`
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

json disable not Disable

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this needed? Why not just delete all mappings?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was hoping we could get away with some default behavior if no mappings are set. So, a zero length mapping slice would result in a default storageclass in the guest that maps to the default infra storageclass.

The disable bool would opt out of all kubevirt csi behavior.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be best for this map (or something in status) to mirror what mappings actually exist. Also, instead of just a bool maybe an enum like None Default Explicit. Default could be Default and it would map the default storage class automatically. Explicit would be just what's in the map

Related question when mapping over the default storage class, what will it be named?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Related question when mapping over the default storage class, what will it be named?

right now, the guest magically gets a storageclass called kubevirt-csi-infra-default by default

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

think it would be best for this map (or something in status) to mirror what mappings actually exist. Also, instead of just a bool maybe an enum like None Default Explicit. Default could be Default and it would map the default storage class automatically. Explicit would be just what's in the map

I think an enum is a good idea here and makes this less confusing. I'll work with that a bit

//
// +optional
// +kubebuilder:validation:Optional
StorageClassMapping []KubevirtCSIMapping `json:"StorageClassMapping,omitempty"`
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

json storageClassMapping

// +kubebuilder:validation:Optional
// +optional
// +immutable
CSIDriver *KubevirtCSIDriverSpec `json:"csiDriver,omitempty"`
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Finally, StorageDriver instead of CSIDriver

StorageClassMapping []KubevirtCSIMapping `json:"StorageClassMapping,omitempty"`
}

type KubevirtCSIMapping struct {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like KubevirtStorageClassMapping or StorageClassMapping better but again whatever

@@ -697,6 +697,39 @@ type KubevirtPlatformCredentials struct {
InfraNamespace string `json:"infraNamespace"`
}

type KubevirtCSIDriverSpec struct {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like KubevirtStorageDriverSpec better but whatever.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

me too

@awels
Copy link
Contributor

awels commented May 8, 2023

Agreed with Michael, and any reason we are also putting this in the alpha CR? if you just put it in the beta, it gives people motivation to use the beta version.

@davidvossel
Copy link
Contributor Author

Agreed with Michael, and any reason we are also putting this in the alpha CR? if you just put it in the beta, it gives people motivation to use the beta version.

alpha and beta are mirrors of one another right now.

@awels
Copy link
Contributor

awels commented May 8, 2023

Agreed with Michael, and any reason we are also putting this in the alpha CR? if you just put it in the beta, it gives people motivation to use the beta version.

alpha and beta are mirrors of one another right now.

Okay, so what is the point of having a beta if it is the same as alpha. I understand what is happening, we did the same thing for the longest time in CDI as well. I am just suggesting that is okay for beta to diverge from alpha, and it gives people motivation to use the beta version.

@davidvossel davidvossel force-pushed the csi-mappings-v1 branch 4 times, most recently from 1392c1a to 43eda0b Compare May 8, 2023 17:24
@davidvossel
Copy link
Contributor Author

@mhenriks @awels updated.

Manual *KubevirtManualStorageClassMapping `json:"manual,omitempty"`
}

type KubevirtManualStorageClassMapping struct {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe KubevirtStorageDriverConfig? Especially if there may eventually be other stuff in here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep, fixed.

@openshift-ci openshift-ci bot added the area/control-plane-operator Indicates the PR includes changes for the control plane operator - in an OCP release label May 16, 2023
@davidvossel davidvossel force-pushed the csi-mappings-v1 branch 3 times, most recently from bc79b53 to 842c536 Compare May 18, 2023 19:35
@davidvossel davidvossel marked this pull request as ready for review May 18, 2023 19:38
@openshift-ci openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label May 18, 2023
@davidvossel davidvossel changed the title [Draft] Kubevirt CSI StorageClass mapping API Kubevirt CSI StorageClass mapping API May 18, 2023

cm.Data = map[string]string{
"infraClusterNamespace": cm.Namespace,
"infraClusterLabels": fmt.Sprintf("%s=%s", hyperv1.InfraIDLabel, infraID),
"infraClusterLabels": fmt.Sprintf("%s=%s", hyperv1.InfraIDLabel, hcp.Spec.InfraID),
"infraStorageClassEnforcement": storageClassEnforcement,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct me if I'm wrong, but it appears that the value of storageClassEnforcement becomes the value of the INFRA_STORAGE_CLASS_ENFORCEMENT environment variable for the CSI driver via the driver-config config map?

So changing the type/mapping will update the configmap. But that will have no effect on the driver once it is running. Is that "good enough?" Should the driver be changed read this configmap key as a file instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, you understand it correctly.

Right now we're locked in to this enforcement config once the driver starts, and we can't change it. We weren't really thinking about how these values could potentially mutate when the kubevirt-csi functionality was added. It's likely I was under the impression it wouldn't be practical to change the StorageClass mappings after the driver starts, so I didn't even consider mutability then.

// storageclass will be present for the corresponding guest clusters storageclass.
//
// +optional
// +immutable

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For my info, do you mind sharing how immutability is actually enforced here? I don't anything at the code/schema level in this pr that makes it possible. But I'm sure I'm missing something

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed... Yeah i think something changed in the way the crd schema is built recently. I added a CEL validation to enforce all this immutability stuff, and it seems to work.

Signed-off-by: David Vossel <davidvossel@gmail.com>
Copy link

@mhenriks mhenriks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

// +kubebuilder:validation:Optional
// +optional
// +immutable
// +kubebuilder:validation:XValidation:rule="self == oldSelf", message="storageDriver is immutable"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if only this validation is necessary? But I guess the others probably don't hurt

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label May 23, 2023
@openshift-ci-robot
Copy link

/retest-required

Remaining retests: 0 against base HEAD a3ebcaf and 2 for PR HEAD 2e46670 in total

@openshift-ci-robot
Copy link

/retest-required

Remaining retests: 0 against base HEAD f03113a and 1 for PR HEAD 2e46670 in total

@openshift-ci-robot
Copy link

/retest-required

Remaining retests: 0 against base HEAD 8861506 and 0 for PR HEAD 2e46670 in total

@openshift-ci-robot
Copy link

/hold

Revision 2e46670 was retested 3 times: holding

@openshift-ci openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label May 24, 2023
@davidvossel
Copy link
Contributor Author

/test e2e-aws

@openshift-ci
Copy link
Contributor

openshift-ci bot commented May 24, 2023

@davidvossel: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/e2e-ibmcloud-iks 2e46670 link false /test e2e-ibmcloud-iks
ci/prow/e2e-ibmcloud-roks 2e46670 link false /test e2e-ibmcloud-roks

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.

@davidvossel
Copy link
Contributor Author

/test e2e-aws
/hold cancel

@openshift-ci openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label May 25, 2023
@openshift-merge-robot openshift-merge-robot merged commit b5323e4 into openshift:main May 25, 2023
12 of 14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. area/cli Indicates the PR includes changes for CLI area/control-plane-operator Indicates the PR includes changes for the control plane operator - in an OCP release area/documentation Indicates the PR includes changes for documentation area/hypershift-operator Indicates the PR includes changes for the hypershift operator and API - outside an OCP release lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants