*: Add --pid-namespace=[container|pod|pod-container] #1280

wking · 2018-01-22T18:50:57Z

So crio callers can pick their PID namespace approach. This seems like something that folks might want to configure per-pod, or possibly even per-container, but for now follow --enable-shared-pid-namespace and make it per-crio-daemon.

The “Deprecated:” paragraph approach in Go comments is recommended here.

The ${parameter:+word} syntax is in POSIX, and ${REDIS_IN_INFRA:+!} resolves to ! when REDIS_IN_INFRA is set non-empty and resolves to nothing when REDIS_IN_INFRA is unset.

The ADDITIONAL_CRIO_OPTIONS approach is easier to maintain than the old approach with settings for every option, because we no longer need to maintain defaults in two locations (lib/config.go and test/helpers.bash). For this pull request, I've only dropped ENABLE_SHARED_PID_NAMESPACE, but we may want to extend this approach to more variables in the future.

There's some related discussion in #1242.

openshift-ci-robot · 2018-01-22T18:51:13Z

Hi @wking. Thanks for your PR.

I'm waiting for a openshift or kubernetes-incubator member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

I understand the commands that are listed here.

Details

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.

wking · 2018-01-22T23:43:29Z

Can anyone reproduce Travis' gofmt error? Travis complains about lib/config.go checked with Go 1.9.2, but using gofmt from Gentoo's dev-lang/go-1.9.2 locally turns up no issues with that file.

mheon · 2018-01-22T23:45:08Z

@wking You might want to try running gofmt on the directory containing the file - I've seen some strange cases where gofmt on a single file detects no issues, but gofmt on a directory catches them.

wking · 2018-01-22T23:53:46Z

On Mon, Jan 22, 2018 at 11:45:09PM +0000, Matthew Heon wrote: You might want to try running `gofmt` on the directory containing the file…

That didn't work either :/. I've filed #1281 to get more helpful error messages.

mrunalp · 2018-01-23T19:43:18Z

We want to support this through k8s. See kubernetes/community#1048 for details.

wking · 2018-01-23T22:46:25Z

We want to support this through k8s.

It looks like the upstream plan is to leave the container / pod-container distinction up to the CRI implementation. I think that means we can move ahead with this PR, and adapt to use the k8s overrides (like we currently do with hostPID) once kubernetes/community#1048 lands. Or do you see things you'd like changed in preparation for kubernetes/community#1048?

This allows us to launch containers that create new PID namespaces within an existing PID namespace that differs from the host PID namespace. One use-case is launching containers into a pod in per-container PID namespaces that are children of the pod's infra containter PID namespace (similar to the existing --enable-shared-pid-namespace, but where the worker containers cannot see each other or back up into the infra container). Signed-off-by: W. Trevor King <[email protected]>

wking · 2018-01-24T19:09:24Z

Rebased onto master with c3a4241 → fe66d00 to pick up #1281.

wking · 2018-01-24T19:15:26Z

lib/config.go

+	// namespace with the non-infra containers in per-container PID
+	// namespaces that are children of the pod's infra PID namespace .
+	// A 'hostPID' Kubernetes pod specification overrides this setting.
+	PIDNamespace string `toml:"pid_namespace"`  // FIXME: should this be an enum type?


The FIXME comment is what Travis is complaining about, and we don't want to land that comment anyway. Maintainers, would you prefer an enum or a string for this property? I'm fine either way.

We don't want options for all possible pid namespace sharing options at the daemon level.
We only want to be able to distinguish whether we want pod or pod-container when k8s passes us POD as the sharing option:

enum NamespaceMode { POD = 0; CONTAINER = 1; NODE = 2; TARGET = 3; }

The reason we had the option at the daemon level was because pid namespace support wasn't fully baked in k8s and we wanted a control at the daemon level. With the upcoming changes, we can do what k8s requests through the API and choice will be down to what to do when we get POD as the setting.

The reason we had the option at the daemon level was because pid namespace support wasn't fully baked in k8s…

kubernetes/community#1048 should help with this, but I'm not clear on the deployment procedure. Wouldn't we need changes to kubernetes/api to implement
kubernetes/community#1048 before we could rely on them here? And until we have k8s API support for kubernetes/community#1048, I'm not sure how to adjust this. Should we just table this PR until there is k8s API support for kubernetes/community#1048?

And either way, I think maintainers here are going to have to make a call on strings vs. enums for the CRI-O config. The kubernetes/community#1048 support question is just impacting the option name and scope, we'll still need an option that takes string arguments on the command line, and holds that configuration in Go.

kubernetes/community#1048 should help with this, but I'm not clear on the deployment procedure. Wouldn't we need changes to kubernetes/api to implement
kubernetes/community#1048 before we could rely on them here? And until we have k8s API support for kubernetes/community#1048, I'm not sure how to adjust this. Should we just table this PR until there is k8s API support for kubernetes/community#1048?

Yes, we can wait for the implementation of 1048 to land: kubernetes/kubernetes#58716

And either way, I think maintainers here are going to have to make a call on strings vs. enums for the CRI-O config. The kubernetes/community#1048 support question is just impacting the option name and scope, we'll still need an option that takes string arguments on the command line, and holds that configuration in Go.

We can use the approach that we have for ImageVolumes where we have defined a custom type.

So crio callers can pick their PID namespace approach. This seems like something that folks might want to configure per-pod, or possibly even per-container, but for now follow --enable-shared-pid-namespace and make it per-crio-daemon. The "Deprecated:" paragraph approach in Go comments is recommended in [1]. The ${parameter:+word} syntax is in POSIX [2], and ${REDIS_IN_INFRA:+!} resolves to ! when REDIS_IN_INFRA is set non-empty and resolves to nothing when REDIS_IN_INFRA is unset. The ADDITIONAL_CRIO_OPTIONS approach is easier to maintain than the old approach with settings for every option, because we no longer need to maintain defaults in two locations (lib/config.go and test/helpers.bash). For this commit, I've only dropped ENABLE_SHARED_PID_NAMESPACE, but we may want to extend this approach to more variables in the future. PIDNamespaceType follows the ImageVolumes pattern at Mrunal's recommendation [3]. [1]: https://blog.golang.org/godoc-documenting-go-code [2]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02 [3]: cri-o#1280 (comment) Signed-off-by: W. Trevor King <[email protected]>

wking · 2018-01-24T22:33:19Z

I've pushed fe66d00 → 87121d8, switching the Go property from a string to a custom type. Once kubernetes/kubernetes#58716 lands, I'll update to take that into account as well.

So crio callers can pick their PID namespace approach. This seems like something that folks might want to configure per-pod, or possibly even per-container, but for now follow --enable-shared-pid-namespace and make it per-crio-daemon. The "Deprecated:" paragraph approach in Go comments is recommended in [1]. The ${parameter:+word} syntax is in POSIX [2], and ${REDIS_IN_INFRA:+!} resolves to ! when REDIS_IN_INFRA is set non-empty and resolves to nothing when REDIS_IN_INFRA is unset. The ADDITIONAL_CRIO_OPTIONS approach is easier to maintain than the old approach with settings for every option, because we no longer need to maintain defaults in two locations (lib/config.go and test/helpers.bash). For this commit, I've only dropped ENABLE_SHARED_PID_NAMESPACE, but we may want to extend this approach to more variables in the future. PIDNamespaceType follows the ImageVolumes pattern at Mrunal's recommendation [3]. [1]: https://blog.golang.org/godoc-documenting-go-code [2]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02 [3]: cri-o#1280 (comment) Signed-off-by: W. Trevor King <[email protected]>

So crio callers can pick their PID namespace approach. This seems like something that folks might want to configure per-pod, or possibly even per-container, but for now follow --enable-shared-pid-namespace and make it per-crio-daemon. The "Deprecated:" paragraph approach in Go comments is recommended in [1]. The ${parameter:+word} syntax is in POSIX [2], and ${REDIS_IN_INFRA:+${NOT}} resolves to ! when REDIS_IN_INFRA is set non-empty and resolves to nothing when REDIS_IN_INFRA is unset. I'm using :+${NOT} instead of :+!, because the latter is giving me: $ echo "${REDIS_IN_INFRA:+!}" bash: !}: event not found $ echo "${BASH_VERSION}" 4.4.12(1)-release regardless of whether REDIS_IN_INFRA is set. The ADDITIONAL_CRIO_OPTIONS approach is easier to maintain than the old approach with settings for every option, because we no longer need to maintain defaults in two locations (lib/config.go and test/helpers.bash). For this commit, I've only dropped ENABLE_SHARED_PID_NAMESPACE, but we may want to extend this approach to more variables in the future. PIDNamespaceType follows the ImageVolumes pattern at Mrunal's recommendation [3]. [1]: https://blog.golang.org/godoc-documenting-go-code [2]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02 [3]: cri-o#1280 (comment) Signed-off-by: W. Trevor King <[email protected]>

So crio callers can pick their PID namespace approach. This seems like something that folks might want to configure per-pod, or possibly even per-container, but for now follow --enable-shared-pid-namespace and make it per-crio-daemon. The "Deprecated:" paragraph approach in Go comments is recommended in [1]. I tried to find a more compact form for the REDIS_IN_INFRA test, but: * =~ is not in POSIX [2], so we need to use Bash's internal [[. * '[ ! {expression} ]' is in POSIX [2], but Bash's [[ seems to look for ! before doing variable expansion. Because of those, we can't use POSIX's ${parameter:+word} [3]: NOT="!" [[ ${REDIS_IN_INFRA:+${NOT}} "$output" =~ "redis" ]] and the best alternative I can find is the if/else that I've gone with in this commit. The ADDITIONAL_CRIO_OPTIONS approach is easier to maintain than the old approach with settings for every option, because we no longer need to maintain defaults in two locations (lib/config.go and test/helpers.bash). For this commit, I've only dropped ENABLE_SHARED_PID_NAMESPACE, but we may want to extend this approach to more variables in the future. PIDNamespaceType follows the ImageVolumes pattern at Mrunal's recommendation [4]. [1]: https://blog.golang.org/godoc-documenting-go-code [2]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html [3]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02 [4]: cri-o#1280 (comment) Signed-off-by: W. Trevor King <[email protected]>

rhatdan · 2018-02-24T16:04:27Z

@wking needs a rebase.

wking · 2018-02-24T16:13:15Z

Hmm, #1324 may have brought in what I need.

rhatdan · 2018-03-01T13:18:28Z

@wking Should we close this PR since we have the other PR on PIDNamespaces?

wking · 2018-03-01T15:46:34Z

Should we close this PR since we have the other PR on PIDNamespaces?

No, the other doesn't support the pod-container approach. But you can flag this as blocked-on-submitter or some such until I have time to rebase it.

rhatdan · 2018-03-08T13:18:51Z

Needs a rebase.

umohnani8 · 2019-03-13T20:15:10Z

@wking please rebase

rhatdan · 2019-07-21T09:18:28Z

@umohnani8 @haircommander @wking @saschagrunert Working on this? Interns? Close?

saschagrunert · 2019-07-22T06:41:09Z

I still see it as valuable improvement and we should continue with it 😇

rhatdan · 2019-10-13T11:47:59Z

@giuseppe PTAL Could you take this over and get it merged or close it, if it does not apply any longer?
@wking @umohnani8 @saschagrunert @haircommander @mrunalp Is this something we want?
Attempting to cleanup old CRI-O PRs

giuseppe · 2019-10-14T08:18:38Z

@giuseppe PTAL Could you take this over and get it merged or close it, if it does not apply any longer?

it is an interesting feature but the rebase is not a trivial task. What is the best way to not lose track of it? Opening an issue?

rhatdan · 2020-03-07T13:57:58Z

@giuseppe @mrunalp @haircommander @saschagrunert @kolyshkin @umohnani8 What should we do with this one?

openshift-ci-robot · 2020-03-07T13:58:05Z

@wking: PR needs rebase.

Details

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.

openshift-ci-robot · 2020-03-07T13:58:05Z

@wking: PR needs rebase.

Details

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.

dougsland · 2020-04-17T01:00:15Z

@mrunalp @rhatdan @haircommander could you please close this PR? (Based on comment from: #3601 (comment)

Thanks!

wking requested review from mrunalp and runcom as code owners January 22, 2018 18:50

k8s-ci-robot added cncf-cla: yes size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Jan 22, 2018

openshift-ci-robot added the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label Jan 22, 2018

wking mentioned this pull request Jan 23, 2018

Update Docker Shared PID proposal for per-pod configuration kubernetes/community#1048

Merged

wking force-pushed the pid-namespace branch from c3a4241 to fe66d00 Compare January 24, 2018 19:08

wking commented Jan 24, 2018

View reviewed changes

wking force-pushed the pid-namespace branch from fe66d00 to 87121d8 Compare January 24, 2018 22:30

wking force-pushed the pid-namespace branch from 87121d8 to 6d99645 Compare January 24, 2018 23:16

wking force-pushed the pid-namespace branch from 6d99645 to c179120 Compare January 25, 2018 00:45

wking force-pushed the pid-namespace branch from c179120 to 21a8591 Compare January 25, 2018 20:14

wking mentioned this pull request Feb 28, 2018

Enable per pod PID namespace setting #1392

Merged

wking mentioned this pull request May 18, 2018

Make capabilities an option in crio.conf #1546

Merged

cblecker removed the cncf-cla: yes label Apr 11, 2019

openshift-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Mar 7, 2020

dougsland mentioned this pull request Apr 16, 2020

[WIP-Rebase] *: Add --pid-namespace=[container|pod|pod-container] #3601

Closed

mrunalp closed this Apr 17, 2020

*: Add --pid-namespace=[container|pod|pod-container] #1280

*: Add --pid-namespace=[container|pod|pod-container] #1280

Uh oh!

Conversation

wking commented Jan 22, 2018

Uh oh!

openshift-ci-robot commented Jan 22, 2018

Uh oh!

wking commented Jan 22, 2018

Uh oh!

mheon commented Jan 22, 2018

Uh oh!

wking commented Jan 22, 2018 via email

Uh oh!

mrunalp commented Jan 23, 2018

Uh oh!

wking commented Jan 23, 2018

Uh oh!

wking commented Jan 24, 2018

Uh oh!

wking Jan 24, 2018

Choose a reason for hiding this comment

Uh oh!

mrunalp Jan 24, 2018

Choose a reason for hiding this comment

Uh oh!

mrunalp Jan 24, 2018

Choose a reason for hiding this comment

Uh oh!

wking Jan 24, 2018

Choose a reason for hiding this comment

Uh oh!

mrunalp Jan 24, 2018

Choose a reason for hiding this comment

Uh oh!

wking commented Jan 24, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rhatdan commented Feb 24, 2018

Uh oh!

wking commented Feb 24, 2018

Uh oh!

rhatdan commented Mar 1, 2018

Uh oh!

wking commented Mar 1, 2018

Uh oh!

rhatdan commented Mar 8, 2018

Uh oh!

umohnani8 commented Mar 13, 2019

Uh oh!

rhatdan commented Jul 21, 2019

Uh oh!

saschagrunert commented Jul 22, 2019

Uh oh!

rhatdan commented Oct 13, 2019

Uh oh!

giuseppe commented Oct 14, 2019

Uh oh!

rhatdan commented Mar 7, 2020

Uh oh!

openshift-ci-robot commented Mar 7, 2020

Uh oh!

openshift-ci-robot commented Mar 7, 2020

Uh oh!

dougsland commented Apr 17, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

11 participants

wking commented Jan 24, 2018 •

edited

Loading