Uh oh!
There was an error while loading. Please reload this page.
runtime-config-linux: Add a way to disable runtime cgroup manipulation - #237
runtime-config-linux: Add a way to disable runtime cgroup manipulation#237wking wants to merge 1 commit into
Conversation
So folks can use a different model, if the current linux.resources approach isn't scratching their itch. Signed-off-by: W. Trevor King <wking@tremily.us>
crosbymichael
commented
Oct 29, 2015
NOTLGTM We are not even done discussion things and you are already opening PRs to change functionality of runtimes implementing the spec |
wking
commented
Oct 29, 2015
On Thu, Oct 29, 2015 at 11:41:25AM -0700, Michael Crosby wrote:
I hadn't heard any pushback on “we need a way to disable the runtime's |
vbatts
commented
Oct 29, 2015
@wking please don't just throw up PRs when the discussion is not close to a census. |
wking
commented
Oct 29, 2015
This should help clarify the cgroupsPath setting added in opencontainers#137, which was the subject of some confusion in opencontainers/runc#397. Issues I'm trying to clarify here: * If you specify a cgroupsPath, is the container added to that path or a sub-cgroup underneath it [1]? (This commit rules in favor of "added to that path") * If you specify a cgroupsPath, can the runtime modify that cgroup [2]? (This commit rules "yes, if 'resources' is specified", following [3] and the Go comment from opencontainers#137 [4]). To help make the distinctions clearer, I've added a facet list to help folks think about the difference between cgroup creation, process assignment, and resource configuration. cgroupsPath is just about cgroup creation and process assignment. 'resources' is just about resource configuration. I've listed out Mrunal's first three cases [3] to be even clearer. I stayed away from the "neither are set" case, since I covered that fairly directly in opencontainers#237, which that was punted back to the list [5] and has seen no further interest. So I'm not clear on what the intended semantics are there, although Mrunal's wording in [4] seems to agree with the proposal in opencontainers#237. [1]: opencontainers/runc#397 (comment) [2]: opencontainers/runc#397 (comment) [3]: opencontainers/runc#397 (comment) [4]: opencontainers@429f936#diff-34c30be66233f08b447fb608ea0e66bbR30 [5]: https://groups.google.com/a/opencontainers.org/d/msg/dev/qWHoKs8Fsrk/c9mv6qXtDAAJ Message-ID: <20151029194427.GA30073@odin.tremily.us> Signed-off-by: W. Trevor King <wking@tremily.us>
This should help clarify the cgroupsPath setting added in opencontainers#137, which was the subject of some confusion in opencontainers/runc#397. Issues I'm trying to clarify here: * If you specify a cgroupsPath, is the container added to that path or a sub-cgroup underneath it [1]? (This commit rules in favor of "added to that path") * If you specify a cgroupsPath, can the runtime modify that cgroup [2]? (This commit rules "yes, if 'resources' is specified", following [3] and the Go comment from opencontainers#137 [4]). To help make the distinctions clearer, I've added a facet list to help folks think about the difference between cgroup creation, process assignment, and resource configuration. cgroupsPath is just about cgroup creation and process assignment. 'resources' is just about resource configuration. I've listed out Mrunal's first three cases [3] to be even clearer. I stayed away from the "neither are set" case, since I covered that fairly directly in opencontainers#237, which that was punted back to the list [5] and has seen no further interest. So I'm not clear on what the intended semantics are there, although Mrunal's wording in [4] seems to agree with the proposal in opencontainers#237. [1]: opencontainers/runc#397 (comment) [2]: opencontainers/runc#397 (comment) [3]: opencontainers/runc#397 (comment) [4]: opencontainers@429f936#diff-34c30be66233f08b447fb608ea0e66bbR30 [5]: https://groups.google.com/a/opencontainers.org/d/msg/dev/qWHoKs8Fsrk/c9mv6qXtDAAJ Message-ID: <20151029194427.GA30073@odin.tremily.us> Signed-off-by: W. Trevor King <wking@tremily.us>
This should help clarify the cgroupsPath setting added in opencontainers#137, which was the subject of some confusion in opencontainers/runc#397. Issues I'm trying to clarify here: * If you specify a cgroupsPath, is the container added to that path or a sub-cgroup underneath it [1]? (This commit rules in favor of "added to that path") * If you specify a cgroupsPath, can the runtime modify that cgroup [2]? (This commit rules "yes, if 'resources' is specified", following [3] and the Go comment from opencontainers#137 [4]). To help make the distinctions clearer, I've added a facet list to help folks think about the difference between cgroup creation, process assignment, and resource configuration. cgroupsPath is just about cgroup creation and process assignment. 'resources' is just about resource configuration. I've listed out Mrunal's first three cases [3] to be even clearer. I stayed away from the "neither are set" case, since I covered that fairly directly in opencontainers#237, which that was punted back to the list [5] and has seen no further interest. So I'm not clear on what the intended semantics are there, although Mrunal's wording in [4] seems to agree with the proposal in opencontainers#237. [1]: opencontainers/runc#397 (comment) [2]: opencontainers/runc#397 (comment) [3]: opencontainers/runc#397 (comment) [4]: opencontainers@429f936#diff-34c30be66233f08b447fb608ea0e66bbR30 [5]: https://groups.google.com/a/opencontainers.org/d/msg/dev/qWHoKs8Fsrk/c9mv6qXtDAAJ Message-ID: <20151029194427.GA30073@odin.tremily.us> Signed-off-by: W. Trevor King <wking@tremily.us>
This allows folks to develop other cgroup managers outside of the runtimes, which is a prerequisite for cgroup removal [1]. I feel like there's a consensus on this issue, so I filed a pull-request [2], but it was punted back to the list [3]. [1]: Message-ID: <CAD2oYtO1RMCcUp52w-xXemzDTs+J6t4hS5Mm4mX+uBnVONGDfA@mail.gmail.com> Subject: removal of cgroups from the OCI Linux spec [2]: opencontainers/runtime-spec#237 [3]: opencontainers/runtime-spec#237 (comment)
So folks can use a different model, if the current linux.resources
approach isn't scratching their itch.
For more motivation, see the discussion here.