Re: Hudson on Windows

[Tim Ellison]

> On Tue, Oct 6, 2009 at 10:59 AM, Gavin  wrote:
>> Niklas, you have volunteered to set up and maintain the Windows Hudson VM, I
>> would rather like to see another one or two offer to help maintain it also,
>> there is nothing worse for infra than a badly maintained and out of date
>> system and poorly managed VM. Not a reflection on you as I'm sure you will
>> do a wonderful job, but I don't want to put extra pressure on infra to help
>> keep this VM operational due to lack of enough oversight of the VM. You must
>> realise that the Windows VMs we are about to unleash at ASF will be Very
>> popular over the coming weeks and months.
>>
>> So if more volunteers show up to help Niklas, I'll create the VM and get
>> Windows on it ready to rock and roll.
> 
> I share your opinion on having multiple admins for this host
> (especially given the preference for a separate box). So, let's see if
> there are additional volunteers.

I'll volunteer to help admin the VM  (selfishly, since I'm also
interested in getting Harmony builds going on Hudson/Windows).

Having it as an available slave to the existing install master would be
the ideal from my pov.

Regards,
Tim

Hudson machine utilization

[Tim Ellison]

Just looking at the Hudson machine utilization at the moment.  There are
a number of jobs that are tied to particular machines in the queue, and
a number of (hadoop-labeled) machines that are committed to tied jobs only.

I realize that the machines are courteously donated etc, but is the
capacity being used effectively [1]?

In particular, would the Hadoop jobs be impacted if we reclassified an
existing slave as general usage, and more jobs as scheduable anywhere?

[1] e.g.
http://hudson.zones.apache.org/hudson/computer/hadoop1%20%28Ubuntu%29/load-statistics?type=hour

Regards,
Tim

Re: Hudson machine utilization

[Tim Ellison]

On 28/Oct/2009 15:13, Justin Mason wrote:
> Well, we could move more load from hudson.zones to minerva first:
> 
> http://hudson.zones.apache.org/hudson/computer/%28master%29/load-statistics
> http://hudson.zones.apache.org/hudson/computer/minerva.apache.org%20%28Ubuntu%29/load-statistics
> 
> (wow, those are good graphs!)

Why do you say to do that first?

At least there are times when Minerva is using both its executors.
However, it looks like we could get by with half the current number of
the Hadoop labeled machines without impacting anything.

http://hudson.zones.apache.org/hudson/label/Hadoop/load-statistics?type=hour

> We certainly should embark on a program of persuading projects to
> schedule their jobs on both Linux and Solaris, though, to do that

Maybe we can just define a useful set of labels to sets of nodes and
encourage people to tie builds to them rather than specific machines.

Regards,
Tim


> On Wed, Oct 28, 2009 at 14:48, Tim Ellison  wrote:
>> Just looking at the Hudson machine utilization at the moment.  There are
>> a number of jobs that are tied to particular machines in the queue, and
>> a number of (hadoop-labeled) machines that are committed to tied jobs only.
>>
>> I realize that the machines are courteously donated etc, but is the
>> capacity being used effectively [1]?
>>
>> In particular, would the Hadoop jobs be impacted if we reclassified an
>> existing slave as general usage, and more jobs as scheduable anywhere?
>>
>> [1] e.g.
>> http://hudson.zones.apache.org/hudson/computer/hadoop1%20%28Ubuntu%29/load-statistics?type=hour
>>
>> Regards,
>> Tim
>>
>>
> 
> 
> 

Java updated on Minerva

[Tim Ellison]

FYI  I have updated the installed Java's available for builds on Minerva
as follows:

harmony-1.5-32 -> Apache Harmony M11 32-bit
harmony-1.5-64 -> Apache Harmony M11 64-bit

ibm-1.4-32 -> IBM Java SDK 1.4 SR13 FP2  32-bit
ibm-1.4-64 -> IBM Java SDK 1.4 SR13 FP2  64-bit
ibm 1.5-32 -> IBM Java SDK 1.5 SR10  32-bit
ibm 1.5-64 -> IBM Java SDK 1.5 SR10  64-bit
ibm 1.6-32 -> IBM Java SDK 1.6 SR6   32-bit
ibm 1.6-64 -> IBM Java SDK 1.6 SR6   64-bit

latest   -> Sun JDK 1.6.0 u17-b04  32-bit
latest1.4-> Sun JDK 1.4.2 u19-b04  32-bit
latest1.5-> Sun JDK 1.5.0 u22-b03  32-bit
latest1.5-32 -> Sun JDK 1.5.0 u22-b03  32-bit
latest1.5-64 -> Sun JDK 1.5.0 u22-b03  64-bit
latest1.6-> Sun JDK 1.6.0 u17-b04  32-bit
latest1.6-32 -> Sun JDK 1.6.0 u17-b04  32-bit
latest1.6-64 -> Sun JDK 1.6.0 u17-b04  64-bit

Any problems just shout.

Nige: I don't have access to the other Linux machines, can you copy them
across?

regards,
Tim

Re: Hudson machine utilization

[Tim Ellison]

On 05/Nov/2009 12:48, Niklas Gustavsson wrote:
> On Thu, Nov 5, 2009 at 12:18 AM, Nigel Daley  wrote:
>> We should also encourage projects (spam-assasin, ftpserver, struts, vysper,
>> xwork2) to move off of the Master hudson.zones.apache.org
> 
> As for FtpServer, we want our builds on Solaris (in addition to Linux
> on which we also builds). Would it be beneficial to provide a Hudson
> slave on a separate Solaris zone from where master is running?

Yes, I think it would be preferable.  Hudson is running on
lucene.zones.apache.org but I suggest we ask infra for a dedicated
Hudson zone rather than encourage individual projects to set up executors.

WDYT?

Regards,
Tim

Re: Hudson machine utilization

[Tim Ellison]

On 04/Nov/2009 23:18, Nigel Daley wrote:
> Tim, the Hadoop labeled machines were not donated to ASF.  Minerva,
> Vesta, and a couple others (used now for buildbot) were donated to ASF.

Ok, that is fair enough.

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

Regards,
Tim

[hudson] Killed misbehaving build "james-server-v2.3-m2/489"

[Tim Ellison]

Dear James devs,

FYI  I just killed a James server build on Hudson that has been running
for ~30hrs and was apparently stuck.

See
  http://hudson.zones.apache.org/hudson/job/james-server-v2.3-m2/489/

Regards,
Tim

Re: Hudson on Windows

[Tim Ellison]

On 12/Nov/2009 21:18, Gavin wrote:
> Hudson-win VM has been created, and Windows 2008 Server 64 bit installed. I
> have a few initial setup tasks to perform, should be ready later on
> today/tonight.

Good news, thanks Gavin.

Tim

Re: Hudson machine utilization

[Tim Ellison]

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

Re: Hudson machine utilization

[Tim Ellison]

On 16/Nov/2009 00:12, Justin Mason wrote:
> On Mon, Nov 16, 2009 at 00:01, Nigel Daley  wrote:
>> On Nov 16, 2009, at 1:59 AM, "Tim Ellison"  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
>>
> 
> 
> 

Re: Hudson machine utilization

[Tim Ellison]

On 16/Nov/2009 09:53, Jukka Zitting wrote:
> On Mon, Nov 16, 2009 at 1:12 AM, Justin Mason  wrote:
>> On Mon, Nov 16, 2009 at 00:01, Nigel Daley  wrote:
>>> 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
> 
> Do we have an easy way to get a list of all the jobs running on (vs.
> being explicitly bound to [1]) master? I volunteer to contact at least
> some of those projects and to help them migrate their builds.
> 
> [1] http://hudson.zones.apache.org/hudson/computer/(master)/

Not that I'm aware of, other than piecemeal by watching what is running
there via [2].  Hopefully there's enough info in groups of build names
to get a few projects at a time notified.

[2] http://hudson.zones.apache.org/hudson/computer/%28master%29/builds

Regards,
Tim

[hudson] Killed misbehaving build "Axis2/43"

[Tim Ellison]

Dear Axis2 devs,

FYI  I just killed an Axis2 build on Hudson that has been running for
~19hrs and was apparently stuck.

I have reconfigured the build to fail if it is apparently stuck (i.e. it
runs over 2hrs).

See
  http://hudson.zones.apache.org/hudson/job/Axis2/43/

Regards,
Tim

Re: Harmony-1.5-head-linux-x86_64-full-tests is filling the disk on minerva

[Tim Ellison]

On 22/Nov/2009 18:19, Jukka Zitting wrote:
> On Sun, Nov 22, 2009 at 5:44 PM, Jukka Zitting  
> wrote:
>> The workspace of the Harmony-1.5-head-linux-x86_64-full-tests build is
>> 1TB in size! Tim, can you look at that?
> 
> Builds started failing on minerva due to missing disk space, so I
> looked at this a bit deeper.
> 
> There was an xvfb-run.log file in the workspace of this Harmony build
> job that was 1.1TB in size. I removed this file, which should
> normalize the situation.

Thanks Jukka.  I've disabled the build until the cause is resolved.

Regards,
Tim

Policy for Hudson accounts

[Tim Ellison]

Just checking that the Wiki is accurate, and that I should reject this
request [1] as Uwe is not a PMC member.

Agreed?

[1] https://issues.apache.org/jira/browse/INFRA-2326

p.s. For extra credit, what is the rationale for requiring PMC
membership rather than, say, committership?

Regards,
Tim

Re: 2 hudson questions

[Tim Ellison]

On 23/Nov/2009 18:22, Andreas Andreou wrote:
> Tapestry recently started using hudson.zones.apache.org for its builds
> and here are 2 issues i've encountered:
> 1) I was told to pin the build to the vesta slave but it looks like it's
> missing maven - am i supposed to install maven for the hudson user
> on my own ? I can certainly do that, just want to make sure it's ok
> to do so (for now, i've just configured the builds to use the master node)
> 2) Is anyone running selenium tests from those hudson slaves? Our
> builds do include such tests, and it'd be great to have them running but
> right now i see a "Failed to start new browser session:
> java.lang.RuntimeException: Firefox 3 could not be found in the path!"
> error message... So, again, what should be the best course of
> action in order to go forward with this?
> 
> fyi, i've also sent an email about issue 1) to hud...@hudson.zones.apache.org
> but i never got any feedback - is there another list i should send this to?

Andreas,

Please direct Hudson questions to builds@apache.org

Regards,
Tim

Re: Hudson solaris slave is down

[Tim Ellison]

On 24/Nov/2009 07:30, Bhuvaneswaran A wrote:
> Looks like the lucene.zones.apache.org is down. Thus, the slave
> process in hudson.zones.apache.org is not running. Result: all jobs
> tied to solaris node (ex: [1]) are in pending state.
> 
> -bash-3.00$ cat /home/hudson/hudson/slave-lucene.zones.apache.org\
> \(Solaris\ 10\).log
> [11/24/09 07:00:38] Launching slave agent
> $ ssh lucene.zones.apache.org
> /export/home/hudson/tools/java/latest/bin/java -jar
> /export/home/hudson/hudson-slave/slave.jar
> ssh: connect to host lucene.zones.apache.org port 22: Connection timed out
> Unable to launch the slave agent for lucene.zones.apache.org (Solaris 10)
> java.io.EOFException: unexpected stream termination
> at hudson.remoting.Channel.(Channel.java:336)
> at hudson.remoting.Channel.(Channel.java:270)
> at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:286)
> at hudson.slaves.CommandLauncher.launch(CommandLauncher.java:111)
> at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:178)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
> at java.lang.Thread.run(Thread.java:619)
> 
> Can someone fix lucene.zones.apache.org, thus jobs tied to solaris
> node hudson.zones.apache.org will run? Thanks.
> 
> Note: If this is not the right forum to report these issues, pardon my
> ignorance. Please let me know the right forum where i can raise these
> issues.
> 
> [1] 
> http://hudson.zones.apache.org/hudson/view/subversion/job/subversion-trunk-solaris/

Yep, this is a known issue.  The node is marked as off-line at the
moment since the host machine has suffered a disk failure and is
awaiting repair.

The lucene.zones.apache.org Solaris zone is hosted on helios.apache.org.
 When it is back up Hudson will be restarted.  News about expected outage
time etc. is posted on the monitoring page [1] in the "Scheduled Host
Downtime" panel.

[1] http://monitoring.apache.org/status/

Regards,
Tim

Re: Hudson password reset

[Tim Ellison]

On 24/Nov/2009 09:48, Kristian Waagan wrote:
> Hello build team,
> 
> I'm sorry, but I seem to have forgotten my Hudson password (my username
> is 'kristwaa').
> For some reason I considered Hudson less secure regarding password
> storage, and chose a brand new password for my account there.

Good idea, the password is stored in plain text on the hudson machine,
so it is viewable by a number of people.

> Then I went on vacation and now I'm unable to log in again...
> 
> BTW: I also sent a mail about resetting my password to hudson at hudson
> dot zones dot a.o a week back or so.
> 
> 
> Sorry for the trouble,

You have mail!


Tim

Re: Harmony-1.5-head-linux-x86_64-full-tests is filling the disk on minerva

[Tim Ellison]

On 22/Nov/2009 18:59, Tim Ellison wrote:
> On 22/Nov/2009 18:19, Jukka Zitting wrote:
>> On Sun, Nov 22, 2009 at 5:44 PM, Jukka Zitting  
>> wrote:
>>> The workspace of the Harmony-1.5-head-linux-x86_64-full-tests build is
>>> 1TB in size! Tim, can you look at that?
>> Builds started failing on minerva due to missing disk space, so I
>> looked at this a bit deeper.
>>
>> There was an xvfb-run.log file in the workspace of this Harmony build
>> job that was 1.1TB in size. I removed this file, which should
>> normalize the situation.
> 
> Thanks Jukka.  I've disabled the build until the cause is resolved.

Just a heads-up that we've not figured out the cause, and without some
log messages it's hard to see what was causing such growth.  I'm going
to re-run a single build and try to capture a smaller log (before things
get out of hand).

Regards,
Tim

Re: 2 hudson questions

[Tim Ellison]

On 23/Nov/2009 18:22, Andreas Andreou wrote:
> Tapestry recently started using hudson.zones.apache.org for its builds
> and here are 2 issues i've encountered:
> 1) I was told to pin the build to the vesta slave but it looks like it's
> missing maven - am i supposed to install maven for the hudson user
> on my own ? I can certainly do that, just want to make sure it's ok
> to do so (for now, i've just configured the builds to use the master node)

I see Maven on there, in /home/hudson/tools/maven

Are you defining a Hudson maven build, or trying to invoke mvn directly?

> 2) Is anyone running selenium tests from those hudson slaves?

Sorry, don't know.

> Our builds do include such tests, and it'd be great to have them
> running but right now i see a "Failed to start new browser session: 
> java.lang.RuntimeException: Firefox 3 could not be found in the
> path!" error message... So, again, what should be the best course of 
> action in order to go forward with this?

Do you have an idea of what you need?  I have zero experience of
selenium, but if it needs to drive a UI then I assume you'll need Xvfb
[1] etc.

> fyi, i've also sent an email about issue 1) to hud...@hudson.zones.apache.org
> but i never got any feedback - is there another list i should send this to?

That should have worked.  I've added myself and Jukka to that alias so
hopefully somebody will see it; though the response might just be to
post here though 


[1] Word to the wise, the Xvfb package dependencies appear to be a bit
lacking, you also need to install a rendering engine or else the log
file gets a bit big {ahem} :-)

Regards,
Tim

Re: Policy for Hudson accounts

[Tim Ellison]

On 24/Nov/2009 14:54, Justin Mason wrote:
> On Mon, Nov 23, 2009 at 16:46, Tim Ellison  wrote:
> 
>> Just checking that the Wiki is accurate, and that I should reject this
>> request [1] as Uwe is not a PMC member.
>>
>> Agreed?
>>
>> [1] https://issues.apache.org/jira/browse/INFRA-2326
>>
>> p.s. For extra credit, what is the rationale for requiring PMC
>> membership rather than, say, committership?
>>
> 
> That's right.
> 
> The reason PMC membership is required is because we allow Hudson users
> access to a command-line.  However, this may be changing, but for now it's
> still the case.

Ok, it just seems strange that we'll give people accounts while
committers in the incubator [1], but when they graduate they are no
longer eligible to apply.

[1] wiki: "a member of a PMC or an Incubator project"

Regards,
Tim

Re: AW: Policy for Hudson accounts

[Tim Ellison]

On 24/Nov/2009 17:37, Jan Matèrne wrote:
>> Ok, it just seems strange that we'll give people accounts while
>> committers in the incubator [1], but when they graduate they are no
>> longer eligible to apply.
>>
>> [1] wiki: "a member of a PMC or an Incubator project"
> 
> I think the idea is, that all (?) committers of an incubator project
> become PMC member if the project passes the incubation phase?

Usually the PPMC -> PMC, so I'm not sure that is the argument.

> But should be edit the wiki and explain why PMC membership is required?

Sure, once there is a reasonable explanation to be given .

Maybe PMC or PPMC membership should be required?

Regards,
Tim

Re: Hudson accounts and PMCs

[Tim Ellison]

On 24/Nov/2009 20:29, Grant Ingersoll wrote:
> Per https://issues.apache.org/jira/browse/INFRA-2326, is it possible
> for a PMC to designate committers who are allowed hudson access?

Earlier [1]
On 24/Nov/2009 14:54, Justin Mason wrote:
> The reason PMC membership is required is because we allow Hudson users
> access to a command-line.  However, this may be changing, but for now
> it's still the case.

I don't know what changes are being considered, but for now it would
appear to be PMC or Incubator membership only.

[1] In message <6c399e450911240654g7ceefd54s83feeb60fe1b4...@mail.gmail.com>

Regards,
Tim

Re: Hudson accounts and PMCs

[Tim Ellison]

On 25/Nov/2009 18:46, Justin Mason wrote:
> On Wednesday, November 25, 2009, Tim Ellison  wrote:
>> On 24/Nov/2009 20:29, Grant Ingersoll wrote:
>>> Per https://issues.apache.org/jira/browse/INFRA-2326, is it possible
>>> for a PMC to designate committers who are allowed hudson access?
>> Earlier [1]
>> On 24/Nov/2009 14:54, Justin Mason wrote:
>>> The reason PMC membership is required is because we allow Hudson users
>>> access to a command-line.  However, this may be changing, but for now
>>> it's still the case.
>> I don't know what changes are being considered, but for now it would
>> appear to be PMC or Incubator membership only.
> 
> I have previously judged PPMC membership as acceptable, fwiw .

Unless somebody objects I'll update the wiki
from "Verify the requestor is a member of a PMC or
  an Incubator project"
to   "Verify the requestor is a member of a PMC or
  an Incubator project PPMC"

Regards,
Tim

Hudson nodes + labels

[Tim Ellison]

Here's a proposal for tweaking the Hudson nodes usage.  It's not much of
a change and hopefully reflects what is happening already, project
specific resources run tied project jobs, and general purpose nodes are
labeled with OS identifiers for those that care.  Comments welcome.

Label: 
  Master : tied jobs only

Label: Lucene
  Lucene : tied jobs only (for Lucene project)

Label: Solaris10
   : any job

Label: Ubuntu
  Minerva : any job
  Vesta   : any job

Label: Hadoop
  hadoop1-8 : tied jobs only (for Hadoop project)

Label: Win2008
   : any job


Jobs should be encouraged to specify node requirements as generally as
possible, i.e. 'any node' before a node type (via label) before a
specific node (via name).

We then try to reduce load on Master by generalizing jobs away from the
master node unless they need to run there, e.g for config purposes.

AIUI
  is requested by INFRA-2360
  is awaiting new disks for nyx, Gavin is looking
  at alternatives now.

Regards,
Tim

Re: Hudson nodes + labels

[Tim Ellison]

On 04/Dec/2009 08:47, Jukka Zitting wrote:
> Hi,
> 
> On Fri, Dec 4, 2009 at 9:41 AM, Tim Ellison  wrote:
>> Here's a proposal for tweaking the Hudson nodes usage.  It's not much of
>> a change and hopefully reflects what is happening already, project
>> specific resources run tied project jobs, and general purpose nodes are
>> labeled with OS identifiers for those that care.  Comments welcome.
> 
> +1 Sounds good.
> 
> It would be good if we documented better what tools (and versions) are
> available on all nodes and on all nodes with a given label. For
> example the PDFBox site build requires a recent version of Forrest,
> which I've installed on Minerva and the Hudson master. I should make
> that available (and document it's availability) on all nodes where
> PDFBox may get built.

Yep.  Unless you have a better idea I'll create pages on the general
wiki, and link to them from the Hudson page [1].

[1] http://wiki.apache.org/general/Hudson

Regards,
Tim

[Fwd: failure notice]

[Tim Ellison]

Heads-up to axis-dev, you need to let Hudson post to the list.

Regards,
Tim

 Original Message 
Subject: failure notice
Date: 16 Dec 2009 18:53:50 -
From: mailer-dae...@apache.org
To: hud...@hudson.zones.apache.org

Hi. This is the qmail-send program at apache.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

:
Sorry, only subscribers may post. If you are a subscriber, check to be
sure you are sending from your subscribed address. (#5.7.2)

--- Below this line is a copy of the message.

Return-Path: 
Received: (qmail 36058 invoked by uid 99); 16 Dec 2009 18:53:50 -
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Dec 2009 18:53:50 +
X-ASF-Spam-Status: No, hits=-2.6 required=5.0
tests=AWL,BAYES_00
X-Spam-Check-By: apache.org
Received: from [140.211.11.106] (HELO hudson.zones.apache.org)
(140.211.11.106)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Dec 2009 18:53:47 +
Received: from hudson.zones.apache.org (localhost [127.0.0.1])
by hudson.zones.apache.org (8.13.8+Sun/8.13.8) with ESMTP id 
nBGIrP4W000523
for ; Wed, 16 Dec 2009 13:53:25 -0500 (EST)
Date: Wed, 16 Dec 2009 18:53:25 + (UTC)
From: Apache Hudson Server 
To: axis-...@ws.apache.org
Message-ID:
<21730574.14831260989605224.javamail.hud...@hudson.zones.apache.org>
Subject: =?UTF-8?Q?Hudson_build_became_unstable:_Axis2_=C2=BB_Ap?=
 =?UTF-8?Q?ache_Axis2_-_JAXWS_Integration_Tests_#48?=
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

See

Re: Hudson on Windows

[Tim Ellison]

On 17/Dec/2009 11:40, Gavin wrote:
> Hi All,
> 
> Ok, Windows 2008 VM for Hudson is complete.
> 
> I have created accts for Tim Ellison and Niklas Gustavsson on the machine.
> I don't think anyone else has volunteered to admin the VM at this stage but
> correct me if I'm wrong.
> 
> I actually set up a Hudson instance on it too before realising that the
> machine is actually to be a slave, so feel free to kill the Hudson instance
> (just undeploy the WAR from tomcat should be enough, then stop tomcat
> service if its no longer needed.)
> 
> Tim, Niklas, I'll send your login info shortly, note that currently only
> Remote Desktop is enabled for logging in, if SSH is needed then cygwin+ssh
> should be installed, so let me know if I'm needed to do that.

Thanks Gavin.

I'll continue to set up the machine, and will put on some more Java
runtimes, etc.

Can you install the C/C++ development tools please (Visual Studio 2008)?
 While I have an MSDN account I don't think it covers general ASF usage.

Regards,
Tim

Re: Activate JNLP in Hudson

[Tim Ellison]

On 17/Dec/2009 21:03, Niklas Gustavsson wrote:
> we now got a Windows server ready for installing a Hudson slave. As
> there is a need to run GUI tests on the slave, the recommended way of
> running Hudson is to use JNLP.

Excuse my ignorance, but why does the method of invoking the Hudson
slave affect what type of code that slave can run?  The GUI tests are
run in a separate JVM forked from a script launched by Hudson...

> However, the port used for JNLP slaves is currently disabled on Hudson
> master.
> 
> Could we enable this port? If we do, we should probably firewall it so
> that only white listed clients can connect. Do we run a firewall on
> the Solaris server and if so, is there someone with the cycles to help
> us in getting this set up?

Solaris - .  It may be simpler to put ssh on the windows side
and have everything work the same way.

Regards,
Tim

MSDN license for Apache build machine

[Tim Ellison]

After discussion with infra folk on IRC, I'm going to use my MSDN
account (donated by MS to me for ASF work) to obtain the C/C++ compiler
to install on the new Hudson Windows build machine (hudson-win.apache.org).

Just posting the fact here so it appears on the mailing list for
posterity, in case people wondered where it came from.

Regards,
Tim

Re: MSDN license for Apache build machine

[Tim Ellison]

My MSDN subscription has expired, so it will have to wait.

On 18/Dec/2009 08:50, Tim Ellison wrote:
> After discussion with infra folk on IRC, I'm going to use my MSDN
> account (donated by MS to me for ASF work) to obtain the C/C++ compiler
> to install on the new Hudson Windows build machine (hudson-win.apache.org).
> 
> Just posting the fact here so it appears on the mailing list for
> posterity, in case people wondered where it came from.
> 
> Regards,
> Tim
> 

Re: MSDN license for Apache build machine

[Tim Ellison]

On 18/Dec/2009 09:56, Gavin wrote:
>> -Original Message-
>> From: Tim Ellison [mailto:t.p.elli...@gmail.com]
>> Sent: Friday, 18 December 2009 7:22 PM
>> To: infrastructure-...@apache.org; builds@apache.org
>> Cc: Garrett Serack
>> Subject: Re: MSDN license for Apache build machine
>>
>> My MSDN subscription has expired, so it will have to wait.
> 
> Hi Tim,
> 
> Mines still current, let me know what packages you need and I'll download
> them straight on to the build machine.

Thanks Gavin.  Can you please grab the VisualStudio 2008 professional
image [1,2] and leave it on the server for me, then send me the license
key.  Thanks.

> I believe renewals will start again in January so make sure to email Garrett
> with your details (see the post on committers@ list from Tuesday.)

Yep, I'm on the list.


[1] en_visual_studio_2008_professional_x86_dvd_x14-26326.iso
[2] http://tinyurl.com/y9ls9lp

Regards,
Tim

>> On 18/Dec/2009 08:50, Tim Ellison wrote:
>>> After discussion with infra folk on IRC, I'm going to use my MSDN
>>> account (donated by MS to me for ASF work) to obtain the C/C++ compiler
>>> to install on the new Hudson Windows build machine (hudson-
>> win.apache.org).
>>> Just posting the fact here so it appears on the mailing list for
>>> posterity, in case people wondered where it came from.
>>>
>>> Regards,
>>> Tim
>>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 9.0.716 / Virus Database: 270.14.109/2567 - Release Date:
>> 12/18/09 11:02:00
> 
> 

Re: MSDN license for Apache build machine

[Tim Ellison]

On 18/Dec/2009 12:38, Gavin wrote:
>> From: Tim Ellison [mailto:t.p.elli...@gmail.com]
>> Thanks Gavin.  Can you please grab the VisualStudio 2008 professional
>> image [1,2] and leave it on the server for me, then send me the license
>> key.  Thanks.
> 
> Hi Tim, it's in your downloads folder. No key to download to you should be
> good to go.

Thanks Gavin.  Done

c:\>cl
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08
for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]


Regards,
Tim

Java installed on Windows box

[Tim Ellison]

Niklas,

FYI the Windows Hudson machine now has a variety of Java's on it.

Regards,
Tim


C:\hudson\tools\java>dir
 Volume in drive C has no label.
 Volume Serial Number is E40F-CEC0

 Directory of C:\hudson\tools\java

12/18/2009  03:40 PM  .
12/18/2009  03:40 PM  ..
12/18/2009  03:39 PM  harmony-5.0-jdk-32
12/18/2009  02:51 PM  ibm-java-sdk-60-win-i386
12/18/2009  02:29 PM  ibm-java-sdk-60-win-x86_64
12/18/2009  02:33 PM  ibm-java2-sdk-50-win-i386
12/18/2009  02:32 PM  ibm-java2-sdk-50-win-x86_64
12/18/2009  02:33 PM  ibm-sdk-j9wa64-142p-win64-amd64
12/18/2009  02:53 PM  ibm-sdk-n142p-win32-x86
12/18/2009  03:22 PM  jdk1.5.0_22-32
12/18/2009  03:09 PM  jdk1.5.0_22-64
12/18/2009  03:17 PM  jdk6_17-32
12/18/2009  03:23 PM  jdk6_17-64
12/18/2009  02:56 PM latest-1.4-32
[C:\hudson\tools\java\ibm-sdk-n142p-win32-x86]
12/18/2009  02:56 PM latest-1.4-64
[C:\hudson\tools\java\ibm-sdk-j9wa64-142p-win64-amd64]
12/18/2009  02:49 PM latest-1.5-32
[C:\hudson\tools\java\ibm-java2-sdk-50-win-i386]
12/18/2009  02:55 PM latest-1.5-64
[C:\hudson\tools\java\ibm-java2-sdk-50-win-x86_64]
12/18/2009  03:01 PM latest-1.6-32
[C:\hudson\tools\java\ibm-java-sdk-60-win-i386\sdk]
12/18/2009  03:02 PM latest-1.6-64
[C:\hudson\tools\java\ibm-java-sdk-60-win-x86_64\sdk]
   0 File(s)  0 bytes
  19 Dir(s)  24,934,055,936 bytes free

Re: Stuck build

[Tim Ellison]

The builds report they are running on the master, but I can't kill them
either.

I'm going to recycle the master node.

Regards,
Tim

On 21/Dec/2009 08:41, Felix Meschberger wrote:
> Hi all,
> 
> There seem to be two stuck builds for the sling-trunk-1.6 build which I
> seem not to be able to kill:
> 
> 
> http://hudson.zones.apache.org/hudson/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/212/
> 
> http://hudson.zones.apache.org/hudson/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/211/
> 
> 
> Both are said to be running on minverva, yet minerva states it is not
> running anything (not sure whether that is really true, though) ...
> 
> Would it be possible to forcibly kill them ? Thanks alot.
> 
> Regards
> Felix
> 

Re: Stuck build

[Tim Ellison]

All looking good again now.

Regards,
Tim

On 21/Dec/2009 13:26, Felix Meschberger wrote:
> Ok, thanks.
> 
> Regards
> Felix
> 
> On 21.12.2009 14:14, Tim Ellison wrote:
>> The builds report they are running on the master, but I can't kill them
>> either.
>>
>> I'm going to recycle the master node.
>>
>> Regards,
>> Tim
>>
>> On 21/Dec/2009 08:41, Felix Meschberger wrote:
>>> Hi all,
>>>
>>> There seem to be two stuck builds for the sling-trunk-1.6 build which I
>>> seem not to be able to kill:
>>>
>>>
>>> http://hudson.zones.apache.org/hudson/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/212/
>>>
>>>
>>> http://hudson.zones.apache.org/hudson/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.launchpad.testing/211/
>>>
>>>
>>>
>>> Both are said to be running on minverva, yet minerva states it is not
>>> running anything (not sure whether that is really true, though) ...
>>>
>>> Would it be possible to forcibly kill them ? Thanks alot.
>>>
>>> Regards
>>> Felix
>>>
>>
> 

Re: Hudson slave on Windows now up and running

[Tim Ellison]

On 22/Dec/2009 13:10, Niklas Gustavsson wrote:
> On Mon, Dec 21, 2009 at 9:46 AM, Niklas Gustavsson  
> wrote:
>> Right, I'm still struggling with getting Hudson run in the automatic
>> way we're aiming for. Will let you all know when it's done.
> 
> The Hudson slave on the Windows server is now up and running.
> FtpServer build successfully. I tried to run the SVN build, but it
> failed on not finding /bin/bash, at which time I gave up :-)
> 
> For the time being, it's probably worth treating this slave as in
> beta. I'm sure we will make further improvements to it. Some additonal
> information:
> The server is a Windows 2008 server. For now, the slave only runs
> builds tied to the label "Windows". It got some various JDKs, Maven
> and Ant installations (similar to the Ubuntu slaves). It also got
> Visual Studio 2008 installed, including the C/C++ compiler.
> 
> Also, let us know if there is any additional software that needs to be
> installed on the server.

FYI I renamed the node from "hudson-win.apache.org" to
"hudson-win.apache.org (Windows 2008)" in keeping with the current
naming convention [1].

The rename was not so smooth, and required restarting Hudson.  I took
the opportunity to update the install to Hudson version 1.338.  Please
shout if there are any problems.

[1] I am responsible for misnaming it in the first place.

Regards,
Tim

Minerva tmp filling up

[Tim Ellison]

FYI I just deleted a whole bunch of temporary Hudson files from Minerva
/tmp, which was near full.

A list of the files in there is available for those that are interested
in ~tellison/tmplist.gz

Many of the files in there were named plan*.xml and were (are?) being
created at a fair rate of knots.  I took an example of one of these
files into ~tellison/plan1000800580185122757.xml

I'll monitor the situation for a while.

Regards,
Tim

Summarily killing stuck builds

[Tim Ellison]

FYI

I am continuing to kill builds that run for long periods without making
progress (e.g. [1]).

In each case, I also go into the build configuration and set the flag to
kill stuck builds after 120 mins.

It would be helpful if people set this timeout to a reasonable value for
 their project when creating new builds.

[1] Recent stuck builds:
http://hudson.zones.apache.org/hudson/job/Synapse%20-%201.3%20-%20SNAPSHOT/186/
http://hudson.zones.apache.org/hudson/job/Synapse%20-%20Trunk/1595/
http://hudson.zones.apache.org/hudson/job/HBase-Patch/1052/

Regards,
Tim

Re: Wtr.: Build failed in Hudson: PDFBox-trunk #441

[Tim Ellison]

On 06/Jan/2010 01:14, Aristedes Maniatis wrote:
> On 6/01/10 4:35 AM, Jukka Zitting wrote:
>> The Hudson configuration was recently changed to allow unbound build
>> jobs to execute not only on the master node but also on the minerva
>> and vesta slaves.
> 
> Yes, that change affected Cayenne as well since we had a special config
> file only present on one server. Perhaps an email could be sent to this
> list when these sort of changes are implemented?

There was support, and no objections when the proposal was made back in
early December [1] to make these changes.

I apologise for not notifying the list when I started implementing them.
 If that plan won't work for anyone, please let me know.  Note that you
may get scheduled on the Windows box too in the future.

> Also, would it be possible to have some sort of replication to
> synchronise files between the various build clients? Perhaps rsync from
> the master pushing out changes to all the slaves. As a start, the hudson
> home directory would be useful (and sufficient for Cayenne).

That would be cool.  There are still many manual tasks involved with
maintaining the Hudson machines.

[1]
http://mail-archives.apache.org/mod_mbox/www-builds/200912.mbox/%3c4b18cb43.8050...@gmail.com%3e

Regards,
Tim

Standard tool locations

[Tim Ellison]

We currently have a number of tools (e.g. JDKs, Ant, Maven, etc) defined
globally, in the 'Manage Hudson' configuration page.

Some are already a bit dubious, being declared as "on Ubuntu only", so
not really global at all.  Now we have a Windows client the paths are
totally wrong there, so specifying a build to use 'latest' is not going
to work.

I think the only option is to push the tool location definitions down to
individual nodes.  That will require some duplication across the Ubuntu
nodes, but will allow us to specify the actual tools available on a
node, and the correct paths for Windows.

WDYT?  Any better option?

Regards,
Tim

Re: Standard tool locations

[Tim Ellison]

On 06/Jan/2010 11:15, Aristedes Maniatis wrote:
> On 6/01/10 9:56 PM, Tim Ellison wrote:
>> We currently have a number of tools (e.g. JDKs, Ant, Maven, etc) defined
>> globally, in the 'Manage Hudson' configuration page.
>>
>> Some are already a bit dubious, being declared as "on Ubuntu only", so
>> not really global at all.  Now we have a Windows client the paths are
>> totally wrong there, so specifying a build to use 'latest' is not going
>> to work.

I should correct this, since we can override the 'latest' locations.  So
we would just 'push down' the platform specific tools to the specific nodes.

>> I think the only option is to push the tool location definitions down to
>> individual nodes.  That will require some duplication across the Ubuntu
>> nodes, but will allow us to specify the actual tools available on a
>> node, and the correct paths for Windows.
>>
>> WDYT?  Any better option?
> 
> Will that work on parameterised builds? [1]

Don't know -- I'm guessing that the parameter choices will be limited to
those that are declared in the global configurations.  We can try with a
single JDK version and see if you can use it in a parameterized build.

Regards,
Tim

> And as I think I emailed before, 'maven (latest)' is already quite old,
> so any improvements here will certainly help.
> 
> 
> 
> [1] eg. http://hudson.zones.apache.org/hudson/job/Cayenne-trunk/
> 
> 

Re: Windows slave and MSSQL server

[Tim Ellison]

On 06/Jan/2010 11:20, Aristedes Maniatis wrote:
> Now that we have a Windows Hudson slave, would it be possible to install
> Microsoft SQL server on that machine as well? The Cayenne project wants
> just a single database there which will be used for testing as part of
> the junit test suite run on Hudson. It will be extremely low load and
> take up negligible disk space (other than the installation of the MS SQL
> server itself).
> 
> I'm sorry I have no Windows skills so I can't help with the setup, but
> I'm assuming you just double click on some installer and go through a 30
> step wizard.

Sure.  Please open an INFRA JIRA ticket.  Once Gav has downloaded the
ASF-licensed ISO image I will install it.

Regards,
Tim

Re: Minerva tmp filling up

[Tim Ellison]

On 27/Dec/2009 19:29, Tim Ellison wrote:
> FYI I just deleted a whole bunch of temporary Hudson files from Minerva
> /tmp, which was near full.
> 
> A list of the files in there is available for those that are interested
> in ~tellison/tmplist.gz
> 
> Many of the files in there were named plan*.xml and were (are?) being
> created at a fair rate of knots.  I took an example of one of these
> files into ~tellison/plan1000800580185122757.xml
> 
> I'll monitor the situation for a while.

Minerva's /tmp is up to 1.4G again.

Still lots of plan*.xml files containing references to hadoop (not
pointing any fingers!)  Anybody know what is creating these?

Here's a snippet...



 
  
   
b

 
  org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe
 
 
  org.apache.hadoop.mapred.TextInputFormat
 
 

org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat
 
 
  
 
 
  
   
name
t2
   

Re: Windows slave and MSSQL server

[Tim Ellison]

On 06/Jan/2010 23:56, Gav... wrote:
>> -Original Message-
>> From: Tim Ellison [mailto:t.p.elli...@gmail.com]
>> Sent: Wednesday, 6 January 2010 9:29 PM
>> To: builds@apache.org
>> Subject: Re: Windows slave and MSSQL server
>>
>> On 06/Jan/2010 11:20, Aristedes Maniatis wrote:
>>> Now that we have a Windows Hudson slave, would it be possible to
>> install
>>> Microsoft SQL server on that machine as well? The Cayenne project
>> wants
>>> just a single database there which will be used for testing as part
>> of
>>> the junit test suite run on Hudson. It will be extremely low load and
>>> take up negligible disk space (other than the installation of the MS
>> SQL
>>> server itself).
>>>
>>> I'm sorry I have no Windows skills so I can't help with the setup,
>> but
>>> I'm assuming you just double click on some installer and go through a
>> 30
>>> step wizard.
>> Sure.  Please open an INFRA JIRA ticket.  Once Gav has downloaded the
>> ASF-licensed ISO image I will install it.
> 
> I've done that now, Enterprise and Developer Editions, not sure which was
> better.

I installed the developer edition.  It required an upgrade to Visual
Studio 2008 SP1, so I did that too.  As always, if there are any
problems please shout.

Ari also asked for the JDBC drivers to be installed.  They are
downloaded and put into c:\hudson\tools [1].

As requested, I've created a database called "cayenne_test" with owner
rights granted to a new "cayenne" user.  I'll send Ari the password.

> I notice now that we have 10-15GB of downloaded ISOs and other stuff, with a
> 40GB drive this doesn't leave much.

FYI the disk space is down to 9Gb now.

> So, I should probably add more space to the VM.
> 
> I'll need to stop the VM at some point and add a 2nd Drive to put the ISOs
> etc onto
> Or see about extending the current drive and expanding C to fill the space.
> 
> Not sure which would be better (or both), I'll probably do this over the
> weekend.

ack.

[1] In particular add the following to your build classpath
c:\hudson\tools\sqljdbc_2.0\enu\sqljdbc4.jar

Regards,
Tim

Re: Root access to vesta

[Tim Ellison]

On 11/Jan/2010 12:11, Andreas Andreou wrote:
> I'm interested in installing firefox and xvfb
> in a hudon client (vesta)
> in order to run selenium/browser tests
> 
> How to get root access?

Open a JIRA for project 'Infrastructure' and component 'Hudson' [1] to
request adding those installs.  If you want to help own the wish list
then you need to volunteer for infra duties [2].

[1] http://issues.apache.org/jira/browse/INFRA
[2] http://www.apache.org/dev/infra-volunteer.html

Regards,
Tim

Re: Stepping down as Hudson Admin

[Tim Ellison]

Understood Nige, thanks for the work you put in helping to establish the
build system. Good luck in your new ventures.

Regards,
Tim

On 11 Jan 2010 19:55, "Nigel Daley"  wrote:

Justin, Tim, Giri, and Jukka (Hudson Admins),

I've had some changes in my personal and work life that require me to step
back from some of my extra responsibilities -- unfortunately this is one of
them.  After 3 years, I'm stepping down as Hudson Admin for Apache and
signing off these lists.  Contact me directly if you need something.  FWIW,
Giri works with me so I'll never be that far away.  Giri can serve as
point-of-contact if there are any issues with the Y! donated/hosted machines
(minerva, vesta, etc).

It's been a fun 3 years administering the Lucene-become-Apache Hudson
instance.  Many thanks to Justin for joining me early on in this and the
rest of you for carrying the butler forward in providing this important
service!

Cheers,
Nige

Re: Root access to vesta

[Tim Ellison]

I'll take a look...

On 19/Jan/2010 09:57, Ulrich Stärk wrote:
> Is there anything I can help with to get this resolved?
> 
> Cheers,
> 
> Uli
> 
> On 13.01.2010 16:58 schrieb Ulrich Stärk:
>> Done.
>>
>> https://issues.apache.org/jira/browse/INFRA-2436
>>
>> Cheers,
>>
>> Uli
>>
>> On 11.01.2010 15:02 schrieb Tim Ellison:
>>> On 11/Jan/2010 12:11, Andreas Andreou wrote:
>>>> I'm interested in installing firefox and xvfb
>>>> in a hudon client (vesta)
>>>> in order to run selenium/browser tests
>>>>
>>>> How to get root access?
>>>
>>> Open a JIRA for project 'Infrastructure' and component 'Hudson' [1] to
>>> request adding those installs. If you want to help own the wish list
>>> then you need to volunteer for infra duties [2].
>>>
>>> [1] http://issues.apache.org/jira/browse/INFRA
>>> [2] http://www.apache.org/dev/infra-volunteer.html
>>>
>>> Regards,
>>> Tim
> 

Re: Hudson workspace visibility

[Tim Ellison]

On 12/Jan/2010 23:03, Aristedes Maniatis wrote:
> Do we want to make the workspace visible to anonymous users? Will that
> introduce too much load or leak confidential information? I think not on
> both counts.

I agree.  Fixed.

Regards,
Tim

> This came up because Hudson sends emails out to public lists with links
> that would be useful for committers to follow. For example:
> 
>  
> http://cayenne.markmail.org/search/#query:list%3Aorg.apache.cayenne.commits+page:1+mid:v27h6bwxuilwn63y+state:results
> 
> 
> 
> 
> Cheers
> Ari
> 
> 

Re: Minerva tmp filling up

[Tim Ellison]

On 06/Jan/2010 11:35, Tim Ellison wrote:
> On 27/Dec/2009 19:29, Tim Ellison wrote:
>> FYI I just deleted a whole bunch of temporary Hudson files from Minerva
>> /tmp, which was near full.
>>
>> A list of the files in there is available for those that are interested
>> in ~tellison/tmplist.gz
>>
>> Many of the files in there were named plan*.xml and were (are?) being
>> created at a fair rate of knots.  I took an example of one of these
>> files into ~tellison/plan1000800580185122757.xml
>>
>> I'll monitor the situation for a while.
> 
> Minerva's /tmp is up to 1.4G again.
> 
> Still lots of plan*.xml files containing references to hadoop (not
> pointing any fingers!)  Anybody know what is creating these?

Minerva's /tmp is still filling up with lots of junk, so I have
installed tmpreaper to clear out files left in /tmp longer than five days.

Don't put anything precious in there.

Regards,
Tim

Re: [Hudson] Derby-trunk_suites.All

[Tim Ellison]

ack - thanks for the heads-up.

Regards,
Tim

On 21/Jan/2010 16:50, Kristian Waagan wrote:
> Hi all Hudson users,
> 
> I have set up a job running the Derby test suite on Ubuntu (minerva,
> vesta), producing test coverage results with Clover. This will be the
> first full run, so things may go wrong...
> On my machines the suites typically finish in between 2 - 3 hours, so
> I'm grabbing the long-running job lock. I plan to run this once per week
> or maybe every other week.
> My test run (with a much smaller test suite) generated around half a gig
> of Clover data, so I hope it won't grow too big now.
> 
> If the job takes too long, or eats up too much resources, feel free to
> kill it and disable it. I would appreciate if you send me a note
> (private or here) telling my why the job got killed.
> I'll check in on the status tomorrow morning (in about 15 hours).
> 
> 
> Regards,

Re: Hudson access for non-PMC member

[Tim Ellison]

On 27/Jan/2010 11:26, Justin Mason wrote:
> Hi Philip --
> it's purely because the user accounts on the Hudson machines have
> quite a lot of privileges.

Anything much more significant than people's privileges via their
people.a.o accounts?

> Personally I'm open to the idea of making an exception if the AVRO PMC
> call for it, and assuming none of the other Hudson admins are against
> it.

Not against it, but if there is a flood of new account requests from
committers I'd like to examine whether we can roll those machines into
the existing infra routines.

Regards,
Tim

Re: [Hudson] Clerezza builds seem to be failing to finish

[Tim Ellison]

On 29/Jan/2010 00:13, sebb wrote:
> There is currently a Clerezza build stuck waiting to finish.
> 
> The project status for Clerezza shows a couple of builds tha
> apparently never finished.
> 
> Looks like a bug in Hudson?
> 
> Perhaps someone wants to have a look before trying to kill the current build?

I looked, but there wasn't much to see.
The builds have been killed.

Thanks,
Tim

Re: Hudson access for non-PMC member

[Tim Ellison]

On 28/Jan/2010 12:46, Gav... wrote:
>> -Original Message-
>> From: Tim Ellison [mailto:t.p.elli...@gmail.com]
>> Sent: Thursday, 28 January 2010 2:04 AM
>> To: builds@apache.org
>> Subject: Re: Hudson access for non-PMC member
>>
>> On 27/Jan/2010 11:26, Justin Mason wrote:
>>> Hi Philip --
>>> it's purely because the user accounts on the Hudson machines have
>>> quite a lot of privileges.
>> Anything much more significant than people's privileges via their
>> people.a.o accounts?
>>
>>> Personally I'm open to the idea of making an exception if the AVRO
>> PMC
>>> call for it, and assuming none of the other Hudson admins are against
>>> it.
>> Not against it, but if there is a flood of new account requests from
>> committers I'd like to examine whether we can roll those machines into
>> the existing infra routines.
> 
> What has been talked about in the past, to the Hudson admin team, is 
> restricted
> access to Hudson Admins ONLY on the main Hudson Master box. This is going to 
> be
> implemented real soon now and those not in the Hudson Admin Team will have 
> their
> accounts removed.
> 
> Regarding the slave machines, Minverva/Vesta , only those PMC members and 
> approved
> Committers (approved by their PMC if they are not PMC Members) that need shell
> accounts will get one. All accounts will need to login using an SSH key as 
> password
> logins will also be disabled. If you have an account on Minerva/Vesta please 
> ensure
> you have a pub key installed and in use as we will switch to this system soon.
> 
> Rather than seeing 500+ accounts on these machines I would rather see as few 
> as 
> possible, with those having accounts helping out the maintenance and 
> configurations
> for all projects and not just their own.

Agreed.  There is a steady stream of requests for accounts, and while
I'm happy to enable people to make progress on their project tasks, we
are building a potential problem for administering all those users.

> I've seen here and elsewhere maintenance become a nightmare for machines with 
> too many
> accounts, too many people doing configurations for their projects which 
> overwrite or
> overrule configurations for other projects, folks upgrading stuff which makes 
> tests
> useless for certain projects because they depended on the older version etc.

... and just the day to day aspects of creating accounts, resetting
passwords, etc. etc.  Which is why I called for rolling these machines
into the regular ASF Infra routines if we choose to go down that route.

> It may seem a pain for some, not being able to just log in and do as they 
> like, but I
> would rather they asked instead for things to be done, and those things be 
> done by a
> few volunteers, such as is the case for the majority of Infra machines. This 
> will make
> maintaining and upgrading and keeping secure the machines a whole lot easier, 
> and those
> that volunteer to look after the machines (not just their own project 
> interests) will
> get to know the machines, where things are, what can and can not be 
> upgraded/replaced
> etc. Minverva/Vesta are in need of patching as a minimum and dist-upgrade 
> preferable
> considering the recent cve releases this past couple of weeks. We need people 
> that
> can perform these Operating System level upgrades and patches, and know what 
> to do if
> any of that breaks stuff for projects.

Yep.  I see no significant difference here with the regular business of
infra.  Can Minerva/Vesta/Hudson-Win be wholly adopted by infra for
administration?

> So, I'm certainly -1 on continuing down this track of giving shell account to 
> anyone
> who asks for it, it's just not workable and not sensible. 

Agreed.

> I am absolutely +1 on Hudson Admin Team maintaining these boxes and giving 
> out shell
> accounts to the few PMC members that really need it, and also expanding out 
> the 
> Hudson Admin Team if necessary to add a very few more folks that will 
> maintain all
> aspects of the machines for the benefit of all projects.

Or reducing/removing the responsibility of the "Hudson admin team" and
making these 'real' ASF Infra managed machines.

I don't have the time (or skills!) of the dedicated infra folk here, and
while I know I can call on you and Philip to help out if things go
wrong, better to have the machines properly managed in the first place.

Regards,
Tim

Hudson machines admin (was: Re: Hudson access for non-PMC member)

[Tim Ellison]

On 29/Jan/2010 10:24, Justin Mason wrote:
> On Fri, Jan 29, 2010 at 09:24, Tim Ellison  wrote:
>>> I am absolutely +1 on Hudson Admin Team maintaining these boxes and giving 
>>> out shell
>>> accounts to the few PMC members that really need it, and also expanding out 
>>> the
>>> Hudson Admin Team if necessary to add a very few more folks that will 
>>> maintain all
>>> aspects of the machines for the benefit of all projects.
>> Or reducing/removing the responsibility of the "Hudson admin team" and
>> making these 'real' ASF Infra managed machines.
>>
>> I don't have the time (or skills!) of the dedicated infra folk here, and
>> while I know I can call on you and Philip to help out if things go
>> wrong, better to have the machines properly managed in the first place.
> 
> The danger I see is that neither Hudson admins [*], nor Infra, have
> the bandwidth to administer all the random bits of build platform
> software required by the range of products in the ASF.
> 
> (*: well, ok, me ;)

Me too, and as Gavin wrote, there will always be the opportunity for
PMC-blessed people to have accounts so they can look after installed
software packages required by build.

I was referring to the admin of the OS itself, such as ensuring the
patches are up to date, repartitioning the disks, noticing anomalies in
usage, and (heaven forbid) dealing with security breaches.

I'm happy to do my part to keep Hudson running because I use it too, but
I'd also like to hack on Harmony code, and I've seen the time and skill
the infra team invest in the other apache.org machines -- I can't do
that for these.

> As Uwe noted earlier in the thread:
> 
> '- Updating lucene's private SVN tools for the new lucene rev-based
> backwards branch (sparse checkout)'
> 
> '- Upgrading hudson's clover version for our new coverage reports
> (that work correct with backwards branch)'
> 
> 'You haven’t seen our IRC conversation between Mike and me where we
> did something like "human remote control" when changing our build
> scripts and so on. Something like "tell me whats in dir xyz", "hmm, ok
> then we have to Ah before tell me if solaris has a toolxy
> installed!", "yes", "ah then we can do pqrs first and tar this there".
> Funny, but worked, but took a day :-)'
> 
> Those are all tasks where SSH access is either required, or greatly
> simplifies the task.

I expect that today, many of these accounts are unnecessary, since we
ask people to apply for an OS account in the same breath as a Hudson
account.  Many build system users only need Hudson logins.

> by the way I fully agree that we can lock down the Hudson master box.
> It's just the build slaves that are still in question.

Who administers the zones?  Does each PMC ensure their zone is well behaved?

Regards,
Tim

[Fwd: Service alert: minerva.apache.org/SSH is CRITICAL]

[Tim Ellison]

FYI

minerva is down at the moment.

I'm trying to raise some help from Giri to reinstate it.

Regards,
Tim

 Original Message 
Subject: Service alert: minerva.apache.org/SSH is CRITICAL
Date: Tue,  2 Feb 2010 19:35:52 + (UTC)
From: nag...@monitoring.apache.org
To: telli...@apache.org

*** ASF Nagios ***

Notification Type: PROBLEM
Host: minerva.apache.org
Address: 67.195.138.8
Service: SSH
State: CRITICAL
Info: CRITICAL - Socket timeout after 10 seconds

Date/Time: Tue Feb 2 19:35:52 UTC 2010

Re: time/ntp on minerva

[Tim Ellison]

On 04/Feb/2010 15:04, Mark Hindess wrote:
> The time on minerva is now out by almost five minutes.  I know there
> were build problems previously when the time was out of sync so it might
> be worth fixing it before it becomes a problem.

Done, I fixed the time for both minerva and vesta.

> It was fixed previously by correcting the time manually.  However, the
> real solution is to allow the machine access to some/all of the time
> servers listed in /etc/ntp.conf so ntpd can do its job.

Yep, and I don't see why ntp is unable to reach outside.  Likely the VMs
are running in a restricted environment, so I've asked Giri if he can
shed some light on it from a hosting pov.

Regards,
Tim

Re: Hudson slave on minerva stuck

[Tim Ellison]

Fixed.

On 09/Mar/2010 21:00, Niklas Gustavsson wrote:
> Hi
> 
> Looks like the Hudson slave on minerva is stuck since a few days back.
> I'm not sure how to best restart it (just kill the processes?), could
> someone have a look at it?
> 
> /niklas
> 

Re: Hudson slave on minerva stuck

[Tim Ellison]

On 10/Mar/2010 09:16, Niklas Gustavsson wrote:
> On Wed, Mar 10, 2010 at 10:13 AM, Tim Ellison  wrote:
>> Fixed.
> 
> Out of curiosity and the possibility of helping out, how did you do it? :-)

There were quite a few zombie hudson builds running.  I simply killed
all the hudson processes and restarted the node from the master's UI.

Regards,
Tim

Re: Hudson slave on Vesta stuck

[Tim Ellison]

Fixed.

On 13/Mar/2010 19:59, Niklas Gustavsson wrote:
> Hi
> 
> Seems like the Hudson slave on Vesta is no longer responding. I killed
> (in the Hudson GUI) a CXF build that was stuck on the slave, but the
> slave no longer seems to accept new builds (nor does it respond to any
> communication from Hudson master).
> 
> /niklas
> 

Re: Account on Vesta and Minerva

[Tim Ellison]

Done.

On 13/Mar/2010 20:02, Niklas Gustavsson wrote:
> Hi
> 
> Would it be possible to get an account on Vesta and Minerva for
> helping out with Hudson admin chores? I'm pretty sure I don't have
> accounts there already, but if I do, a password reset would be in
> place :-)
> 
> /niklas
> 

Re: chemistry locked up on hudson master

[Tim Ellison]

On 15/Mar/2010 18:49, Patrick Hunt wrote:
> Could someone kill chemistry (> 6hrs runtime so far) on hudson master?

Done.

I also set a timeout for future "Chemistry - OpenCMIS - install" builds
to complete within 2hrs.

Regards,
Tim

Re: Setting up hudson-solaris

[Tim Ellison]

On 17/Mar/2010 19:43, Jukka Zitting wrote:
> Thanks to Gavin we now have a new general-purpose Solaris zone for use
> as a Hudson slave (see INFRA-2360).
> 
> I've just configured the zone as a Hudson slave and will be running a
> few builds there to see whether everything works OK. Once all the
> issues have been worked out, I'm planning to switch the zone from
> "Leave this machine for tied jobs only" to "Utilize this slave as much
> as possible" so that all untied jobs will start using the new slave.
> Later I'd like to do the opposite switch on the master node, and
> direct most of our Solaris builds to the new slave. This should
> release most of the pressure we're seeing on the Hudson master.


+1, let me know if I can help.

Tim

Re: Runaway Pig builds on hudson.

[Tim Ellison]

On 31/Mar/2010 16:41, Patrick Hunt wrote:
> Pig has been running on hudson for 9 and 11 hrs respectively:
> http://hudson.zones.apache.org/hudson/job/Pig-Patch-h7.grid.sp2.yahoo.net/261/
> 
> http://hudson.zones.apache.org/hudson/job/Pig-Patch-h8.grid.sp2.yahoo.net/273/
> 
> 
> I can't kill it from the console, could someone with greater access than
> I resolve this? My ZooKeeper builds are hung up waiting for Pig to finish.

Looks like hadoop7 and hadoop8 are unwell.  It will need a Y! admin to
intervene there.

Regards,
Tim

Re: Hudson Admins gone missing.

[Tim Ellison]

On 15/May/2010 22:34, Gav... wrote:
> Hi,
> 
> Where have all the Hudson Admins gone?
> 
> I have done and closed the last 10 Hudson Jira issues, there is another 5 to
> do currently.
> So no sign of a Hudson Admin looking at Jira issues for more than a month.
> 
> The builds@ lists is also barren, with only jukka and gkesavan making an
> appearance in over
> a month.
> 
> The current listed Hudson Admins are:
> 
> jmason, ndaley, jukka, gkesavan, tellison, ngn.
> 
> I think it's safe to remove ndaley from that list, who else is not going to
> be active anymore?
> 
> I won't be doing any more Hudson jira issues for the time being, I have
> other stuff to get on with
> now (which includes tightening up on the Hudson slaves themselves, you'll
> get notice soon)

Still here, but not much time to spend on this at the moment.  Should be
able to get back to resolving a few issues once things settle down again.

Thanks to all those that are keeping things running.

Regards,
Tim

hudson-win update

[Tim Ellison]

FYI I'm about to take down hudson-win for a while to install a number of
security patches.  Will be back on-line soon.

Regards,
Tim

Re: hudson-win update

[Tim Ellison]

On 23/Jul/2010 14:52, Tim Ellison wrote:
> FYI I'm about to take down hudson-win for a while to install a number of
> security patches.  Will be back on-line soon.

All clear.

Re: Minerva - Hudson slave will be down for a few days

[Tim Ellison]

On 06/Dec/2010 07:52, Gav... wrote:
> Ok,
> 
> Minerva (Slave 1) lost 2 disks, had to rebuilt from scratch.
> 
> It now has Hudson back on  nd some of the common packages.
> 
> Niklas has his admin acct back but I haven't added anyone else.
> 
> I see it is busy catching up on jobs now that were still tied to it.
> 
> We'll start again with the shell access as and when required.
> 
> Gav...

Can you confirm that Minerva has /home/hudson/tools/ant/latest defined?
 Harmony builds are failing (and I no longer have an account to go fix
things).

Thanks,
Tim

Re: Minerva - Hudson slave will be down for a few days

[Tim Ellison]

On 08/Dec/2010 12:54, Niklas Gustavsson wrote:
> On Wed, Dec 8, 2010 at 1:42 PM, Tim Ellison  wrote:
>> Can you confirm that Minerva has /home/hudson/tools/ant/latest defined?
>>  Harmony builds are failing (and I no longer have an account to go fix
>> things).
> 
> Yes, it should be:
> $ ls /home/hudson/tools/ant/latest
> bin  docs  etcfetch.xml  get-m2.xml  INSTALL  KEYS  lib  LICENSE
> NOTICE  README  WHATSNEW

The build seems to run ok if I use a job configuration of
  Ant Version: Ant (latest)
but not if I use
  Ant Version: (Default)

which produces
[harmony] $ ant bundle-src clean fetch-depends snapshot
FATAL: command execution failed.Maybe you need to configure the job to
choose one of your Ant installations?
java.io.IOException: Cannot run program "ant" (in directory
"/home/hudson/hudson-slave/workspace/Harmony-1.5-head-linux-x86_64/harmony"):
java.io.IOException: error=2, No such file or directory

Minerva should pick up the default tools locations.

Which installation of Ant is considered the "Default"?  Is it looking
for a system version on the path?

Regards,
Tim

Re: Minerva - Hudson slave will be down for a few days

[Tim Ellison]

On 08/Dec/2010 15:01, Niklas Gustavsson wrote:
> On Wed, Dec 8, 2010 at 3:52 PM, Tim Ellison  wrote:
>> Which installation of Ant is considered the "Default"?  Is it looking
>> for a system version on the path?
> 
> Sure looks like it.

It would be a good idea to set up a default as the 'latest'.

Could you also install libjpeg62-dev for me please, it's needed for a
Harmony build (there may be more, that's the first one it fell over).

Thanks,
Tim