#260 work items to harmonize releng pungi/ostree artifact creation
Closed: Fixed 2 years ago Opened 3 years ago by dustymabe.

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.

OK. Some time later - an update on this ticket

  • Highlighting OSTree commits as the delivered artifact

We will be setting an ostree version that corresponds to
the pungi compose ID. See OSTREE_VERSION_FROM_LABEL_DATE_TYPE_RESPIN
in https://pagure.io/pungi/pull-request/592. We are already
using this for rawhide.

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

We are not planning to change the compose ID any longer. Additionally
with bodhi calling pungi we will be able to support multi-arch better.

  • pungi compose ids are inflexible

Still using the same compose ID as in the past so no issues here

  • Getting rid of bodhi creation of ostrees

planned and in progress: https://pagure.io/atomic-wg/issue/300

  • Coupling ostree creation with image creation

Since we are also planning to move mash to pungi we might as well
add image/ISO creation to pungi and have it do everything all at
the same time. This would mean we no longer have timing issues

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.

Done. https://pagure.io/pungi/pull-request/592

  1. 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

Same as above

  1. 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)

No need. Just use OSTREE_VERSION_FROM_LABEL_DATE_TYPE_RESPIN

  1. Determine priority of having bodhi call pungi to create ostrees

high :)

  1. 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

We will get 26.20170320.0

  1. Figure out if a compose id like Fedora-Atomic-26-26.20170220.0_0 is possible and if anything breaks as a result.

No Need

Metadata Update from @dustymabe:
- Issue tagged with: infra, releng

2 years ago

luckily most of this work has been completed. The move to have bodhi call pungi was done in: https://github.com/fedora-infra/bodhi/pull/1900

Closing this issue for now.

Metadata Update from @dustymabe:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata