
On Tue, Aug 07, 2012 at 01:24:40PM -0400, Robert Middleswarth wrote:
On 08/07/2012 09:40 AM, Ewoud Kohl van Wijngaarden wrote:
I agree with your concerns on the home based service for something this critical as a master. One solution could be to revamp the slave I provide into a master and use Roberts infra as slaves. It's a VM running on our production RHEV cluster and has sufficient HA. My suggestion was just a stop-gap - run it at Robert's for a few weeks until we get new datacenter-based hosting. Agreed I like your idea of revamping the slave to be the new master. That gets us running faster soonest. Then we can use Robert's hosts as slaves, and also bring up a dedicated box at a hosting facility to run multiple slaves. I don't. Jenkins master really needs to have the profile of a database server were the slaves don't need as much IO and can run fine on systems with limit IO. As a stop gap converting his slave to master might work but just like using the servers housed in my home is a stop gap I would put that in the same list. The limited IO we have seen from that VM would slow down everything just like
On 08/07/2012 12:49 PM, Karsten 'quaid' Wade wrote: the EC2 instance. Granted we don't need ssd raid 10 array in the box but a decent sata raid controller or even better a sas will allow faster builds and room for growth. But does it also need much random IO when it's just master and not building? I think that uploading the artifacts is mostly sequential IO where SATA does a good enough job. I'm convinced that if we transform my slave into a master who's just a master we will have more than enough
On Tue, Aug 07, 2012 at 01:06:55PM -0400, Robert Middleswarth wrote: performance to last us for quite a bit. What kind of storage does the box have? Remember the master is managing jobs so when several jobs finish at once they all are coping back there artifacts to the master. Although for the most
On 08/07/2012 01:13 PM, Ewoud Kohl van Wijngaarden wrote: part the jobs are sequential.
PS there are a few jobs it just makes since to run on master. Like the publishing one since it copies artifacts into a central folder and pushes them to www.ovirt.org.
Not sure of the exact configuration, but it's stored on one of our equallogic SATA SANs. It can't be worse than EC2, right ;)