blog

Flock 2017

08 September 2017

Flock is over. It was nice, good conversations, useful talks and workshops, it
was awesome to see everyone once again. And I liked the location.

The theme of this year’s Flock was “do-sessions”. It means, less talks and more
workshops, hackfests and discussions. I liked that I could try things and be
part of the discussions, but at the same time, I missed big talks. Also some
talks with similar topics were scheduled at the same time, so one had to make
tough choices.

One of the most visible things one could see during Flock were comics
portraits! These were drawn by a professional artist. Everyone was running
around with a portrait of their own, I loved this! The booth was sponsored by
RHEL product marketing team.

Here are some of my assorted notes from talks and workshops I attended.

Keynote

Matt was running his favorite graphs and current state of the art. They were
looking pretty good!

Fedora 25 and 26 received good feedback and press talked about those releases
positively.

Looks like that Fedora is getting more and more installs (26 is bigger than
25, 25 is bigger than 24).

Factory 2

Mike Bonnet talked about vision of Factory 2 team and introduced basic concepts
of the new tools the team is working on. Most of the tools got a standalone
presentation on their own by their core contributor.

The tools include:

Module Build Service

Freshmaker

Greenwave

WaiverDB

ResultsDB

Arbitrary Branching

The interesting point from Mike’s talk was when he tried to present motivation
for all the automation the team is working on:

There is more than 20.000.000 tasks in koji.

Latest Fedora release contains 54.000 binary RPMs.

Which is 215 RPMs per active maintainer.

I hope it’s obvious that humans cannot manage this. Especially with
introduction of modules. Hence all the new tools which will make our lives
easier.

Freshmaker

Contains policies to rebuild artifacts.

And initiates rebuilds of artifacts.

There are various events one may be interested to rebuild an artifact.

E.g. for container images:

When RPM hits stable (slower workflow).

When RPM (or module) passes tests (faster workflow).

Greenwave & WaiverDB

A service for making decisions – is this artifact good?

Gating points at certain places, e.g. a test of artifact has finished.

Gating is based on policies.

dist.* checks, which you may find in bodhi, are Fedora policies.

WaiverDB is a database of waivers against ResultsDB.

Arbitrary Branching

What happens when a module goes EOL?

Should there be a dnf plugin to inform the user?

Arbitrary branches can be used only with modules.

The maintainer is able to release the module via Bodhi.

Multi-arch container image build system

Adam Miller talked about the architecture of this system:

There will be one OpenShift cluster per CPU architecture.

There will be one additional OpenShift cluster which will orchestrate the builds.

There was a question from audience why not label nodes and use selectors.
Response from Adam was, that upstream team tried to go for this solution, but
realized it would be too hard to implement so they chose the path of multiple
clusters.

Module build service

Ralph had a nice and short presentation about MBS. The most important part for me were the future plans. Here they are:

Modularity UX feedback

This session was up every day. It was interesting to see community members to
go though the workflow of modular dnf. They asked some very good questions and
found several issues (including me!). I think Martin Hatina received a very
solid feedback which he’ll be working on next weeks. The main outcome for me
was, when Sinny Kumari asked about a container
image of boltron for different CPU architectures. Obviously we didn’t provide
anything like this. So I started working on a guide how to do this locally.
Expect another blog post!

Let’s build a module

This was my workshop. Overall, I received good feedback. Unfortunately we
didn’t have enough time to build some real modules, nor was Internet connection
stable enough. The most interesting outcome for me was that people could see
what it takes to create a new module and what the steps are to build it
locally. Clearly, this was confusing to some, since the process of defining
modulemd is not completely straight-forward. There was a lot questions and
fruitful discussion. But in the end, everyone seemed to be on the same page.
Which is awesome. The interesting part is that prior to my session, we were
having pretty advanced discussion about what it would take to modularize the
whole distribution. And after that “complex” discussion, we’ve got back “to the
roots” of creating roots. It was great to teach everyone the essentials of
creating modules so people now understand what modules really are and how to
make them.