A lot of discussion about improving the compose process seem to end up
with a "reality check" - that ideas have already been tried but don't
work because of requirements a) b) c) d). You can't have the pony, but
maybe if a lot of effort is put into it, you can have a faster rocking
horse.
If want to fundamentally improve the Fedora workflow we need compose
ponies, we can't just have rocking horses!
Perhaps it would make sense to leave the current 8-10 hour compose in
place for the forseeable future, and work on a new system in parallel
where the primary constraint is to be as fast as possible. Hopefully
most problems with the slow compose will get sorted out in the fast
composes, and the slow compose will become more reliable. Perhaps in a
distant future, we can make the new system do everything
I don't know what the system would look like exactly, but you could
imagine things like:
* Composed of several micro-composes (micro-compose-services?) to
avoid blocking on everything completing successfully.
* Able to do speculative composes for CI
* Either x86_64-only, or with decoupled architectures so that we can
throw x86_64 hardware (or cloud resources) at it, and make it super
fast.
* No IO /mnt/koji during the compose - having a big network share be
central to the process creates a performance bottleneck, makes it hard
to move to the cloud, and potentially adds a lot of "noise" to
figuring out what is going on where things are slow because of some
other entirely different thing is goin gon.
Add your own bullet points :-)
Owen