[MIR] containerd
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
containerd (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
containerd-app (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Availability]
The containerd package is available in Ubuntu Universe, and builds for amd64,
arm64, armhf, i386, ppc64el, s390x
It has been available since at least Yakkety in mid 2016:
https:/
[Rationale]
containerd controls runC (which is the subject of MIR bug #1817336).
From their github page (https:/
is an industry-standard container runtime with an emphasis on simplicity,
robustness and portability."
The "industry standard" bit is about OCI (Open Container Initiative:
https:/
[Security]
- CVE: there are no CVEs for it currently: http://
- Ubuntu CVE tracker for universe also shows no hits: https:/
- one hit in the OSS security mailing list about CVE-2019-5736 (the runC
vulnerability): https:/
- no suid/sgid binaries
- executables are in /usr/bin as expected
- the package installs a systemd service and the daemon runs as root, at least
initially: /lib/systemd/
- the service by default listens on a localhost socket:
tcp 0 0 127.0.0.1:39301 0.0.0.0:* LISTEN 21114/containerd
- the service also listens on a unix socket, available only to root:
srw-rw---- 1 root root 0 Feb 22 15:54 /run/containerd
[Quality assurance]
After installing the package it must be possible to make it working with a
reasonable effort of configuration and documentation reading.
- the service starts after installation without errors, and since no default
config file is shipped, it assumes defaults on its own. A quick check with the
unsupported bundled ctr(1) tool shows the service is live:
root@disco-runc:~# ctr images list
REF TYPE DIGEST SIZE PLATFORMS LABELS
root@disco-runc:~#
The DEP8 test can also be run manually right after installation: http://
There are no debconf questions.
Bugs:
- upstream issues: https:/
- 110 open
- 657 closed
- two bugs in debian (https:/
- https:/
- "containerd: 0.2.3 ds1-1 breaks docker 1.11 - unable to start containerd"
- seems closed
- https:/
- "containerd 0.2.3+git201701
- unanswered for > 1y
- no open bugs in Ubuntu at the moment: https:/
- 4 closed bugs in ubuntu:
- https:/
- "Old clients cannot talk to Docker in 16.04"
- https:/
- "[16.10 FEAT] Upgrade Docker to newest version 1.12"
- https:/
- "Please upgrade docker.io to latest 1.12.6"
- https:/
- "failing to start on ppc64el: R_PPC64_ADDR16_HA 277ef287d88 for symbol `' out of range"
Debian PTS:
https:/
https:/
- a few lintian warnings
- debian is behind upstream (0.2.3 vs 1.2.4)
- debian experimental has a 1.2.4 upload (Ubuntu Disco has 1.2.2):
- first upload since 2017-08-08
- https:/
- package is out of date regarding the debian policy
- excuses page looks bad:
https:/
"581 old (needed 10 days)"
- Updating containerd 0.2.3 introduces new bugs: #855922, #857819, #863248, #923431
It's unclear if the 1.2.4 version in experimental is better.
The package should not deal with exotic hardware which we cannot support.
- no exotic hardware involved
Tests:
- there is a basic smoke DEP8 test which downloads a docker container and runs a command in it
http://
- the package also runs tests during package build time, except on armhf:
https:/
(search for dh_auto_test)
debian/watch:
- a debian/watch file is provided, and it works:
ubuntu@
uscan: Newest version of containerd on remote site is 1.2.4, local version is 1.2.2
uscan: => Newer package available from
https:/
Successfully symlinked ../containerd-
Full lintian:
- lintian -I --pedantic output: http://
- I would highlight:
- problems with d/copyright
- missing build-depends
- out of date standards
- some cleanups needed in the -dev package (perms, .git dirs)
- binaries with no manpages
The package should not rely on obsolete or about to be demoted packages. That
currently includes package dependencies on Python2 (without providing Python3
packages), and packages depending on GTK2.
- none seen
[UI standards]
There is no i18n for containerd.
[Dependencies]
Runtime dependencies are in main with the exception of runc, subject of another MIR (1817336)
- the package has one golang build dependencies that comes from Universe: go-md2man.
That package itself has other golang build dependencies that are in Universe.
The MIR team currently seems to have an understanding
(https:/
to a case-by-case analysis to avoid populating main with too many packages
like this.
- there are no python{2,3} or GTK2 dependencies
[Standards compliance]
- the package is behind in its declaration of standards compliance: 3.9.7 vs 4.3.0
- golang-
containerd source, has tons of golang source code shipped in
/usr/
trees of several projects. There are currently no reverse-depends for this
package, so it can probably be placed in Universe. This package is also where
many of the lintian issues come from.
- FHS is fine otherwise (I'm not sure if the above is an FHS violation)
- golang buildsystem is "odd". From d/rules, for example:
override_
# copy pristine source for "/usr/share/gocode" to get into "golang-
mkdir -p .pristine-source
tar -c --exclude=debian --exclude=.pc --exclude=
# set up GOPATH symlink farm
mkdir -p '$(OUR_
ln -sfT '$(CURDIR)' '$(OUR_
[Maintenance]
All packages must have a designated "owning" team, regardless of complexity,
which is set as a package bug contact.
- TBD
This package is definitely important in the container ecosystem. It drives other runtimes (runc, docker), and is driven by other projects (k8s).
[Background information]
None at this time.
Related branches
- Robie Basak: Approve
-
Diff: 12 lines (+2/-0)1 file modifiedsupported-misc-servers (+2/-0)
ubuntu-server is now subscribed to bugs