#742 order ostree installer before cloud image builds
Closed: Fixed 6 years ago Opened 6 years ago by walters.

We want to use the Atomic Host installer to build Atomic Host cloud images, but can't currently:

https://pagure.io/pungi-fedora/pull-request/296


The installer can only run once the ostree phase finishes, right? Or can they run at the same time?

The ISOs we build are like DVDs - they contain the content, so indeed must be run after the (rpm-)ostree phase. But strictly speaking that's not required by the model. This is the same distinction between "boot ISO" and "DVD".

But strictly speaking that's not required by the model.

I'm not sure what you're saying here. The way I see it we either have to serialize dependencies:

ostree -> ostree_installer -> cloud_image

which could be ok, but that also means that we'd have to block all cloud_images or find some way to granularly block only the atomic cloud images. It also means that we would add stage to the pipeline on this page: https://docs.pagure.org/pungi/phases.html

Hmm, that diagram can't be correct today can it? Since indeed the ostree goes into the ISO.

Are you saying that all cloud images are blocked by every installer completing? Pungi doesn't understand that e.g. the FAH installer is used to generate FAH images, and we don't need to wait for the Workstation installre?

Really big picture...I'm not sure how much sense the "big compose" idea makes sense as a thing generally. Why not just make each edition its own compose, then have an "Everything-and-Other" compose that has the random Fedora spins?

Even within that...what should really move faster is the ostree generation. Testing images derived from that is definitely useful but blocking any tests going until an ISO has been generated loses a lot of the point.

Anyways our goal in this issue should really be to ensure that we can use the FAH ISO for generating FAH cloud images, otherwise we lose the point of all of those optimizations.

Hmm, that diagram can't be correct today can it? Since indeed the ostree goes into the ISO.

I believe it is accurate. The OSTree phase is before OstreeInstaller (this is the phase that generates our ISO).

Are you saying that all cloud images are blocked by every installer completing? Pungi doesn't understand that e.g. the FAH installer is used to generate FAH images, and we don't need to wait for the Workstation installre?

I'm saying that all cloud images are blocked by OSTree phase completing. If we make it so that the Atomic* ImageBuilds need to go after OstreeInstaller then that might mean all ImabeBuilds wait on OstreeInstaller.

Really big picture...I'm not sure how much sense the "big compose" idea makes sense as a thing generally. Why not just make each edition its own compose, then have an "Everything-and-Other" compose that has the random Fedora spins?

i think generally I agree with you. but considering the actual 'compose' is expensive (i.e. lots of reading from NFS and creation of repos) it has made sense to put them together rather than tear them apart.

Even within that...what should really move faster is the ostree generation. Testing images derived from that is definitely useful but blocking any tests going until an ISO has been generated loses a lot of the point.

Anyways our goal in this issue should really be to ensure that we can use the FAH ISO for generating FAH cloud images, otherwise we lose the point of all of those optimizations.

Agreed. More complex dependency specification may help us here.

Pungi currently operates at the phase granularity, there's no way to express dependencies in finer detail. #743 switch the ostree installer phase to finished before image building starts, so it should make it possible to reuse the atomic boot.iso in the qcows.

I agree though that long term we should come up with a better way to do things.

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

6 years ago

Metadata Update from @lsedlar:
- Issue tagged with: 4.1.20

6 years ago

Login to comment on this ticket.

Metadata