From Fedora Project Wiki
< Atomic
Container Policy VFAD
This VFAD was convened in order to clear out a queue of unresolved questions about the Fedora Layered Image Build System (FLIBS) [Container:Guidelines|Container Guidelines]. This included several different issues which arose around reviewing some of the early container submissions.
What follows is a summary of all of the decisions made at the VFAD, which will be implemented through container guidelines changes in the next week. For full discussion, see the Notes below.
Decisions
Notes from 2017-03-10 VFAD, covering Container Policy
Original Etherpad here: https://public.etherpad-mozilla.org/p/20170310-FedoraAtomicWGFVAD
Notes in case Etherpad is lost:
Welcome to the 2nd Virtual Fedora Activity Day for VFAD for the Fedora Atomic WG.
Attendees: dustymabe, roshi, jberkus, kushal, maxamillion, trishnag, jbrooks, ttomecek, jantill, yzhang, mkocka, goern, jhogarth, dwalsh
Fedora Container Guidelines are here: https://fedoraproject.org/wiki/Container:Guidelines
Project Atomic Upstream Container Best Practices are in: http://docs.projectatomic.io/container-best-practices/
Atomic CLI: https://github.com/projectatomic/atomic
Need to merge Atomic CLI docs -- copy into there by now?
10:00 - 10:45 RUN, INSTALL, UNINSTALL (Issues #242 and #244)
- https://pagure.io/atomic-wg/issue/242
- https://pagure.io/atomic-wg/issue/244
http://www.projectatomic.io/docs/usr-bin-atomic/
These LABELs are targeting the atomic cli which is important to Fedora Atomic Host in order to be able to target "system containers" (which will allow us to remove kubernetes from the base ostree).
Dockerfiles should be self-documented about the implications of these LABELs (or at least a link/ref to Fedora Container Guidelines)
INSTALL UNINSTALL are OPTIONAL
INSTALL
Optional or required?
AGREED: Should be optional, only recommended if the container needs some action beyond "pull image"
should point to a script inside the image
Should also explain that this LABEL is specific for the atomic cli and won't be meaningful to a "vanilla" docker/rkt client
Need command examples
Need brief overview for why you would want to do this (for people new to atomic)
Guidelines on what is "allowed" vs "restrictions"
Allowed:
Can easily pull this from the atomic-cli docs
Restrictions:
scripts should be as simple as possible
scripts must run without error
Testing of INSTALL command?
UNINSTALL
if there is an INSTALL there should probably be an UNINSTALL
container removal should "clean up"
exceptions: not required to delete directories including user files
surely there's RPM guidelines on this?
what about configuration files?
removal
YES remove systemd unit files
NO removing user files (/var/lib/httpd)
??? Configuration files
Yes if NOT MODIFIED from original content at install time (no change in checksum of file detected)
No if MODIFIED from original content at install time (change in checksum of file detected)
Partial RPM stuff (WIP) will replace a lot of this.
RUN
Label should only exist in the event that the container maintainer intends for the container to be used with the 'atomic run' command
Otherwise, USAGE is required with an example therein
USAGE
Example/doc of how to run/use this particular container
Might be useful to target the Atomic help file -> http://docs.projectatomic.io/container-best-practices/#_creating_a_help_file
AGREED:
either USAGE or RUN is required
RUN if it works with Atomic Run
AGREED GUIDELINES for INSTALL/UNINSTALL: point to /usr/bin/atomic docs and also supply short description that are loose guidelines for what to do on INSTALL/UNINSTALL.
Action Items:
Josh to Follow Up on RUN
Dusty to follow up on INSTALL/UNINSTALL
Jerry Zhang to draft guideline section on System Containers.
10:45 - 11:30 Version/Release (Issue #235)
https://pagure.io/atomic-wg/issue/235
Typically, a RPM has a very specific git ref that correlates to a N-V-R, this is not the case in container land.
For Containers, is the release the release of the "container" as an entity or of the rpm that's the primary version of the container?
VERSION: the version of the *primary* RPM package in the container (the one the "user") cares about.
But we can't do that because Automatic Rebuild
And don't have any way to automatically pull the version out of the RPM
So might get out-of-sync
RELEASE: the release of the container itself (usually "1")
The labels are requirement for koji. And for the registry. Really, we need them.
Versions for Release Candidates today (for example):
"query_data.rclist": [
"f25/cockpit:130-1.4.f25docker",
"f25/cockpit:130",
"f25/cockpit",
"f25/kubernetes-node:0.1-3.f25docker",
"f25/kubernetes-node:0.1",
"f25/kubernetes-node",
"f25/kubernetes-controller-manager:0.1-3.f25docker",
"f25/kubernetes-controller-manager:0.1",
"f25/kubernetes-controller-manager",
"f25/mariadb:10.1-2.f25docker",
"f25/mariadb:10.1",
"f25/mariadb",
"f25/kubernetes-apiserver:0.1-3.f25docker",
"f25/kubernetes-apiserver:0.1",
"f25/kubernetes-apiserver",
"f25/kubernetes:0.1-2.f25docker",
"f25/kubernetes:0.1",
"f25/kubernetes",
"f25/kubernetes-scheduler:0.1-4.f25docker",
"f25/kubernetes-scheduler:0.1",
"f25/kubernetes-scheduler",
"f25/kubernetes-master:0.1-5.f25docker",
"f25/kubernetes-master:0.1",
"f25/kubernetes-master",
"f25/s2i-base:1-2.f25docker",
"f25/s2i-base:1",
"f25/s2i-base",
"f25/kubernetes-kubelet:0.1-3.f25docker",
"f25/kubernetes-kubelet:0.1",
"f25/kubernetes-kubelet",
"f25/flannel:0.1-3.f25docker",
"f25/flannel:0.1",
"f25/flannel",
"f25/kubernetes-proxy:0.1-3.f25docker",
"f25/kubernetes-proxy:0.1",
"f25/kubernetes-proxy",
"f25/etcd:0.1-5.f25docker",
"f25/etcd:0.1",
"f25/etcd",
"f25/toolchain:1-2.f25docker",
"f25/toolchain:1",
"f25/toolchain"
AGREED: Decision: To use Version 0 until we have an automated solution
Only increment the Release Number
Remember to pull from git before incrementing the release number
Action Items:
Adam to follow up on "can the build system automatically set the Version for the container label?"
Can this be done with defining a "macro language" for Dockerfiles?
Adam and Jason to write para including Version 0 rule
ISSUE: this decision requires that all container definition changes be backwards-compatible. Discuss?
11:30 - 12:00 DESCRIPTION (Issue #243)
Issue: https://pagure.io/atomic-wg/issue/243
"HELP" as well
Proposal:
Require narrative description
Label called HELP
Requirements in issue 243
Also in file help1.txt in root of container
Questions about help file vs Label
File could be really long
AGREED: Have a file with the full verbose description in dist-git
Have a public link to that file
For the LABEL have a link to that public URL
File will be copied to help1.txt in the container (or README?)
If there are other labels containing the same information, these labels need to be added by a conversion step (not the maintainer) and content needs to be copied from the DESCRIPTION label.
Action:
* James to write up guidelines for the agreed guideline (with Josh)
* Tomas to follow up on requested changes (pick up README/help1.txt, have it supercede the label)
Contents:
This would include, for all containers:
what service/software the container provides
It would also include all of the following which are applicable to the container:
what purpose it fulfills in a larger infrastructure
what each VOLUME in the container is for and what kinds of storage they need
any details about dependencies on other container images
links to documentation or software project pages
any special requirements the container has (like lots of RAM, or sound server access)
details on any required configuration, or links to documentation on configuration
13:00 - 13:30 Volumes (Issue #234)
https://pagure.io/atomic-wg/issue/234
AGREED
We should REQUIRE maintainers to declare all expected volumes
RUN/USAGE should contain volume examples
HELP should have details of the volumes required
Action:
James to write guideline for this
13:30 - 14:00 Overage
14:00 - 14:45 Systemd containers (Issue #233) (will try to recruit Dan Walsh)
Issue: https://pagure.io/atomic-wg/issue/233
1. Do we want to accept systemd containers? YES
but only if needed (multi-service, reaping issue, pruning, etc.)
AGREED: REQUIRE note in HELP and RUN/USAGE example which includes systemd requirements
Options:
docker run -ti --tmpfs /run -v /sys/fs/cgroup:/sys/fs/cgroup IMAGE ...
Or
install oci-systemd-hook and use default docker package
docker run -ti IMAGE ...
Fedora base image to set CONTAINER=oci? Update base image?
or do we want a fedora-init base image?
three images: microdnf, regular, systemd(init)
this is future
Action:
Jason and Dan Walsh to write guidelines for SystemD containers
Dusty to open issue to set CONTAINER=oci in Fedora base image
Other Business
System Containers
Jerry to write general guidelines
Need HOWTO doc to link to
Action:
Jerry to write para in guidelines
Action:
Mike to write HOWTO for writing a container following the guildelines
Jerry will help with systemcontainer part
Jason to help with systemd container howto