Flock 2015 – Report Day0 and Day1

Day 0:

I almost missed my flight at the san jose airport, My flight was supposed to take off by 2:55. There was a big queue at the airport around 2:30 pm.  I cleared TSA around 2:40 pm. It was tight!

Met  Major Haydon(major.io) at the Chicago midway (MDW) airport. Major was a keynote speaker at flock. He works for rackspace. The flight from chicago landed about 12:45 am in the morning at Rochester. We took a cab to the hotel. The hotel is 10 minutes from the airport.  My roommate aditya was jetlagged and was already sleeping. Managed to slip into  the bed without waking him up!

Day 1:

FPL (fedora project leader) Matt Miller did his usual state of the union in the morning. As the name implies it is about the current state of fedora project. More details about the state of union can be seen at http://fedoramagazine.org/state-fedora-2015-edition/

Koschei – Continuous integration for fedora

The next talk i attended was Koschei – Continuous integration for fedora packages by mikolaj. koschei is a CI  system that schedules koji builds and make sure that fedora packages are sane all the time. https://github.com/msimacek/koschei. koschei uses koji scratch builds. The scheduler of koschei is intelligent enough to schedule these builds when koji slaves are not busy.

The main motivation of koschei is to find FTBFS early and inform maintainers. The production instance of koschei is here https://apps.fedoraproject.org/koschei. More details about this presentation is here https://github.com/msimacek/koschei/blob/master/doc/pp/koschei.tex

Koji 2.0

Mike McLean (https://fedoraproject.org/wiki/User:Mikem) wrote the first line of code when dinosaurs were still alive :). Now he has plans to clean up koji under koji 2.0 project. koji is used to build packages for fedoraproject, it has many roles (rpm building, compose etc).

Mike wants to use python 2.6 for koji-2.0. It will also has support for python 3.0 using python-six. Most of the audience including me suggested that python 2.7 as it is the latest stable in 2.x release. Mike explained that he wants to support koji-client on RHEL6 which comes with python 2.6.

Luke Macken in the audience went even further and suggested that the server side of koji  should drop support for python 2.x and entirely written using python 3.0.

some of the koji 2.0 proposed features include,

•  build namespaces (re-building same nvr again and again)
• json-rpc
• content generators (https://fedoraproject.org/wiki/koji/ContentGenerators)
  •  other type of build process to feed into koji
  • robust metadata import
•  Following build types are proposed
  • rpm builds
  • maven builds
  • windows builds
  • image builds
  • + ???

Mike’s email about koji2.0 to koji-devel mailing list is available here https://lists.fedorahosted.org/pipermail/koji-devel/2015-June/000000.html

His talk sides are available here https://mikem.fedorapeople.org/Talks/flock-2015-koji-2.0/

Reproducible builds using koji

Reproducing koji builds was scheduled at 2:30 pm, It was the 3rd talk of the day.

In this talk Mike Mclean talked about debian’s reproducible build project
https://wiki.debian.org/ReproducibleBuilds. Builds are not (binary) reproducible because of following reasons,

•  Timestamps embedded into binaries during build time
• Usage pseudo-random numbers to generate code data
• Umask/uid
• uname, hostname, username
• locale
• Timezone

Mike was really appreciative of the debian reproducible build project. The debian team is actively upstreaming their patches. Some one in the audience noted that debian still allows builds created on developer workstations to be uploaded and deployed to repositories. So by having reproducible builds the binaries are easily verifiable.

Then Mike went on to talk about what it would take to make builds reproducible on koji He talked about using task-id/repo-id to preserve the state of repo’s and recreating them at a later point.  He also noted that the rpm metadata included in the rpm package makes it impossible to reproduce.

One of the audience suggested that the metadata could be  moved out of the
package in future to enable reproducible builds. Mike noted that he is very busy with  koji-2.0 work and does not want to spend more time on making builds  reproducible. However he was open to helping out someone who is willing to take on this challenge. Any takers?

Super privileged containers

The last talk of the day i attended was about ‘super privileged containers’ by Dan Walsh. Dan, showed lot of funny gif’s about selinux and docker before starting the presentation.His presentation is available here https://dwalsh.fedorapeople.org/Presentations/SPC/

RedHat’s atomic host doesn’t support yum install. Redhat customers often want some utlity to be included in the atomic host and Redhat wants atomic host to be minimal as possible. As you one can see these two goals are competing with each other. The current rule to include an utlity in the atomic host is to prove that it won’t work in a container.

Customers want to ship an application that will manage a host or manage other containers. Enter Super privileged container aka SPC.
A super privileged container must have the following

• It should  be a privileged container
• will enable all capabilities (CAP_*) in the container
• disable selinux separation (it will lie in the container)
• disable user namespace;
• disable mounting read only file systems;
• Allow creation of linux devices.
• Specific namespaces like network, ipc and pic should be disabled
  respectively using (‘–net=host;–net=ipc,–pid=host)
• SPC should mount /run into /run of the container and let container process to communicate with system dbus, systemd, or even docker daemon (docker run -v /run:/run)
• The entire host file system should be shared inside the container using
  docker run -v /:/host -e HOST=/host.

To do all these, you have to run a big docker command:
"/usr/bin/docker run -t -i --rm --privileged -v /:/host -v /run:/run -v
/etc/localtime:/etc/localtime --net=host --ipc=host --pid=host -e HOST=/host
-e NAME=fedora-spc -e IMAGE=fedora fedora /bin/sh"

As you can see this is a big command, redhat has introduced a ‘rheltools’ container image with project atomic. This tools image includes strace,gdb,sosreport and other tools The atomic command now allows users to run containers in SPC mode.

'atomic run --spc rheltools /bin/sh'

The big docker command now is encapsulated into a small atomic command.

Atomic command wraps os-tree as well,
– atomic host upgrade
– atomic host rollback
– atomic host status

Today there is not a good way to tell your users how to run the container you created. Some container may need special privileges for example ntpd needs –cap_add SYS_TIME; Without SYS_TIME ntpd container will break; To solve this problem redhat has introduced container image labels. Redhat added labels patch to docker which allows developer to create labels during container build time.'LABEL RUN docker -d -n ntpd --cap_add SYS_TIME IMAGE'

Now, ‘atomic run ntpd’ will automatically read this image json metadata and run the container appropriately.

Dan also distributed his container coloring book at the talk. If you want a pdf version of it please see http://bit.ly/1KuB1c6 (pdf). If you haven’t see his selinux coloring book checkout http://bit.ly/1K4Kueu. These books are designed by mairin duffy.

After the conference, we had a game night where we played board games until 11 pm

Advertisement