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
Kubevirt CSI StorageClass mapping API #2528
Conversation
[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 |
✅ Deploy Preview for hypershift-docs ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
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.
Other than the json naming I think it's probably fine as is but some minor suggestions mostly about naming.
api/v1alpha1/hostedcluster_types.go
Outdated
// Defaults to false | ||
// +optional | ||
// +kubebuilder:validation:Optional | ||
Disable bool `json:"Disable,omitempty"` |
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.
json disable
not Disable
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.
Why is this needed? Why not just delete all mappings?
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.
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.
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.
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?
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.
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
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.
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
api/v1alpha1/hostedcluster_types.go
Outdated
// | ||
// +optional | ||
// +kubebuilder:validation:Optional | ||
StorageClassMapping []KubevirtCSIMapping `json:"StorageClassMapping,omitempty"` |
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.
json storageClassMapping
api/v1alpha1/hostedcluster_types.go
Outdated
// +kubebuilder:validation:Optional | ||
// +optional | ||
// +immutable | ||
CSIDriver *KubevirtCSIDriverSpec `json:"csiDriver,omitempty"` |
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.
Finally, StorageDriver
instead of CSIDriver
api/v1alpha1/hostedcluster_types.go
Outdated
StorageClassMapping []KubevirtCSIMapping `json:"StorageClassMapping,omitempty"` | ||
} | ||
|
||
type KubevirtCSIMapping struct { |
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.
I like KubevirtStorageClassMapping
or StorageClassMapping
better but again whatever
api/v1alpha1/hostedcluster_types.go
Outdated
@@ -697,6 +697,39 @@ type KubevirtPlatformCredentials struct { | |||
InfraNamespace string `json:"infraNamespace"` | |||
} | |||
|
|||
type KubevirtCSIDriverSpec struct { |
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.
I like KubevirtStorageDriverSpec
better but whatever.
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.
me too
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. |
1392c1a
to
43eda0b
Compare
api/v1alpha1/hostedcluster_types.go
Outdated
Manual *KubevirtManualStorageClassMapping `json:"manual,omitempty"` | ||
} | ||
|
||
type KubevirtManualStorageClassMapping struct { |
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.
Maybe KubevirtStorageDriverConfig
? Especially if there may eventually be other stuff in 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.
yep, fixed.
43eda0b
to
c65af78
Compare
c65af78
to
6f5ef9b
Compare
bc79b53
to
842c536
Compare
842c536
to
d5928ec
Compare
|
||
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, |
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.
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?
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.
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 |
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.
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
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.
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>
d5928ec
to
2e46670
Compare
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.
/lgtm
// +kubebuilder:validation:Optional | ||
// +optional | ||
// +immutable | ||
// +kubebuilder:validation:XValidation:rule="self == oldSelf", message="storageDriver is immutable" |
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.
I wonder if only this validation is necessary? But I guess the others probably don't hurt
/hold Revision 2e46670 was retested 3 times: holding |
/test e2e-aws |
@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. |
/test e2e-aws |
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.
Disable kubevirt csi entirely
Mapping infra storageclasses into guest