From Fedora Project Wiki

This page documents how Atomic images are generated, updated, etc. to provide a better understanding for Cloud WG members. This is a work in progress, as many changes discussed below are noted as not having been implemented yet.

Educate yourself

ostree command usage

The `ostree summary` command runs on ostree repositories. It generates a summary file describing the repository, which is the file that MirrorManager will need to be updated to look for.

In order to create an ostree repository locally, you can run `mkdir REPO && ostree --repo=REPO init --mode=archive-z2`, where REPO is the desired path of the repository. This command will set up the proper file structure for a new ostree repository.

The `rpm-ostree compose tree` command can be used to capture a set of RPMs as ostree repository commits. This command takes a treefile as an argument, and is intended to be used on build servers.

Treefiles should be formatted as JSON. Documentation on creating a treefile is found here.

Official documentation on this utility is found here.

Note: `ostree` and `rpm-ostree` are two different commands. This can be confusing. `rpm-ostree` is only available in the F21 repos at the time of this writing. Therefore, if you're going to work with ostree, it's probably best to use an F21 machine.

Compose script operations

Scripts that compose images need to be updated to generate the files required by Atomic. Releng scripts "buildbranched" and "buildrawhide" need to be updated with Atomic code, similar to "run-pungi". All of these scripts need to run `ostree summary -u` to generate ostree summary files for each compose.

Image (qcow2) generation

The Atomic cloud images are built using ImageFactory, which calls into Anaconda using a kickstart file. The kickstart file refers to the tree composed above (just like how with mainline packages, the kickstart file points to yum repositories).

The kickstart files for Atomic are located here: https://fedorahosted.org/fedora-atomic/

MirrorManager operations

Normally, MirrorManager crawls directories looking for repositories. In that case, repositories are identified by their repomd.xml file. The info contained in that file is used to build the metalinks. However, for atomic images, we don't care about repomd.xml files. Future patches to MirrorManager will need to look for an ostree repo with a summary file instead.

MirrorManager's "mirrorlist_server.py" file needs to be updated to generate a metalink to the summary file generated by the compose scripts.