Generic /cmd endpoint and dm specific operations (resize/resize-pool/trim-pool) #4202
Conversation
| args = append(args, strings.Split(argsString, " ")...) | ||
| } | ||
|
|
||
| job := eng.Job("driver", args...) |
There was a problem hiding this comment.
I would prefer this way:
job := eng.Job("driver", vars["operation"], strings.Split(r.Form.Get("args"), " ")...)
if you don't mind, I think it's easier to read
There was a problem hiding this comment.
@vieux I had it like that at first, but it doesn't handle the case where there are zero args well. It splits "" into [""].
|
@alexlarsson , the operation is called |
| @@ -202,8 +202,8 @@ func FindLoopDeviceFor(file *osFile) *osFile { | |||
| if err != nil { | |||
| return nil | |||
| } | |||
| targetInode := stat.Sys().(*sysStatT).Ino | |||
| targetDevice := stat.Sys().(*sysStatT).Dev | |||
| targetInode := stat.Sys().(*syscall.Stat_t).Ino | |||
There was a problem hiding this comment.
Is this retated to the resize or it fixes another bug ?
There was a problem hiding this comment.
Well, its used in the codepath for the resize, and its broken.
stat is returned from osFile.Stat() which calls *os.File.Stat(), which returns a syscall.Stat_t, not a sysStatT, so the casts broke.
|
New series moves "driver" to the right order in the usage output. @vieux "grow" maybe? Not super great either. |
|
This last rebase also adds the "trim-pool" command that allows you to regain space on the host filesystem in case you have an older kernel as per #3182 (comment) |
|
|
|
@vieux what is your kernel version ? I have 3.12 |
|
3.11.0-15-generic On Thu, Feb 20, 2014 at 11:08 AM, Michael Crosby
Victor VIEUX |
|
@vieux Are you sure it hangs? It can take quite some time. |
|
No I don't have |
|
trim-pool doesn't really use any paricular kernel features. |
|
@vieux Ah, i guess we should check that :) |
|
@vieux I tried with thin_dump not installed and got: Do you not get something like that? |
|
Yes I retried and I get But I'm certain that the first time it freezed. could you pleas try @crosbymichael |
|
@alexlarsson Do you think it'd be a good idea to allow users to customize the size of the default base fs? |
|
@unclejack That seems like a nice idea. It'd have to be set the first time the daemon runs though. |
|
So, what is the opinion on this? |
|
@alexlarsson This is useful and it's going to be needed sooner or later. Being able to set the initial base fs size would be useful as well. Couldn't it be changed, provided that there are no containers and no images? I'll test this PR on Fedora as soon as possible. |
|
@unclejack Well, the base image can be re-created at any time i guess. The only problem is that existing images and containers will not pick that up. That may not be a problem though, |
|
Rebased on latest master |
|
rebased to latest master |
|
I've tested this latest rebase on RHEL6.5 and verified "device trim-pool" operates correctly/as-advertised. As there is no other way offered presently to trim the devicemapper data file, I'd appreciate upstream's consideration in merging this. For my own purposes I've backported to 0.9.1: https://github.com/lcarstensen/docker/tree/dm-operations-v0.9.1 |
|
@shykes @crosbymichael I've heard this may be waiting on an introduction of plugins to api/client/* - may I request that you confirm that and cross reference a branch / issue / label / milestone / somesuch here? FWIW I've been using this PR for several weeks now in a moderate environment - just tracking the merge so I don't have to keep carrying the patch on each release for that environment. |
|
Maybe we can merge the code into the devicemapper package first. I'm not sure about the top level command and if the code was available to sys admins then we could have a small contrib tool. |
|
@alexlarsson I'm +1 on the feature, but this will be the first implementation of driver-specific operations, so I want to set the right precedent. What do you think of this syntax (inspired by the heroku and dokku command-line) Implementation changes: Instead of a new /driver route in the remote API, this could be sent on a more generic /cmd route, which would simply execute a job. The /cmd route wouldn't be specific to driver operations: we can use it as a catch-all for all commands which are not known to map to another route. The nice thing about this is that we can gradually move more and more commands to this /cmd route, basically making it a generic http1 beam transport. On the server side, we just need to make sure that there is a job handler registered on the engine for "devicemapper:resize" and "devicemapper:resize-pool". This can be done in builtins/builtins.go, with any sort of "plugin-y" scaffolding that we want. In fact we could use this as a simple scaffolding for plugins. |
|
I rebased this series to latest. I'll keep this pull open for now to keep the code, then i'll make a separate pull request with only the /cmd part. Then when that is in i can rebase the devicemapper specific ops. |
|
New rebased set. Note, this includes the changes from #5380, so that should probably be pulled first. |
|
rebased on latest master, still containes the changes from #5380, so that should probably be pulled first. |
This allows registering handlers after you've started using the engine, as well as setting hack envs. Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
If you do docker devmapper:resize -o Key=Value -o Foo=Bar plugin:op arg1 arg2 This will do a GET http request to /cmd/devmapper/resize with the arguments and options as keys. This will then try to spawn a job on the engine called "devmapper:resize" with the arg1, arg2, etc as arguments and the -o options as environment. Also, any graph driver implementing the engine.Installer interface will get installed on the engine when the daemon is created. This will be used by e.g. the devicemapper to allow driver-specific operations like pool resizing. Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
This lets you live-resize the devicemapper loopback files for the pool. Use it like this: docker dm:resize-pool 140G Also, it changes the way pool sizes are reported to use the units.HumanSize call which uses base 1000, not 1024, to match the FromHumanSize call. Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
This lets you resize individual images or containers like: docker dm:resize f4eff8c9f36d3114c3a16fc7b213512153a2d25caef6f11f385020e6558600f1 12G Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
This adds a BlockDeviceDiscardAll which discards everything on the device, and makes BlockDeviceDiscard take offset and length arguments. Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
This command suspends the pool, extracts all metadata from the metadata pool and then manually discards all regions not in use on the data device. This will re-sparsify the underlying loopback file and regain space on the host operating system. This is required in some cases because the discards we do when deleting images and containers isn't enought to fully free all space unless you have a very new kernel. See: moby#3182 (comment) Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson) Conflicts: daemon/graphdriver/devmapper/driver.go
alexlarsson
changed the title
|
What is the current state of this pull request? |
|
@vieux @crosbymichael are we still good on this one? |
|
I would say that we can close this for now because it's not the direction being taken with the API. |
|
@crosbymichael This api is what @shykes proposed at #4202 (comment), if some other API is a better approach can you document that so we can fix this, because the feature is quite useful. |
|
We think the design and implementation from the earlier discussion do not apply today. I'm sure this is currently handled by an external tool and should probably be based on new API discussions. |
Largely bringing in the Trim and resize logic by @alexlarsson and moby#4202 Signed-off-by: Vincent Batts <vbatts@redhat.com>
|
None of the commands are working and is known by the docker daemon. Please can someone suggest the method to use it? I need to increase the size of my containers to 50 GB. |
|
@rhvgoyal ^^ |
This series adds a generic /cmd endpoint and cli support for it, so that drivers and other form of plugins can add arbitrary new operations, which are accessible as "docker : args..." .
Additionally it adds devicemapper specific operations
dm:resize-pool,dm:resizeanddm:trim-pool. These allow resizeing the devicemapper pool, indivdual devicemapper devices (like images and containers) and finally allows you to return unused space in the pool to the host root filesystem (when using loopback).The last one is interesting because it lets you get space back if the discard trick we're using on delete doesn't work (older kernel) or is disabled (because its very slow).