The releng and atomic groups had a meeting today to discuss several items that we have identified as things that are important to us in the (hopefully near) future. I'm going to try to summarize the meeting in this ticket and identify work items that can be worked on as a result.

There were several things that were discussed during the meeting:

• Highlighting OSTree commits as the delivered artifact

It would be nice if we can start shipping media that reflects what ostree version or commit is baked into this media. This would help us highlight what ostree content was embedded as well as start getting people to think of OSTree as the real deliverable vs the combination of the rpms as the deliverable.

• If we change the compose ID - what about Multi-Arch?

If we start to try to make the compose id match the version of the OSTree then we have to be careful in multi-arch scenarios where we may want to embed content from different arch trees and create media from these different trees. We have to make sure the arch trees all have synced versions. It was noted during the meeting that if we decide to couple the creation of OSTrees with the creation of the images then this is not a problem as we can generate all the arch ostrees and the images with the same OSTree version.

• pungi compose ids are inflexible

Pungi is somewhat limited in the compose IDs it can produce because of assumptions that we will follow and NVR model. During the meeting we decided that we might be able to adopt a model where N='Fedora Atomic' V='Fedora Version' and R=OSTree Version_0. One example would be: Fedora-Atomic-26-26.20170220.0_0.

• Getting rid of bodhi creation of ostrees

It has been identified quite a few times that we would like to unify the processes that create ostrees within Fedora. We currently have pungi and fedmsg-atomic-composer (kicked off by bodhi runs). We would like to only have ostree's get created by pungi, even if that means that bodhi calls pungi somehow, it would be better to have a single code path and set of configs that is consulted to create the ostrees. The problem is that I don't believe this is a high priority for anyone, we need to sort out if this is a high priority so that we can avoid confusion here. This is also a blocker for multiarch. See https://github.com/fedora-infra/bodhi/issues/1182.

• Coupling ostree creation with image creation

Currently in our process we create an ostree and then some time later we create images that pick up the latest ostree commits during the image creation process. We could continue using the current model but it may behoove us to start creating the ostrees and the images at the same time.

Identified Action Items

1. We can work on patches to pungi to accept an ostree version as input and know what to do with it. This would be a version that would be input for image creation, not necessarily for ostree tree compose creation. i.e. build a qcow image for ostree version 25.100 that is in the ostree repo. Assumes the ostree version already exists.
2. We can work on patches to pungi to that can determine what the ostree version should be and set that during ostree tree compose time. See https://pagure.io/pungi/pull-request/575
3. We need to provide to releng a script that can be run so they can "detect" what ostree version to specify as a compose id (I believe this assumes we keep ostree/image creation decoupled)
4. Determine priority of having bodhi call pungi to create ostrees
5. We need to determine what we want the OSTree version to look like for Fedora 26 (right now the atomic WG proposal is $majorversion.$year$month$day.$serial 26.20170320.0. Please comment in https://pagure.io/atomic-wg/issue/229
6. Figure out if a compose id like Fedora-Atomic-26-26.20170220.0_0 is possible and if anything breaks as a result.