This leaves out the internal conversions as we may need to consider
docker backward compatibility for those changes.
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
Add support for the pids cgroup controller to libcontainer, a recent
feature that is available in Linux 4.3+.
Unfortunately, due to the init process being written in Go, it can spawn
an an unknown number of threads due to blocked syscalls. This results in
the init process being unable to run properly, and thus small pids.max
configs won't work properly.
Signed-off-by: Aleksa Sarai <asarai@suse.com>
Add support for the pids cgroup controller to libcontainer, a recent
feature that is available in Linux 4.3+.
Unfortunately, due to the init process being written in Go, it can spawn
an an unknown number of threads due to blocked syscalls. This results in
the init process being unable to run properly, and thus small pids.max
configs won't work properly.
Signed-off-by: Aleksa Sarai <asarai@suse.com>
This allows us to distinguish cases where a container
needs to just join the paths or also additionally
set cgroups settings. This will help in implementing
cgroupsPath support in the spec.
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
Godeps: Vendor opencontainers/specs 96bcd043aa
Fix a bug where it's impossible to pass multiple devices to blkio
cgroup controller files. See https://github.com/opencontainers/runc/issues/274
Signed-off-by: Antonio Murdaca <runcom@linux.com>
spec introduced a new field rootfsPropagation. Right now that field
is not parsed by runc and it does not take effect. Starting parsing
it and for now allow only limited propagation flags. More can be
opened as new use cases show up.
We are apply propagation flags on / and not rootfs. So ideally
we should introduce another field in spec say rootPropagation. For
now I am parsing rootfsPropagation. Once we agree on design, we
can discuss if we need another field in spec or not.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Right now config.Privatefs is a boolean which determines if / is applied
with propagation flag syscall.MS_PRIVATE | syscall.MS_REC or not.
Soon we want to represent other propagation states like private, [r]slave,
and [r]shared. So either we can introduce more boolean variable or keep
track of propagation flags in an integer variable. Keeping an integer
variable is more versatile and can allow various kind of propagation flags
to be specified. So replace Privatefs with RootPropagation which is an
integer.
Note, this will require changes in docker. Instead of setting Privatefs
to true, they will need to set.
config.RootPropagation = syscall.MS_PRIVATE | syscall.MS_REC
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Right now if one passes a mount propagation flag in spec file, it
does not take effect. For example, try following in spec json file.
{
"type": "bind",
"source": "/root/mnt-source",
"destination": "/root/mnt-dest",
"options": "rbind,shared"
}
One would expect that /root/mnt-dest will be shared inside the container
but that's not the case.
#findmnt -o TARGET,PROPAGATION
`-/root/mnt-dest private
Reason being that propagation flags can't be passed in along with other
regular flags. They need to be passed in a separate call to mount syscall.
That too, one propagation flag at a time. (from mount man page).
Hence, store propagation flags separately in a slice and apply these
in that order after the mount call wherever appropriate. This allows
user to control the propagation property of mount point inside
the container.
Storing them separately also solves another problem where recursive flag
(syscall.MS_REC) can get mixed up. For example, options "rbind,private"
and "bind,rprivate" will be same and there will be no way to differentiate
between these if all the flags are stored in a single integer.
This patch would allow one to pass propagation flags "[r]shared,[r]slave,
[r]private,[r]unbindable" in spec file as per mount property.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
I deleted possibility to specify config file from commands for now.
Until we decide how it'll be done. Also I changed runc spec interface to
write config files instead of output them.
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Without this, multiple runc containers can accidentally share the same cgroup(s)
(and change each other's limits), when runc is invoked from the same directory
(i.e.: same cwd on multiple runc executions).
After these changes, each runc container will run on its own cgroup(s). Before,
the only workaround was to invoke runc from an unique (temporary?) cwd for each
container.
Common cgroup configuration (and hierarchical limits) can be set by having
multiple runc containers share the same cgroup parent, which is the cgroup of
the process executing runc.
Signed-off-by: Fabio Kung <fabio.kung@gmail.com>
Only add the localhost interface information to the config if the NEWNET
flag is passed on the namespaces.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
And allow cgroup mount take flags from user configs.
As we show ro in the recommendation, so hard-coded
read-only flag should be removed.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
- Initialize swappiness to -1 for the default config.json
- Pass swappiness from config.json to libcontainer config
Signed-off-by: Zefan Li <lizefan@huawei.com>
This fixes a bug where IDMapping.From was mapped to IDMap.ContainerID
and IDMapping.To was mapped to IDMap.HostID, while the old spec docs
were:
// From is the uid/gid of the host user or group.
From int32 `json:"from"`
// To is the uid/gid of the container's user or group.
To int32 `json:"to"`
The new IDMapping field names make the expected mapping more obvious
(HostID -> HostID and ContainerID -> ContainerID ;).
Kenfe-Mickael Laventure
Michael Crosby
Mike Brown
Mrunal Patel
Aleksa Sarai
Mrunal Patel
Alexander Morozov
yangshukui
Antonio Murdaca
Vivek Goyal
Lai Jiangshan
Alexander Morozov
Matthew Heon
Rajasekaran
Tonis Tiigi
Fabio Kung
Qiang Huang
Zefan Li
W. Trevor King