-
Notifications
You must be signed in to change notification settings - Fork 346
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
Pass VolumeAttributesClass Parameters as MutableParameters to CreateVolume #1068
Conversation
/assign @sunnylovestiramisu @msau42 |
Chasing down CI failures, but I believe they are largely (if not entirely) false positives caused by issues with the go version - this PR should be reasonably safe to review now, I don't anticipate any large or architectural changes. |
pkg/controller/controller.go
Outdated
@@ -596,6 +604,14 @@ func (p *csiProvisioner) prepareProvision(ctx context.Context, claim *v1.Persist | |||
} | |||
} | |||
|
|||
vacName := claim.Spec.VolumeAttributesClassName | |||
// TODO: For reviewers - Should we reject volumes that have a VAC specified if the VAC feature gate is disabled? |
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.
The csi spec states that "A Controller plugin MUST implement this RPC call if the plugin has the MODIFY_VOLUME controller capability. "
To consider backward compatibility I do not think we should reject the call. Maybe if there is a way to send a warning to users indicate that the VAC is not applied because of feature gate etc.
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 would it not be backwards compatible? A user would have to opt-in to specifying the VAC in their PVC.
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.
What if they downgrade their cluster and turn off the vac feature but the VAC is applied?
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.
Kubernetes doesn't support downgrades, although I'm not 100% sure what would happen if you disabled the API Server feature gate on a cluster with VACs already in it
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.
Kubernetes supports downgrades.
However, even with the help of the folks on #sig-architecture the best link that I could find was only the underlying design for API storage: https://kubernetes.io/docs/reference/using-api/deprecation-policy/
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 "doesn't support" is too strong of wording, but Kubernetes does not document any support for downgrading and it is widely considered unsafe: kubernetes/website#12327
That said, I'm not sure it really matters for the purpose of this question: My question is basically, if the volume does specify a VolumeAttributeClassName
(i.e. the feature flag is enabled at the API level and the user is using it) but the local external-provisioner
feature flag is disabled, what should we do?
Should we either (1) provision the volume as normal - ignoring the fact it has a VAC or (2) refuse to provision the volume and demand the user turns on the VAC feature flag or remove the VAC from the volume?
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.
KEP says that "API server gets requests of modify parameters in VolumeAttributesClass but does not act on it", which I read as the external-provisioner / resizer should not act on it and thus ignore vacName
.
Perhaps a little refactoring could help:
var vacName string
if utilfeature.DefaultFeatureGate.Enabled(features.VolumeAttributesClass) {
if claim.Spec.VolumeAttributesClassName != nil {
vacName = *claim.Spec.VolumeAttributesClassName
}
}
if vacName != "" {
...
}
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.
Much better than my version, I stole it wholesale for the next revision
3deff1e
to
e467de1
Compare
@ConnorJC3 API changes is merged now, please use upstream kubernetes repo instead. |
Bumped to use k8s 1.29.0-alpha.3 version. CI still broken because it uses go 1.20 |
Rebased on latest |
Makefile
Outdated
# TODO: Change in csi-release-tools before PR merge? | ||
export CSI_PROW_GO_VERSION_BUILD=1.21 |
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.
Yes, please send a PR for csi-release-tools. All sidecar releases for 1.29 will need a new go.
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.
Working on a PR, for now I modified the directory directly to hopefully unblock CI, although this will cause make test
to fail because it detects non-upstreamed changes
pkg/controller/controller.go
Outdated
@@ -596,6 +604,14 @@ func (p *csiProvisioner) prepareProvision(ctx context.Context, claim *v1.Persist | |||
} | |||
} | |||
|
|||
vacName := claim.Spec.VolumeAttributesClassName | |||
// TODO: For reviewers - Should we reject volumes that have a VAC specified if the VAC feature gate is disabled? |
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.
KEP says that "API server gets requests of modify parameters in VolumeAttributesClass but does not act on it", which I read as the external-provisioner / resizer should not act on it and thus ignore vacName
.
Perhaps a little refactoring could help:
var vacName string
if utilfeature.DefaultFeatureGate.Enabled(features.VolumeAttributesClass) {
if claim.Spec.VolumeAttributesClassName != nil {
vacName = *claim.Spec.VolumeAttributesClassName
}
}
if vacName != "" {
...
}
/lgtm |
@torredil: changing LGTM is restricted to collaborators In response to this:
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. |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ConnorJC3, jsafrane 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 |
csi-release-tools PR here: kubernetes-csi/csi-release-tools#238 |
release-tools have go 1.21 now |
Signed-off-by: Connor Catlett <conncatl@amazon.com>
Signed-off-by: Connor Catlett <conncatl@amazon.com>
Signed-off-by: Connor Catlett <conncatl@amazon.com>
…olume Signed-off-by: Connor Catlett <conncatl@amazon.com>
/lgtm |
What type of PR is this?
/kind feature
What this PR does / why we need it:
Implements the external-provisioner component of https://kep.k8s.io/3751
Which issue(s) this PR fixes:
Fixes #952
Special notes for your reviewer:
There are several places where I was unsure of the best action, marked with "TODO" comments, please answer those if you have a better answer than I do.
Breakdown by commit:
Update to go1.21
Required because the Kubernetes dependency that will be upgrading in the following commit references the go1.21-only slices library.
[TODO FIX AFTER PRS MERGE] Bump CSI spec, csi-test, and Kubernetes dependencies
Add VolumeAttributesClass feature flag
Adds a default-off VAC feature flag.
Pass VolumeAttributesClass Parameters as MutableParameters to CreateVolume
The meat of the PR: Adds the funcionality for VACs, as well as associated unit tests.
Does this PR introduce a user-facing change?: