On Sun, Jul 22, 2018 at 7:04 PM, Kevin Fenzi <kevin@xxxxxxxxx> wrote: > On 07/21/2018 02:54 PM, Andrew Lutomirski wrote: >>>>> On Jul 15, 2018, at 5:47 AM, Richard W.M. Jones <rjones@xxxxxxxxxx> wrote: >>>>> >>>>> On Fri, Jul 13, 2018 at 04:05:42PM +0200, Mikolaj Izdebski wrote: >>>>> On 07/12/2018 10:17 PM, Richard W.M. Jones wrote: >>>>> Does each build start with its own fresh VM? Do you care about the >>>>> data in that build VM if either qemu or the host crashes? If the >>>>> answers are 'Yes' and 'No' respectively to these questions then IMHO >>>>> this is the ideal situation for cache=unsafe. >>>> >>>> The answers are 'No' and 'Not much'. >>>> >>>> 1. VMs are installed once and are running for week/months until they are >>>> reinstalled. In the meantime guests and hosts are rebooted during >>>> routine maintenance, to apply updates. >>> >>> In this case my preferred advice would be: DO NOT use cache=unsafe. >>> >>> We've only tested scenarios for very short-lived build or temporary >>> VMs (for example when I was building RISC-V packages before we had >>> Koji, I used a script which created a VM per build and there it made >>> sense to use cache=unsafe). >>> >>> I do not think it's a good idea to be using this for VMs which are in >>> any way long-lived as there could be unforeseen side effects which I'm >>> not aware of and certainly have never tested. >>> >>>> 2. There would be no data loss in case of host or hypervisor crash. >>>> Worst case, if guest operating system was corrupted sysadmins would need >>>> to trigger VM install. >>> >>> Host crash => yes you'd definitely need to reinstall that VM. >>> >>> It's not a worst case, a host crash would near-definitely corrupt a VM >>> that was ignoring flush requests. It might even corrupt in an >>> undetectable way (eg. throwing away data while leaving metadata >>> intact). >> >> Would it make sense to boot the builders with -snapshot and >> cache=unsafe? After all, during normal operation, they don’t need to >> persist anything. > > I don't think thats at all worth it for a slight bit of build speed. > >> >> It might even be reasonable to reboot the VMs after every single build. > > Well, koji has no ability to do that currently, and note that some > builders can in fact be doing multiple builds at once, so you would need > to make sure all in progress builds were done and no new ones arrived, etc. > > There was a project a while back to make koji builders more dynamic (I > think by making them cloud instances), but I am not sure whatever > happened with it. I seem to remember there was discussion of replacing mock with docker containers as well, again I don't know what happened to that either. _______________________________________________ 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/message/JSIMJH2WWVQB7YAC7KPPBJ7YENRLJTFS/
