www-builds mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Hudson machine utilization
Date Mon, 16 Nov 2009 08:31:10 GMT
On 16/Nov/2009 00:12, Justin Mason wrote:
> On Mon, Nov 16, 2009 at 00:01, Nigel Daley <ndaley@yahoo-inc.com> wrote:
>> 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....

Yep, like I say, I don't think things are especially broken at the
moment, I'm merely suggesting a soft approach to 'stop digging the hole'
before we are in too deep to get out of trouble.

Regards,
Tim

>>> 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
>>
> 
> 
> 

Mime
View raw message