On Tue, 27 Nov 2018 at 09:59, Owen Taylor <otaylor@xxxxxxxxxx> wrote: > > 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 :-) Define what a compose is? Currently it is a word which covers a multitude of different processes and reasons for those processes. We can't 'fix' or even 'replace' or parallel them without actually knowing why someone duct taped this tool to that widget during a 2 am release window. If the definition of a compose is pull out all the packages from koji and put them together into a 'release' then your No IO is not possible. If the definitions is that it is every release target, then removing things makes those things not composes. [That is ok, it just means that when we call them jam making we know it covers what we want it to be versus what someone else expects a 'compose' to do.] > Owen > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx -- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
