www-builds mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Mason ...@jmason.org>
Subject Re: Hudson machine utilization
Date Mon, 16 Nov 2009 00:12:06 GMT
On Mon, Nov 16, 2009 at 00:01, Nigel Daley <ndaley@yahoo-inc.com> wrote:
>
> Sent from my iPhone
>
> On Nov 16, 2009, at 1:59 AM, "Tim Ellison" <t.p.ellison@gmail.com> wrote:
>
>> On 14/Nov/2009 04:46, Nigel Daley wrote:
>>>>>
>>>>> I agree we should encourage folks to tie their linux builds to the
>>>>> "Ubuntu" label (which already exists), so both minerva and vesta get
>>>>> used.
>>>>>
>>>>> We should also encourage projects (spam-assasin, ftpserver, struts,
>>>>> vysper, xwork2) to move off of the Master hudson.zones.apache.org
>>>>
>>>> Why are minerva and vesta configured as "Leave this machine for tied
>>>> jobs only"?  I'd expect that setting for Master and Hadoop nodes, and
>>>> let the others pick up any job.
>>>
>>> That would be preferable, but for legacy reasons Vesta and Minerva are
>>> left for tied jobs.  This was because the Master was the only build node
>>> for 1.5+ years and had lots and lots of build on it when we then added
>>> Vesta and Minerva.  For compatibility reasons, we set it up as is.
>>>
>>> Suggestions on how to change this now?  How to migrate builds off
>>> Master?  Clearly the extremes are "rip the band-aid off -- builds start
>>> failing that try to run on Master" & "big project to contact build
>>> owners and push them to migrate".
>>
>> Just tie jobs to master that have dependencies there,
>
> How do we determine this for the 100+ jobs?

I'm assuming we can ask -- all Hudson users are supposed to be subbed
to infrastructure@ at least.  Also we can change the main site
banner....

--j.


>> and mark it for
>> tied jobs only, and let other jobs target labels if they have specific
>> OS/CPU requirements.
>>
>> I don't think anything is particularly 'broken' at the moment is it?  I
>> was just trying to understand the current set-up, and if we ask new jobs
>> to set up a bit differently we can prevent over burdening master while
>> leaving spare capacity elsewhere.
>>
>> Regards,
>> Tim
>
>



-- 
--j.

Mime
View raw message