[atomic-wg] Issue #233 `Container guidelines for systemd based containers`
by Jason Brooks
jasonbrooks added a new comment to an issue you are following:
``
How does this look?
@dwalsh
=== systemd-Based Containers ===
A systemd-based container includes the systemd system and service manager as part of its image in order to run one or more systemd-managed services within a single container, to take advantage of systemd's zombie-reaping capabilities, or to better handle container logging.
systemd-based containers' Dockerfiles have the following differences:
==== LABELS ====
Run/Usage: systemd-based containers should include a Run or Usage label that directs users to include "--tmpfs /run", "--tmpfs /tmp", and "-v /sys/fs/cgroup:/sys/fs/cgroup", which systemd requires to run. Container hosts running the default Fedora docker package and the oci-systemd-hook don't require these run options, but they should be included for compatibility with other container hosts.
For example:
<pre>
LABEL Usage="docker run -d -P --tmpfs /run --tmpfs /tmp -v /sys/fs/cgroup:/sys/fs/cgroup -v owncloud-data:/var/lib/owncloud -v owncloud-config:/etc/owncloud owncloud"
</pre>
==== CMD/ENTRYPOINT ====
systemd-based containers must include "/sbin/init" as an ENTRYPOINT or CMD, which will start systemd inside the container at run time. systemd will start up and manage services enabled with the Dockerfile using the standard "systemctl enable foo" commands in RUN statements.
For example:
<pre>
FROM fedora:25
ENV container=oci
RUN dnf -y install httpd; dnf clean all; systemctl enable httpd
EXPOSE 80
CMD [ "/sbin/init" ]
</pre>
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/233
7 years, 1 month
2wk atomic release candidate: 20170314
by Dusty Mabe
We are going to attempt to release the 20170314 images.
These images contain the following ostree version/commit:
25.80
24d4499420ffb2cc49681020bbe5aa6780d780d2b811eab1f5ffea6446b5a4c5
The atomic host VM images are here:
https://kojipkgs.fedoraproject.org/compose/twoweek/Fedora-Atomic-25-20170...
The ISO image is here:
https://kojipkgs.fedoraproject.org/compose/twoweek/Fedora-Atomic-25-20170...
The AMIs are here:
Fedora-Atomic-25-20170314.0.x86_64 EC2 (ap-northeast-1) ami-b5faa8d2 hvm standard
Fedora-Atomic-25-20170314.0.x86_64 EC2 (ap-southeast-1) ami-c8c270ab hvm standard
Fedora-Atomic-25-20170314.0.x86_64 EC2 (ap-southeast-2) ami-e0191483 hvm standard
Fedora-Atomic-25-20170314.0.x86_64 EC2 (eu-central-1) ami-8401d6eb hvm standard
Fedora-Atomic-25-20170314.0.x86_64 EC2 (eu-west-1) ami-42447324 hvm standard
Fedora-Atomic-25-20170314.0.x86_64 EC2 (sa-east-1) ami-70e8891c hvm standard
Fedora-Atomic-25-20170314.0.x86_64 EC2 (us-east-1) ami-89f55b9f hvm standard
Fedora-Atomic-25-20170314.0.x86_64 EC2 (us-west-1) ami-30025a50 hvm standard
Fedora-Atomic-25-20170314.0.x86_64 EC2 (us-west-2) ami-d225abb2 hvm standard
Fedora-Atomic-25-20170314.0.x86_64 EC2 (ap-northeast-1) ami-bff7a5d8 hvm gp2
Fedora-Atomic-25-20170314.0.x86_64 EC2 (ap-southeast-1) ami-9bc270f8 hvm gp2
Fedora-Atomic-25-20170314.0.x86_64 EC2 (ap-southeast-2) ami-11181572 hvm gp2
Fedora-Atomic-25-20170314.0.x86_64 EC2 (eu-central-1) ami-100fd87f hvm gp2
Fedora-Atomic-25-20170314.0.x86_64 EC2 (eu-west-1) ami-c34473a5 hvm gp2
Fedora-Atomic-25-20170314.0.x86_64 EC2 (sa-east-1) ami-eee98882 hvm gp2
Fedora-Atomic-25-20170314.0.x86_64 EC2 (us-east-1) ami-44f75952 hvm gp2
Fedora-Atomic-25-20170314.0.x86_64 EC2 (us-west-1) ami-a6025ac6 hvm gp2
Fedora-Atomic-25-20170314.0.x86_64 EC2 (us-west-2) ami-f029a790 hvm gp2
Cheers!
Dusty
P.S. The diff between this and the previous released version is:
Upgraded:
atomic-devmode 0.3.3-1.fc25 -> 0.3.6-1.fc25
bind99-libs 9.9.9-4.P5.fc25 -> 9.9.9-4.P6.fc25
bind99-license 9.9.9-4.P5.fc25 -> 9.9.9-4.P6.fc25
cockpit-bridge 131-1.fc25 -> 134-1.fc25
cockpit-docker 131-1.fc25 -> 134-1.fc25
cockpit-networkmanager 131-1.fc25 -> 134-1.fc25
cockpit-ostree 131-1.fc25 -> 134-1.fc25
cockpit-system 131-1.fc25 -> 134-1.fc25
container-selinux 2:2.6-1.fc25 -> 2:2.10-1.fc25
coreutils 8.25-15.fc25 -> 8.25-16.fc25
coreutils-common 8.25-15.fc25 -> 8.25-16.fc25
fedora-repos 25-2 -> 25-3
freetype 2.6.5-1.fc25 -> 2.6.5-3.fc25
gnutls 3.5.9-2.fc25 -> 3.5.10-1.fc25
gssproxy 0.6.1-2.fc25 -> 0.7.0-1.fc25
kernel 4.9.12-200.fc25 -> 4.9.13-201.fc25
kernel-core 4.9.12-200.fc25 -> 4.9.13-201.fc25
kernel-modules 4.9.12-200.fc25 -> 4.9.13-201.fc25
krb5-libs 1.14.4-4.fc25 -> 1.14.4-7.fc25
libseccomp 2.3.1-1.fc25 -> 2.3.2-1.fc25
libsss_idmap 1.14.2-2.fc25 -> 1.15.1-1.fc25
libsss_nss_idmap 1.14.2-2.fc25 -> 1.15.1-1.fc25
libsss_sudo 1.14.2-2.fc25 -> 1.15.1-1.fc25
nss 3.28.1-1.3.fc25 -> 3.28.3-1.0.fc25
nss-pem 1.0.2-2.fc25 -> 1.0.3-2.fc25
nss-softokn 3.28.1-1.0.fc25 -> 3.28.3-1.1.fc25
nss-softokn-freebl 3.28.1-1.0.fc25 -> 3.28.3-1.1.fc25
nss-sysinit 3.28.1-1.3.fc25 -> 3.28.3-1.0.fc25
nss-tools 3.28.1-1.3.fc25 -> 3.28.3-1.0.fc25
nss-util 3.28.1-1.0.fc25 -> 3.28.3-1.0.fc25
oci-systemd-hook 0.1.4-4.git15c2f48.fc25 -> 1:0.1.5-1.git16f7c8a.fc25
openssh 7.4p1-3.fc25 -> 7.4p1-4.fc25
openssh-clients 7.4p1-3.fc25 -> 7.4p1-4.fc25
openssh-server 7.4p1-3.fc25 -> 7.4p1-4.fc25
pcre 8.40-4.fc25 -> 8.40-5.fc25
python3-rpm 4.13.0-6.fc25 -> 4.13.0.1-1.fc25
python3-sssdconfig 1.14.2-2.fc25 -> 1.15.1-1.fc25
rpm 4.13.0-6.fc25 -> 4.13.0.1-1.fc25
rpm-build-libs 4.13.0-6.fc25 -> 4.13.0.1-1.fc25
rpm-libs 4.13.0-6.fc25 -> 4.13.0.1-1.fc25
rpm-plugin-selinux 4.13.0-6.fc25 -> 4.13.0.1-1.fc25
screen 4.5.0-1.fc25 -> 4.5.1-1.fc25
selinux-policy 3.13.1-225.10.fc25 -> 3.13.1-225.11.fc25
selinux-policy-targeted 3.13.1-225.10.fc25 -> 3.13.1-225.11.fc25
sssd-client 1.14.2-2.fc25 -> 1.15.1-1.fc25
vim-minimal 2:8.0.347-2.fc25 -> 2:8.0.425-1.fc25
7 years, 1 month
[atomic-wg] Issue #235 `Container guidelines for versioning of packages in
the container`
by James Hogarth
jhogarth reported a new issue against the project: `atomic-wg` that you are following:
``
Since the container build process uses stable repos it's tricky to time a container update alongside an update of key components.
It also leads to the question to the guidelines of "what does 'ENV NAME=myawesomecontainer VERSION=0.1 RELEASE=1 ARCH=x86_64' actually mean?"
In the case of the owncloud container review one would think it refers to owncloud itself (presently at 9.1.4) but the container also has httpd and php which may be susceptible to security issues and knowing the version within may be important.
There's also an issue of tying the version in the ENV to the actual package in place.
We should have something in the guidelines to ensure this. The RUN dnf -y install owncloud (in this instance) should probably have dnf -y install owncloud-${VERSION}-${RELEASE} in order to prevent race conditions, although this would have an effect on the proposed fortnightly build process with the timing between an RPM maintainer updating the package and the container maintainer presenting a container update.
We either need a way to attempt to automate this, accept failures and rebuilds or some other thing I haven't thought of.
In addition we should allow building the container from at least the testing repos, if not the koji buildroot or similar setup, to prevent a significant lag between an update in fedora and being able to provide that update in a container based service.
The worst case would be a package in updates-testing for a full week and a poorly timed move to stable with the next container build, as proposed elsewhere, two weeks away for a full three weeks for a potential vulnerability or major bug.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/235
7 years, 1 month
[atomic-wg] Issue #238 `VFAD: Settle container policy open questions`
by Dusty Mabe
dustymabe reported a new issue against the project: `atomic-wg` that you are following:
``
We have identified quite a few policy decisions that need to be made surrounding containers before we can start reviewing these things in bulk. Some of the issues are below:
- https://pagure.io/atomic-wg/issue/235
- https://pagure.io/atomic-wg/issue/234
- https://pagure.io/atomic-wg/issue/233
We need to have a group of people really get together and hash these issues out and publish the results so that we can start reviewing containers at a faster rate. I am giving the point on this to @jberkus as discussed in today's IRC meeting. A VFAD next week would probably be a great way to hash out some of this and get decisions back to users and reviewers fast.
other interested parties that want to take part in the discussion are @gbraad, @kushal, @jhogarth. It's also required that @maxamillion be there and would probably be good to have @jbrooks there. I'll add more names as I find people.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/238
7 years, 1 month