Hey folks, just a quick openQA status update: both staging and prod are now running a recent git master build of openQA and os-autoinst (the -24 and -7 builds in the recently-submitted update). Also, qa14.qa has been added to prod as an extra worker box; it's currently hosting 10 workers, just over doubling our test capacity (wahay). It was used for the 20160415 Rawhide tests and they seemed to go fine, we'll keep an eye on things for the next few days.
Tim is hoping to free up another of those boxes for use as a worker soon; we could give both 'big iron' boxes to prod (=20 workers) and give all three old worker boxes to stg (=6 workers), or split it up some other way (e.g. give both servers one 'big iron' box and give all the old boxes to prod, which would be a 16/10 split). (It *is* possible to have one box act as a worker host for two openQA servers, but it could get tricky if the tests get out of sync between the two hosts, as sometimes happens, as the worker box just has one mount point of tests, so it's probably best to stick with each worker host box being dedicated to a server).
We could also look at going to single-CPU VMs; this is how SUSE runs, apparently. We ought to be able to up the worker count considerably if we do that.
On Mon, 2016-04-18 at 09:42 +0200, Jan Sedlak wrote:
We could also look at going to single-CPU VMs; this is how SUSE runs, apparently. We ought to be able to up the worker count considerably if we do that.
I thought that Anaconda would be unusably slow with single-core CPU.
I've always run my happyassassin.net workers with a single CPU and that's not noticeably the case; do you know that anaconda relies heavily on threading in some way? Does package installation even use threads? I would guess it couldn't, because of the importance of the ordering of the transactions...
qa-devel@lists.fedoraproject.org
-
Adam Williamson -
Jan Sedlak