-
Notifications
You must be signed in to change notification settings - Fork 459
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
Add enhancement for supporting user namespaces #1649
Add enhancement for supporting user namespaces #1649
Conversation
/hold @deads2k is on vacation and should review this. I'm opening it for preliminary review though |
31705ee
to
55032bf
Compare
SCC piece openshift/api#1939 |
TPNU piece openshift/api#1940 |
95cdfa8
to
3605bb1
Compare
3605bb1
to
edb1513
Compare
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rphillips 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 |
/hold |
for API and auth team reviews |
2dcdba1
to
4176f0e
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.
I am currently checking the impact on SCCs overall, but I added my first thoughts on reading it.
b8fc9cb
to
afb1d1f
Compare
/hold cancel |
79c3553
to
ed340f4
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.
some changes.
// NamespaceLevelEmpty will set to the default, which is currently "AllowHostLevel". | ||
NamespaceLevelEmpty NamespaceLevelType = "" |
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.
This field is closer to user workloads than to configuration. This one we'll default to AllowHostLevel
instead of leaving empty because we know the intent will never change
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.
sorry I don't think I fully understand--do you want me to drop this or keep 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.
Empty should not be allowed. We should default the value.
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.
If we ever wanted to start enforcing this, would we not want to change the default? Is the expectation there that we create a new version of the SCC and folks move over to it? In which case, having an API default doesn't really matter as we will create the object with the new value we desire
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 dropped empty.
Is the expectation there that we create a new version of the SCC and folks move over to it?
this is my understanding of the approach
The `MinimalKubeletVersion` feature is to fix this problem. If all apiservers support this field upon GA, then a cluster admin can set the field and ensure | ||
their kubelets are new enough to certainly support user namespaces. This frees the apiserver to relax validation and GA these SCC fields. | ||
|
||
This feature is not required for TechPreview, but is required for GA if we do not want to wait until 1.33/4.20 to GA this feature (the point where the oldest |
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.
FeatureGate is still not enabled for kubelets in 1.31/4.18, so if MinimalKubeletVersion is not developed, it looks like 4.22 is the earliest possible. If MinimalKubeletVersion is developed, the earliest is 4.18.
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 4.22?
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 4.22?
Because as it currently stands 1.31/4.18 kubelets won't correctly honor the field. 4.19 becomes the first level where it might be properly honored and we have 4.19+3.
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.
Adding some nits/typos I came across while reading this.
ed340f4
to
37a6e99
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.
Added a suggestion and a side-note for clarity.
e819dc7
to
74c2cfe
Compare
/lgtm Holding for @deads2k to finish his review and approve. /hold |
74c2cfe
to
a77d43a
Compare
Signed-off-by: Peter Hunt <pehunt@redhat.com>
a77d43a
to
b11957b
Compare
/lgtm |
@haircommander: all tests passed! 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-sigs/prow repository. I understand the commands that are listed here. |
related https://issues.redhat.com/browse/OCPNODE-2337
cc @rphillips @mrunalp