Note that this PR need docker-archive/libcontainer#441 to me merged, so right now we might get compile error on Docker, please ignore that and review the code and docs first.

Please squash your commits

@duglin I took Michael's PR(https://github.com/docker/docker/pull/9984/commits) as example, daemon side, client side, docs, etc. Thought that's more clearer. Anyway, I squash the first three patches into one, I think the last one should be separated. Hope that's what you want.

ping, I don't know why Jenkins failed on set command, this is passed in my box.

ping @jfrazelle can you help take a look at Jenkins? Failed at runCommand seems quite strange.

daemon/execdriver/native/driver.go:349: too many arguments in call to cont.Set

@cpuguy83 this is not the error for now, docker-archive/libcontainer#441 has been merged so arguments should be right. From currently Jenkins output, I don't know why it failed :(

This needs a rebase now.

Rebased.

design LGTM

One question... I noticed that once you create a container with (or w/o) --privileged you can't change it. Should we allow for that to change too? Can it?

@duglin I think even we want to do that, it can only be one way trip, once you drop a capability, you can never add it back before the system is rebooted, that's restriction from kernel.

+1. Thanks for working on this feature @hqhq!

I don't have any objections for this feature, but it needs broad approval.

Ping @jfrazelle @crosbymichael @estesp @LK4D4 @icecrime @unclejack wdyt?

@icecrime I don't get it.

• The use case is definitely general, change container configs after it is created is no doubt useful, especially resource configs, I saw many people seek for this feature.
• Sorry but I don't see any chance how our needs can be met with current features, for example with parent cgroup, can you be more specific?
• This can be discussed more, but one thing for sure it wouldn't be limit to work on running containers only, just for the first step, this is easy to archive, we can surely expand that. And regarding which configs we can set, I don't think that'll be the problem, a simple --help would give users enough information which configs they can set. If someone wants to expand, let's just discuss if that's worth to do.

I don't know how you discussed this but I only see approval for the design in this thread from maintainers, and the reasons you give are really not strong enough. Hope you can reconsider it or give more reason why this feature should not be provided by Docker.

Thanks.

Yes, I can see the usefulness of at the very least being able to tweak resource usages.
I thought this was something that @crosbymichael had specifically worked on getting into libcontainer so we could expose it in Docker... but I could be wrong.

Only thing I'm not happy about is that we have a rename endpoint and now this, but I digress.

I think what we are trying to avoid is the rabbit hole where then people
want everything to be supported by set, kinda like what happened with exec.
Today you can create cgroup-parents and easily change the resource
constraints.

Since this is really basic functionality we don't see why it can't be done
w a small tool that just changes the values of the resource files. That way
we don't have to go down the path where we have a new top level command and
have to support new features for everything it could do

On Friday, May 1, 2015, Brian Goff [email protected] wrote:

Yes, I can see the usefulness of at the very least being able to tweak
resource usages.
I thought this was something that @crosbymichael
https://github.com/crosbymichael had specifically worked on getting
into libcontainer so we could expose it in Docker... but I could be wrong.

Only thing I'm not happy about is that we have a rename endpoint and now
this, but I digress.

—
Reply to this email directly or view it on GitHub
#11442 (comment).

What if this was API only? Maybe a post to /containers//resources?

I'm not a fan of doing stuff like "API only" things. I would interpret it as "we're going to support something but make it hard for you to get to it" (yea I know the API isn't hard, but its harder than the CLI). If we're going to support something I think we should fully support it and make it a first-class feature and easy to use.

I think we should step back and not get bogged down in some of the technical side-issues. I think its important to first discuss, and decide, whether we want to support modifying an existing container's resource config properties via Docker?

IMO, if these configuration knobs are available in the underlying infrastructure then its hard for me to see why we wouldn't offer them to our users.

we can comment on this until the cows come home but my current belief is this is "feature creep" but that can be disproven in the future just like -f ;)

--cgroup-parent should solve the update issue for cgroup based resources. The other option is to expose cgroup paths via inspect.
Updating resources (and volumes maybe) is a feature that is very useful for managing clusters.
One way to look at this would be to classify updates as power user features, and expect such power users to run additional software to handle updates.
Is it fair to summarize that docker is not transforming into a system daemon for cluster management in the near future?

my beloved -f :-)

@jfrazelle One reason I use a more common command set is because someone tried a specific name #3604 and was told that we should not expose such low-level thing like cgroups to users, no mention to let users deal with cgroupfs directly. So I don't think --cgroup-parent can be a common solution.

Also, the design purpose including change other configs beside resources. I agree that people always have all kinds of needs for a common command, like we are keep adding options for docker run, that's something we should adjudge and maintain, if we can control docker run, we can control docker set in the same way. Even without set, if people want some feature, I won't be surprise if they propose other top command like docker rename to do one simple thing because they really have no other options.

Anyway, comments can be forever, I agree with @duglin , let's get to the same page about whether we want to support modifying an existing container's properties via Docker (not only resource configs).

Is it fair to say that #6323 should be closed if we are not going to support this?

IMO since docker is the one setting up the cgroups why shouldn't it be the API we call to adjust them?
Nobody really used cgroups before docker (at least not the great masses that are today because of Docker) because who wants to have to do this?
Docker is the cgroup abstraction (among other things) I want to interact with.

+1 to @cpuguy83 Docker is there to make people's lives easier so they don't need to get under the covers for everything the need to do. If the functionality is there in the underlying infrastructure its odd to me that we would want to hide it, unless exposing it breaks things or hacks things up.

@icecrime As we discussed in DockerCon, can we reopen this? Should we discussed how our approach should be or should I rebase first?
@crosbymichael Any comments on this PR?

Anyway I'll rebase it first, one change is that I would like to remove the restriction about running container, configs of any existed container should be changeable, maybe not paused container.
And I'll address all @duglin 's comments, thanks for these detailed review.

@icecrime @crosbymichael @duglin I have updated PR, can you please take a look.

I did forced update, but the code didn't change, is it because it's closed?

@hqhq yes I believe github won't update it once the issue is closed.

@hqhq
Thanks for working on this. We definitely have a usecase for this. Immediate usecases I can think of is:

1. Suppose we start a database container with swappiness value x
   if we observe that over a period of time we are seeing lot of major
   faults reduce memory swappiness.
2. Container is cpu intensive and performance is low because of less
   cpu-share given during container start.

one unimportant thing: when I thought about this feature myself before looking at this thread,
I had something like below in mind.
docker modify-config =value

But I think docker set is more better and crispy.

@icecrime @jfrazelle - Am trying to understand your suggestion of using --cgroup-parent to possbily change resource configs of a running container. Could you please provide an example to describe how this could be done ?

The only way I can see to actually change the config. of a container that is already started is to directly write to the cgroup filesystem on the docker host.

Thanks!

@selvik: You will have to run a container with a --cgroup-parent path to be able to update resources. If the container is already running, that option won't work for you.

@vishh Thanks a lot for the clarification. So this means that the proposed "docker set" command allows one to change resource configs of a running container but --cgroup parent cannot be used to do this.
The comments above seemed to indicate that docker set wasn't necessary because --cgroup-parent flag could help with the same..hence my confusion. Thanks!

is the proposed SET command available then for a running contianer?
I got lost trying to follow all the various links and variation of requests...
I think it's important for all management frameworks like Mesos, Kubernetes etc.
thank you

@zrml see #15078 (comment)

the latest link is #15078