The container effort in Fedora has until now been looked after by the
Atomic WG, since this Working Group is now going to focus mostly on
Fedora CoreOS, I propose to create a new container SIG to regroup
people interested in the maintenance of application containers in
This SIG would look after the container guidelines , the container
review process  and also the release process and tooling.
Please Reply if you're interested with helping out making the
Container story great in Fedora. If there is a good response, I will
create a Container SIG wiki page, and I guess we can ask for
container-devel mailing list for SIG discussions.
 - https://fedoraproject.org/wiki/Container:Guidelines
 - https://fedoraproject.org/wiki/Container:Review_Process
on behalf of the Fedora QA team I'd like inform you about some useful QA
processes and links that can help you with your Fedora CoreOS releases.
Here we go.
= Test Days =
When you have something new and interesting, or perhaps something you'd
like to get tested by different people/workflows/hardware configurations,
it's a good idea to ask the community to participate in a test day. You
provide the thing to be tested (an image, package, etc) and the test cases,
and we'll try to spread the word and support attendees.
You can see the schedule, the instructions and other important info at:
= Blockers and freeze exceptions =
Blocker process applies to products that are blocking Fedora release (which
is not CoreOS's case at this moment), but the freeze exception process can
be used by anyone. Before the major release milestones (Beta, Final), the
whole Fedora release goes into a freeze (see schedule ). Nothing can
enter stable updates except for builds that either fix an accepted blocker
bug, or have been granted a freeze exception.
When you have an update that you really need to get to stable updates, you
can ask for an exception. You explain why you need it, and during a blocker
bug meeting the importance of your use case will be weighted against the
risk of breaking something in our release-blocking products. A freeze
exception is then granted or denied, and the package is pushed stable (or
stays in testing until the freeze is over).
The process is described in detail at:
We have a webapp that can be used to propose the freeze exception:
https://qa.fedoraproject.org/blockerbugs/ (the Propose button)
or it can be done manually in bugzilla (see the SOP).
= Common Bugs =
When there's an important or perhaps just an uncomfortable bug in your
product, it's good to let your users know. One of the more visible
locations that gets referenced in release announcements is the "common
bugs" wiki page. It's used both pre-release (important bugs we're trying to
fix) and post-release (bugs we failed to fix and were not critical enough
to block the release, or bugs we found out too late).
F29 common bugs will be documented at (wiki page not yet created):
Here are F28 common bugs as an example:
The process of including a new entry is documented on the same wiki page.
You don't need anyone's permission, simply follow the process and edit the
page. Alternatively, you can mark it in bugzilla, and someone from QA will
get to it eventually and document it for you.
Usually we try to provide a short and understandable description of the bug
on that wiki page, so that even end users without deep technical knowledge
can read and understand it, and document a workaround or some other
solution when possible.
= Release validation matrices =
We have a process of using wiki matrices for tracking release validation
testing. It contains the test cases and their results for a particular
compose. The results are partly provided from manual testing and partly
from automated systems. Here's an example of F28 final compose summary page
(containing all matrices grouped into a single view):
As I learned, you give a heavy emphasis on automated testing and don't
intend to have manual test cases at the moment. Therefore we probably won't
extend our matrices with FCOS test cases and results (at least not yet,
might change in the future, e.g. if it changed to be release-blocking). All
you need to do is to pay attention to your automated test suite results. It
would be nice if Fedora QA had access to those results as well, and we've
been discussing that on your github issue tracker. One of the options is to
make your test runner public, another (possibly combined) is to send at
least the overall results to our ResultsDB instance , so that it's
stored in the same place as the rest of our automation results and we can
check on it in a programmatic way.
So, this might not be immediately useful to you, but we'll try to work on
it in the future.
= Communication =
I'm not sure whether I included all that is relevant or forgot something.
Either way, if you have any questions or requests, please contact us. You
can either ask here or on IRC (I and coremodule will be following your
channels), or you can use our QA channels:
Last few days, I spent doing a feasibility analysis on the migrating
from fedimg to ore, a subproject of mantle to release the Fedora cloud
ore/mantle comes from the CoreOS community. mantle is comprised of
multiple utility projects to keep the CL bits together.
The workflow for fedimg right now:
- Downloads the raw.xz image
- Uses the ImportVolume AWS API to create a volume via S3
- Creates the snapshot using the earlier created volume
- Registers the AMI of the snapshot provided
- Copies the AMI to other regions and makes the AMI and the snapshot public.
What if we migrate to Ore?
The process remain more or less the same except for a few changes:
- Downloads the .qcow2 image
* Once we start using the .qcow2 image we don't need releng to
produce two formats i.e. qcow2 & .raw.xz
- Converts the .qcow2 image to .vmdk format image using qemu-img
- Uses the newer supported AWS API i.e. ImportSnapshot which directly
creates the Snapshot uploading the image via S3
- Registers the AMI with the snapshot.
- Copies the AMI to other regions.
- Ore also skips any of the steps already processed which makes it
easier for the AMIs maintainer.
- Ore has a more maintainers than fedimg.
- It's better to focus on a single project than maintaining two.
Two areas where it needs more research
- how do we send out the fedmsg messages when we move to ore
- making the images & the snapshots public.
Sayan Chowdhury <https://sayanchowdhury.dgplug.org/>
Senior Software Engineer, Fedora Engineering - Emerging Platform
GPG Fingerprint : 0F16 E841 E517 225C 7D13 AB3C B023 9931 9CD0 5C8B
Proud to work at The Open Organization!
A number of us who regularly attend the Fedora CoreOS meeting won't be able to
attend tomorrow. I propose we cancel. Anyone opposed?
If someone wants to volunteer to run the meeting please let me know and I can
help answer any questions. Some documentation is here: https://github.com/coreos/fedora-coreos-tracker/#meetings