On 16/Nov/2009 00:12, Justin Mason wrote: > On Mon, Nov 16, 2009 at 00:01, Nigel Daley <nda...@yahoo-inc.com> wrote: >> On Nov 16, 2009, at 1:59 AM, "Tim Ellison" <t.p.elli...@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 >> > > >
