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

Upgrade VolumeSubpathEnvExpansion to Beta #65769

Conversation

kevtaylor
Copy link
Contributor

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:

Upgrade VolumeSubpathEnvExpansion feature gate to Beta

@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. size/S Denotes a PR that changes 10-29 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Jul 3, 2018
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: kevtaylor
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: soltysh

Assign the PR to them by writing /assign @soltysh in a comment when ready.

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

@k8s-ci-robot k8s-ci-robot requested review from shyamjvs and thockin July 3, 2018 15:18
@thockin
Copy link
Member

thockin commented Jul 3, 2018

Strictly speaking this is a breaking change. A directory named $(foo) or even $(rm -rf ..) is technically valid. This feature breaks that.

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. subPathFrom as was done for EnvVar.ValueFrom. I'd say this PR should NOT go in until that is changed.

I didn't track all the original work - I assume this properly handles $$ escape and that we validate that FOO="../../../../../proc is not allowed?

Edit: for future, the way to make sure I see a PR is to ASSIGN it to me :)

@k8s-ci-robot k8s-ci-robot added sig/architecture Categorizes an issue or PR as relevant to SIG Architecture. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API labels Jul 3, 2018
@thockin thockin self-assigned this Jul 3, 2018
@kevtaylor
Copy link
Contributor Author

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.

@kevtaylor
Copy link
Contributor Author

/cc @msau42

@k8s-ci-robot k8s-ci-robot requested a review from msau42 July 4, 2018 06:20
@idealhack
Copy link
Member

/ok-to-test

@k8s-ci-robot k8s-ci-robot removed the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label Jul 4, 2018
@thockin
Copy link
Member

thockin commented Jul 6, 2018 via email

@kevtaylor
Copy link
Contributor Author

@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

@liggitt
Copy link
Member

liggitt commented Jul 6, 2018

@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.

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.

Copy link
Member

@thockin thockin left a 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},
Copy link
Member

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.

@msau42
Copy link
Member

msau42 commented Aug 23, 2018

Yes I agree we should consider an alternative API.

@thockin
Copy link
Member

thockin commented Aug 23, 2018

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 subPathFrom because we need catenated variables. What about subPathExpr or subPathTemplate which is explicitly an env-substituted value and mutually exclusive with subPath?

@thockin thockin added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Aug 23, 2018
@kevtaylor
Copy link
Contributor Author

@thockin I think the use of the word template implies a lot more functionality than is actually occurring so I prefer subPathExpr

@k8s-ci-robot k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Aug 23, 2018
@k8s-ci-robot
Copy link
Contributor

@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.

@thockin
Copy link
Member

thockin commented Aug 24, 2018

Please feel free to find a better name - those were just seeds...

@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Nov 22, 2018
@msau42
Copy link
Member

msau42 commented Nov 22, 2018

Can this be closed? We have a KEP for the new proposal that we will pursue in 1.14: kubernetes/community#2871

@kevtaylor
Copy link
Contributor Author

/close

@k8s-ci-robot
Copy link
Contributor

@kevtaylor: Closed this PR.

In response to this:

/close

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.

@kevtaylor kevtaylor deleted the feature/volumesubpathenvexpansion-beta branch March 28, 2019 13:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/architecture Categorizes an issue or PR as relevant to SIG Architecture. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Upgrade VolumeSubpathEnvExpansion to Beta
7 participants