-
Notifications
You must be signed in to change notification settings - Fork 15.1k
content: Mention containerd 1.7 supports user namespaces #40264
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
Conversation
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site settings. |
SergeyKanzhelev
left a comment
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
|
Rebased and pushed to see if the CI works now. @SergeyKanzhelev can you re-LGTM? :) |
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site settings. |
SergeyKanzhelev
left a comment
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
sftim
left a comment
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 very strongly recommend revising this before we merge it.
content/en/docs/tasks/configure-pod-container/user-namespaces.md
Outdated
Show resolved
Hide resolved
content/en/docs/tasks/configure-pod-container/user-namespaces.md
Outdated
Show resolved
Hide resolved
|
In fact, with #40264 (review) in mind: /lgtm cancel |
fb71333 to
b00862e
Compare
| * containerd: support is planned for the 1.7 release. See containerd | ||
| issue [#7063][containerd-userns-issue] for more details. | ||
| * containerd: version 1.7 supports user namespaces for containers, compatible | ||
| with Kubernetes {{< skew currentVersion >}}. If you are running a different |
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 will break if we apply this to 1.25. This will point to kubernetes 1.24, IIUC, which simply doesn't support user namespaces
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, I don't recommend backporting this line to the v1.25 docs
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.
IMHO it will be simpler if we just use the versions, as they are not relative to any k8s version. In fact, here just expands to k8s 1.26, but this is true with k8s 1.25 too.
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'd prefer calling out the specific version in this context.
We say "the WWII ended in 1945" instead of "in {{ current year }}, the WWII has ended." with a constant refreshing of the {{ current year }}.
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.
Historical events aren't quite the right analogy. It's about a commutative relationship between (releases of) two things. The containerd docs might want to express the reverse relationship for example.
The text I've proposed for v1.27 also uses a skew shortcode (for a different reason).
I guess if we're sure that v1.7 of containerd is compatible specifically with v1.26 of Kubernetes and no other minor version of this project, we should say exactly that (and keep the “If you are running a different version of Kubernetes, check the documentation for that Kubernetes release.”)
However, this is an unusual case because of when we're making the change, ie after the code freeze for v1.27
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.
@sftim what change is after code freeze? This doc PR?
First, this doc isn't for 1.27. This is for 1.25 and 1.26.
Secondly, that statement is true for 1.25 and 1.26, I don't understand why you insist in mentioning only one release.
And yes, we re-worked the implementation in 1.27 and what we need other requirements from the runtime. That is why it is not recommended to use 1.7 for userns with k8s >= 1.27.
But to return to more practical matter, how do you want me to phrase it here? So we can merge this PR
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.
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.
@sftim that link is not working (github is having hiccups, maybe is due to that). Can you please explain here again? Or a suggestion is even better ;)
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.
Ah, try #40264 (review)
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.
@sftim thanks not sure what you mean, though. Yes, I'll open another PR for 1.25, but what change in the content here do you expect to see? I don't follow, sorry
|
@sftim PTAL, all comments are addressed now. How will this work once this PR and PRs for 1.27 are merged? (#39860 and #40335) I think merging the main branch with the dev-1.27 might have conflicts, what happens in that case? Also, I applied the suggestion to use the k8s skew version template thingy, but I think that will break when this is merged with the 1.25 branch (see the comment I added on that line for more details). What should we do? Can't we just use the hardcoded k8s versions (1.25 and 1.26) as what we really want is those versions and not something relative to the current k8s version? |
|
We have a team that resolve merge conflicts. Consider putting in an HTML comment that explains your intent about the merge conflict that will arise. I don't understand the shortcoming that we have with using |
|
@sftim I'll add an html comment, thanks My concern is that using version skrew does not expend to 1.26 AND 1.25 (which is what is accurate in this context) and can't be backported. If you want to keep it, I'm fine with it... |
|
@sftim added the comment, thanks. PTAL |
content/en/docs/tasks/configure-pod-container/user-namespaces.md
Outdated
Show resolved
Hide resolved
containerd 1.7 was just released with user namespaces support. Let's mention which kubernetes versions should work with container 1.7. While we are there, let's clarify the CRI-O version and not duplicate the requirements in the concept and task pages and just add a link Signed-off-by: Rodrigo Campos <[email protected]>
|
@sftim Fixed, PTAL |
|
/lgtm thank you @sftim for all the feedback. |
|
LGTM label has been added. Git tree hash: 491469ab6dbe3c37912cf396113498ac0a05467d
|
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: reylejano, SergeyKanzhelev 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 |
containerd 1.7 was just released with user namespaces support. Let's mention this.
Also, let's emphasize in the task page that only supported runtimes work with user namespaces.
Fixes: #40233
@sftim doing only one PR against main is enough for this to show for 1.25 and 1.26? Let me know if I should open another PR for the other branch or what
cc @SergeyKanzhelev