-
Notifications
You must be signed in to change notification settings - Fork 40.1k
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
Upgrade VolumeSubpathEnvExpansion to Beta #65769
Upgrade VolumeSubpathEnvExpansion to Beta #65769
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: kevtaylor Assign the PR to them by writing 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 |
Strictly speaking this is a breaking change. A directory named I didn't see the original PR, so I apologize for not reviewing it then. This is the sort of change that needs sig-arch to review (@jdumars @kubernetes/sig-architecture-api-reviews) (the process is in development, so no indictment here :). It's a good example of an API change that DOESN'T touch a types.go file, because we don't document alpha features in the comments. The compatible way to do this would be to add a new field, e.g. I didn't track all the original work - I assume this properly handles Edit: for future, the way to make sure I see a PR is to ASSIGN it to me :) |
Not sure why you think it is a breaking change as it doesn't alter the existing subpath creation or validation
There are tests for backticks and absolute paths to ensure no validation was violated. So can't see the need for introduction of a new element but I guess that's your perogative as code owners. |
/cc @msau42 |
/ok-to-test |
My point was that someone COULD be using a subpath that was ACTUALLY the
literal `$(FOOBAR)`, since that is a legitimate path name. After this
change, that can change meaning to expand the variable, breaking users.
Another example would be someone using a subpath with `$$` in it - that
will also get changed and break users.
In short, the entirety of the namespace of subpath strings belongs to the
end user. You can't intrude on it in any way without being a breaking
change.
Sorry :(
…On Tue, Jul 3, 2018 at 11:15 PM Kevin Taylor ***@***.***> wrote:
Not sure why you think it is a breaking change as it doesn't alter the
existing subpath creation or validation
setting env to "" gives /logs/hello.txt
setting env to " " gives /logs/ /hello.txt
setting env variable to $(PODX_NAME) gives /logs/$(PODX_NAME)/hello.txt
There are tests for backticks and absolute paths to ensure no validation
was violated.
So can't see the need for introduction of a new element but I guess that's
your perogative as code owners.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#65769 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFVgVHphtXMUI5oueKF479UBpzYqWWouks5uDF2NgaJpZM4VBJlw>
.
|
@thockin Thanks for the clarity and yes I see your point on this edge case but that would be a very unconventional use of file systems to include $ in files/folders However, in our defence the massive workarounds that we had to do to implement this and the subsequent vulnerabilities that the team uncovered as a result of it are in my opinion a greater justification for this feature than the edge case(s) that you highlight. Also, not sure if you saw this but Michelle Au raised #64045 for a wider discussion |
I agree with @thockin that it isn't acceptable to break the meaning of the existing field. That doesn't preclude the introduction of a mutually exclusive parallel field with expansion semantics. |
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.
Strictly speaking this is a breaking change, and should not be allowed. $(FOO)
is a valid (if awkward) subPath today and after this PR it changes meaning (for all users, by default). I swear I said this before but I can't find proof of that via github's awesome UIs.
How should we proceed? It's probably unlikely to be a real problem in practice, but on principle we SHOULD NOT be doing changes like this.
I scanned the alpha PR - I don't think we considered a whole lot of other options. It's likely that whatever we do here will be looked at as precedent for further changes, so we need to be careful.
I'm holding this PR until discussion, sorry.
@@ -397,7 +397,7 @@ var defaultKubernetesFeatureGates = map[utilfeature.Feature]utilfeature.FeatureS | |||
BalanceAttachedNodeVolumes: {Default: false, PreRelease: utilfeature.Alpha}, | |||
DynamicProvisioningScheduling: {Default: false, PreRelease: utilfeature.Alpha}, | |||
PodReadinessGates: {Default: false, PreRelease: utilfeature.Beta}, | |||
VolumeSubpathEnvExpansion: {Default: false, PreRelease: utilfeature.Alpha}, | |||
VolumeSubpathEnvExpansion: {Default: true, PreRelease: utilfeature.Beta}, |
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 comments around the SubPath field need to be updated to indicate that it supports variable expansion.
Yes I agree we should consider an alternative API. |
I couldn't find it because it was in this thread, LOL. Jordan's suggestion is better - can we add a new field? We ruled out |
@thockin I think the use of the word template implies a lot more functionality than is actually occurring so I prefer |
@kevtaylor: PR needs rebase. 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. |
Please feel free to find a better name - those were just seeds... |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Can this be closed? We have a KEP for the new proposal that we will pursue in 1.14: kubernetes/community#2871 |
/close |
@kevtaylor: Closed this PR. 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. |
What this PR does / why we need it:
Promotes the alpha feature gate VolumeSubpathEnvExpansion to Beta for milestone 1.12
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #64604
Special notes for your reviewer:
Release note: