> On Apr 28, 2015, at 1:25 PM, Daniel J Walsh <[email protected]> wrote: > > > >> On 04/28/2015 11:05 AM, Jeremy Eder wrote: >> I haven't tested this, but it came to mind when reading about >> --cgroup-parent. >> >> Think we can use --cgroup-parent to create resource jails around daemon ops >> like build/load/import/save ? >> >> I worry about fairness (especially disk I/O) when daemon tasks like the >> above are co-located with "prodcution" apps. >> >> That is, until/unless we have support for dedicated image builder machines, >> or support for multiple docker backend graph directories. Clayton? > If these happen at the client, then the they would be controlled by the > cgroup that the client is running under. >
Right now we were going to pass the invoking container's (container starting the build) cgroup to build. It would only be build for our case, so push is still not gated by cgroup, nor is the layer creation cost (until docker distribution stuff allows push/build from a separate binary). Our container will invoke the parent cgroup via the go docker client for build. Long term I'd like to box the invocation a bit better. Agree disk is still a concern right now. Although if we could run docker containers daemonless we could do the build from a root container and cgroup everything, since we don't really need the daemon to create an image usable on the same box we run the build on.
