The `/info` endpoint was badly documented, missing various
fields and incorrectly describing others.
This patch defines a type for the endpoint, based on the
API types in the source.
Also removing the response example in favor of
per-field examples, as this prevents an incorrectly
formatted response from masking omissions in the
actual type.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 18b23067be82054a6384fc5934ecbb0276d1862b
Component: engine
All example values are now documented per field,
so are automatically used to generate responses.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 2720cefbb2eaac9f440cd7c1807b4222b18ee0c4
Component: engine
The `Node.ManagerStatus` property was only present in
the example, but not in the definition.
This patch adds definitions for `ManagerStatus`
and `Reachability`, similar to what is used in the
code;
f02a5b50c4/api/types/swarm/node.go (L84-L101)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 3f1ad79faf3bfecc19722eb6541bb415024dafe4
Component: engine
- `TLSInfo` is part of `Node.Description`, but was documented as a
direct child of `Node`
- `Node.TLSInfo` incorrectly was using the `SwarmSpec` type,
instead of `TLSInfo`
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: b2de157a41bbd18ca4317792614e8630d73a7102
Component: engine
- `ObjectVersion.Index` is an `uint64` 0fd90c4d5d/api/types/swarm/common.go (L5-L15)
- `ClusterInfo` is nullable in the `/info` output (see ff4f700f74/api/types/swarm/swarm.go (L203))
- `CAConfig.ForceRotate` was missing a type, therefore treated as an `object` in Swagger: ff4f700f74/api/types/swarm/swarm.go (L121)
- `Raft.SnapshotInterval`, `Raft.KeepOldSnapshots`, and `Raft.LogEntriesForSlowFollowers` are an `uint64` not an `int64`
- Various fields in `swarm.Info` are nullable; added `x-nullable`
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 93e324e2a7b8131414382b6fb38b69f0d09bc30c
Component: engine
This patch updates the definition of `NetworkConfig` to match the code, and
renames to the definition to `NetworkSettings` (also to match the type in
the code).
Add definitions for:
- `Address`
- `PortMap`
- `PortBinding`
- `EndpointIPAMConfig`
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: b98ceb7121c5513c73d69081737ad824384c5391
Component: engine
I was able to successfully use device mapper autoconfig feature
(commit 5ef07d79c) but it stopped working after a reboot.
Investigation shown that the dm device was not activated because of
a missing binary, that is not used during initial setup, but every
following time. Here's an error shown when trying to manually activate
the device:
> kir@kd:~/go/src/github.com/docker/docker$ sudo lvchange -a y /dev/docker/thinpool
> /usr/sbin/thin_check: execvp failed: No such file or directory
> Check of pool docker/thinpool failed (status:2). Manual repair required!
Surely, there is no solution to this other than to have a package that
provides the thin_check binary installed beforehand. Due to the fact
the issue revealed itself way later than DM setup was performed, it was
somewhat harder to investigate.
With this in mind, let's check for binary presense before setting up DM,
refusing to proceed if the binary is not there, saving a user from later
frustration.
While at it, eliminate repeated binary checking code. The downside is
that the binary lookup is happening more than once now -- I think the
clarity of code overweights this minor de-optimization.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: 58a453f3f06c1daf34544da8aa16bb95e8e18010
Component: engine
These test cases cover various arguments for docker create/run --ipc
option, as well as daemon's --default-ipc-mode cli option and
configuration file parameter.
For the description of container IPC modes, see previous commit.
To run these:
TESTFLAGS='-check.f IpcMode' make test-integration-cli
[v2: simplify TestDaemonEvents(), add default-ipc-mode presense check]
[v3: add TestDaemonIpcModeVSRestart]
[v4: ipcmode test now uses client lib instead of CLI (except for exec)]
[v5: nitpicks in comments]
[v6: add test case for "none"; fix a typo; simplify TestDaemonEvents() more]
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: 9a60e1cc874402d10eb7e45f62cce25bf5c41d30
Component: engine
Since the commit d88fe447df0e8 ("Add support for sharing /dev/shm/ and
/dev/mqueue between containers") container's /dev/shm is mounted on the
host first, then bind-mounted inside the container. This is done that
way in order to be able to share this container's IPC namespace
(and the /dev/shm mount point) with another container.
Unfortunately, this functionality breaks container checkpoint/restore
(even if IPC is not shared). Since /dev/shm is an external mount, its
contents is not saved by `criu checkpoint`, and so upon restore any
application that tries to access data under /dev/shm is severily
disappointed (which usually results in a fatal crash).
This commit solves the issue by introducing new IPC modes for containers
(in addition to 'host' and 'container:ID'). The new modes are:
- 'shareable': enables sharing this container's IPC with others
(this used to be the implicit default);
- 'private': disables sharing this container's IPC.
In 'private' mode, container's /dev/shm is truly mounted inside the
container, without any bind-mounting from the host, which solves the
issue.
While at it, let's also implement 'none' mode. The motivation, as
eloquently put by Justin Cormack, is:
> I wondered a while back about having a none shm mode, as currently it is
> not possible to have a totally unwriteable container as there is always
> a /dev/shm writeable mount. It is a bit of a niche case (and clearly
> should never be allowed to be daemon default) but it would be trivial to
> add now so maybe we should...
...so here's yet yet another mode:
- 'none': no /dev/shm mount inside the container (though it still
has its own private IPC namespace).
Now, to ultimately solve the abovementioned checkpoint/restore issue, we'd
need to make 'private' the default mode, but unfortunately it breaks the
backward compatibility. So, let's make the default container IPC mode
per-daemon configurable (with the built-in default set to 'shareable'
for now). The default can be changed either via a daemon CLI option
(--default-shm-mode) or a daemon.json configuration file parameter
of the same name.
Note one can only set either 'shareable' or 'private' IPC modes as a
daemon default (i.e. in this context 'host', 'container', or 'none'
do not make much sense).
Some other changes this patch introduces are:
1. A mount for /dev/shm is added to default OCI Linux spec.
2. IpcMode.Valid() is simplified to remove duplicated code that parsed
'container:ID' form. Note the old version used to check that ID does
not contain a semicolon -- this is no longer the case (tests are
modified accordingly). The motivation is we should either do a
proper check for container ID validity, or don't check it at all
(since it is checked in other places anyway). I chose the latter.
3. IpcMode.Container() is modified to not return container ID if the
mode value does not start with "container:", unifying the check to
be the same as in IpcMode.IsContainer().
3. IPC mode unit tests (runconfig/hostconfig_test.go) are modified
to add checks for newly added values.
[v2: addressed review at https://github.com/moby/moby/pull/34087#pullrequestreview-51345997]
[v3: addressed review at https://github.com/moby/moby/pull/34087#pullrequestreview-53902833]
[v4: addressed the case of upgrading from older daemon, in this case
container.HostConfig.IpcMode is unset and this is valid]
[v5: document old and new IpcMode values in api/swagger.yaml]
[v6: add the 'none' mode, changelog entry to docs/api/version-history.md]
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: 7120976d74195a60334c688a061270a4d95f9aeb
Component: engine
I tried using dm.directlvm_device but it ended up with the following
error:
> Error starting daemon: error initializing graphdriver: error
> writing docker thinp autoextend profile: open
> /etc/lvm/profile/docker-thinpool.profile: no such file or directory
The reason is /etc/lvm/profile directory does not exist. I think it is
better to try creating it beforehand.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: 6ca20ec771ab7c0ebf64c20021ca795746cf3ccb
Component: engine
It was noted[1] that container's HostConfig.ShmSize, if not set, should be
initialized to daemon default value during container creation.
In fact, it is already done in daemon.adaptContainerSettings, so we can use
value from container.HostConfig directly.
[1] https://github.com/moby/moby/pull/34087#discussion_r128656429
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: 0fb1fb1ce0177cf31dd96e9fdb4a5f55155a5966
Component: engine
Commit db63f9370e26d725357c703cbaf9ab63cc7b6d0a
extracted daemon configuration to its own
package, but did not update the Solaris stubs.
This updates the Solaris daemon.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 335033e25fae0173217e70d4b8dfc5df682ea913
Component: engine
The quotactl syscall is being whitelisted in default seccomp profile,
gated by CAP_SYS_ADMIN.
Signed-off-by: Panagiotis Moustafellos <pmoust@elastic.co>
Upstream-commit: cf6e1c5dfd07f5048606bb7b21464c658e252322
Component: engine
