+1.

On Dec 4, 2009, at 12: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.
>
> Label: <none>
>  Master : tied jobs only
>
> Label: Lucene
>  Lucene : tied jobs only (for Lucene project)
>
> Label: Solaris10
>  <new_node_1> : any job
>
> Label: Ubuntu
>  Minerva : any job
>  Vesta   : any job
>
> Label: Hadoop
>  hadoop1-8 : tied jobs only (for Hadoop project)
>
> Label: Win2008
>  <new_node_2> : 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
> <new_node_1> is requested by INFRA-2360
> <new_node_2> is awaiting new disks for nyx, Gavin is looking
>              at alternatives now.
>
> Regards,
> Tim
>

On Friday, December 4, 2009, Tim Ellison <t.p.ellison@gmail.com> wrote:
> On 04/Dec/2009 08:47, Jukka Zitting wrote:
>> Hi,
>>
>> On Fri, Dec 4, 2009 at 9:41 AM, Tim Ellison <t.p.ellison@gmail.com> 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.  Also it may be possible to define your own label like
'has-forrest', add that to the relevant hosts, and require that in yr
builds.



>
> [1] http://wiki.apache.org/general/Hudson
>
> Regards,
> Tim
>
>

-- 
--j.

On 04/Dec/2009 08:47, Jukka Zitting wrote:
> Hi,
> 
> On Fri, Dec 4, 2009 at 9:41 AM, Tim Ellison <t.p.ellison@gmail.com> 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

On Fri, Dec 4, 2009 at 9:41 AM, Tim Ellison <t.p.ellison@gmail.com> 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.

Big +1

/niklas

Hi,

On Fri, Dec 4, 2009 at 9:41 AM, Tim Ellison <t.p.ellison@gmail.com> 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.

BR,

Jukka Zitting

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: <none>
  Master : tied jobs only

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

Label: Solaris10
  <new_node_1> : any job

Label: Ubuntu
  Minerva : any job
  Vesta   : any job

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

Label: Win2008
  <new_node_2> : 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
 <new_node_1> is requested by INFRA-2360
 <new_node_2> is awaiting new disks for nyx, Gavin is looking
              at alternatives now.

Regards,
Tim

fwiw I am trying to sort out a Solaris Zone or VM for use as another Hudson
slave, hopefully wont be too much longer.

Gav...

> -----Original Message-----
> From: Bhuvaneswaran A [mailto:bhuvaneswaran@gmail.com]
> Sent: Thursday, 3 December 2009 4:13 AM
> To: builds@apache.org
> Subject: Re: Hudson: 2 executors in lucene (solaris10)
> 
> On Wed, Dec 2, 2009 at 11:35 PM, Nigel Daley <ndaley@yahoo-inc.com> wrote:
> > No, please don't do this.  It's for lucene subprojects.  We don't (yet)
> have
> > permission from Lucene PMC to run other builds on their zone.
> >
> > n.
> >
> > On Dec 2, 2009, at 10:01 AM, Bhuvaneswaran A wrote:
> >
> >> On Wed, Dec 2, 2009 at 1:47 PM, Bhuvaneswaran A <bhuvan@apache.org>
> wrote:
> >>>
> >>> Right now, the solaris slave lucene.zones.apache.org is configured to
> >>> execute 1 job at a time. This being the only Solaris node integrated
> >>> with Hudson, may i set it as 2, thus 2 Hudson jobs can run in
> >>> parallel?
> >>
> >> Unless anyone object I'll make it as "2" jobs for this solaris slave,
> >> lucene.zones.apache.org, on Thu, Dec 02 2009 @ 11am IST.
> 
> OK. I'll not change it. Thank you.
> 
> --
> Regards,
> Bhuvaneswaran A
> www.livecipher.com
> GPG: 0x7A13E5B0
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.708 / Virus Database: 270.14.87/2536 - Release Date: 11/30/09
> 17:31:00

On Wed, Dec 2, 2009 at 11:35 PM, Nigel Daley <ndaley@yahoo-inc.com> wrote:
> No, please don't do this.  It's for lucene subprojects.  We don't (yet) have
> permission from Lucene PMC to run other builds on their zone.
>
> n.
>
> On Dec 2, 2009, at 10:01 AM, Bhuvaneswaran A wrote:
>
>> On Wed, Dec 2, 2009 at 1:47 PM, Bhuvaneswaran A <bhuvan@apache.org> wrote:
>>>
>>> Right now, the solaris slave lucene.zones.apache.org is configured to
>>> execute 1 job at a time. This being the only Solaris node integrated
>>> with Hudson, may i set it as 2, thus 2 Hudson jobs can run in
>>> parallel?
>>
>> Unless anyone object I'll make it as "2" jobs for this solaris slave,
>> lucene.zones.apache.org, on Thu, Dec 02 2009 @ 11am IST.

OK. I'll not change it. Thank you.

-- 
Regards,
Bhuvaneswaran A
www.livecipher.com
GPG: 0x7A13E5B0

No, please don't do this.  It's for lucene subprojects.  We don't  
(yet) have permission from Lucene PMC to run other builds on their zone.

n.

On Dec 2, 2009, at 10:01 AM, Bhuvaneswaran A wrote:

> On Wed, Dec 2, 2009 at 1:47 PM, Bhuvaneswaran A <bhuvan@apache.org>  
> wrote:
>> Right now, the solaris slave lucene.zones.apache.org is configured to
>> execute 1 job at a time. This being the only Solaris node integrated
>> with Hudson, may i set it as 2, thus 2 Hudson jobs can run in
>> parallel?
>
> Unless anyone object I'll make it as "2" jobs for this solaris slave,
> lucene.zones.apache.org, on Thu, Dec 02 2009 @ 11am IST.
> -- 
> Regards,
> Bhuvaneswaran A
> www.livecipher.com
> GPG: 0x7A13E5B0

On Wed, Dec 2, 2009 at 1:47 PM, Bhuvaneswaran A <bhuvan@apache.org> wrote:
> Right now, the solaris slave lucene.zones.apache.org is configured to
> execute 1 job at a time. This being the only Solaris node integrated
> with Hudson, may i set it as 2, thus 2 Hudson jobs can run in
> parallel?

Unless anyone object I'll make it as "2" jobs for this solaris slave,
lucene.zones.apache.org, on Thu, Dec 02 2009 @ 11am IST.
-- 
Regards,
Bhuvaneswaran A
www.livecipher.com
GPG: 0x7A13E5B0

Right now, the solaris slave lucene.zones.apache.org is configured to
execute 1 job at a time. This being the only Solaris node integrated
with Hudson, may i set it as 2, thus 2 Hudson jobs can run in
parallel?

Thank you.
-- 
Regards,
Bhuvaneswaran A
www.livecipher.com
GPG: 0x7A13E5B0

> -----Original Message-----
> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
> Sent: Thursday, 26 November 2009 8:28 AM
> To: builds@apache.org
> Subject: Re: Hudson accounts and PMCs
> 
> On 25/Nov/2009 18:46, Justin Mason wrote:
> > On Wednesday, November 25, 2009, Tim Ellison <t.p.ellison@gmail.com>
> 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"

+1, thanks Tim, I like and agree with that.

Gav...

> 
> Regards,
> Tim

On 25/Nov/2009 18:46, Justin Mason wrote:
> On Wednesday, November 25, 2009, Tim Ellison <t.p.ellison@gmail.com> 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

On Wednesday, November 25, 2009, Tim Ellison <t.p.ellison@gmail.com> 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 .



> [1] In message <6c399e450911240654g7ceefd54s83feeb60fe1b41c9@mail.gmail.com>
>
> Regards,
> Tim
>
>

-- 
--j.

On 25/11/2009, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
>
>  On Tue, Nov 24, 2009 at 3:54 PM, Justin Mason <jm@jmason.org> wrote:
>  > The reason PMC membership is required is because we allow Hudson users
>  > access to a command-line.
>
>
> Essentially the PMC membership requirement is just an approximation to
>  limit accounts to only people who can be trusted with command-line
>  access.

Not entirely.

Granting Hudson access also means that the person can create lots of
Hudson jobs, potentially causing problems for other Hudson users.

Seems to me that the requirement for PMC membership may go some way to
ensuring that the person is more experienced.

>
>  Personally I'd be in favor of giving out Hudson web accounts to all
>  committers and limiting command line access only to administrators.

Disagree, see above.

>  There aren't that many cases where command line access really is
>  needed.

Agree, but IMO that's a separate issue.

>  BR,
>
>
>  Jukka Zitting
>

Hi,

On Tue, Nov 24, 2009 at 3:54 PM, Justin Mason <jm@jmason.org> wrote:
> The reason PMC membership is required is because we allow Hudson users
> access to a command-line.

Essentially the PMC membership requirement is just an approximation to
limit accounts to only people who can be trusted with command-line
access.

Personally I'd be in favor of giving out Hudson web accounts to all
committers and limiting command line access only to administrators.
There aren't that many cases where command line access really is
needed.

BR,

Jukka Zitting

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 <6c399e450911240654g7ceefd54s83feeb60fe1b41c9@mail.gmail.com>

Regards,
Tim

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

Maybe PMC or PPMC membership should be required?

Regards,
Tim

Per https://issues.apache.org/jira/browse/INFRA-2326, is it possible for a PMC to designate
committers who are allowed hudson access?

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

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


Jan

On 24/Nov/2009 14:54, Justin Mason wrote:
> On Mon, Nov 23, 2009 at 16:46, Tim Ellison <t.p.ellison@gmail.com> 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

On Mon, Nov 23, 2009 at 16:46, Tim Ellison <t.p.ellison@gmail.com> 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.

-- 
--j.

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 hudson@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 <g>


[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

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 <jukka.zitting@gmail.com> 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

Tim Ellison wrote:
> 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!

Thanks for the help, Tim :)


-- 
Kristian

> 
> 
> Tim

Hello,

I guess it's okay to create a new group in Hudson for Derby?
I'm trying out the Hudson plugin in NetBeans, and if there is no group 
for the builds you're interested in it seems you have to keep an eye on 
all builds in the instance. That's a waste of resources (assuming it's 
smart enough to only query for the groups being shown).

The Derby project has a test suite that takes between 2 - 4 hours to run 
(2.8 GHz dual core/CPU), and at times it can be a bit CPU and/or IO 
intensive. Most tests are single threaded, but there are a few that 
would keep more than one CPU busy as well. Run on a low-frequency 
CMT-machine the suite would take longer, and the toll on the IO 
subsystem would probably be higher than on the CPU.
I chose not to run this in Hudson, as it would block the other projects 
for a long time. The Derby jobs are currently tied to Solaris, but they 
can be run on any platform.

My questions:
 - is there enough resources to run the test suite in Hudson, say once a 
week?
   (this would allow us to get test coverage reports as well)
 - would it help if Derby requested a zone and "donated" (as Lucene has 
done) it to Hudson, or is the zones machine already saturated?

The Derby project is currently reasonably well covered outside of Apache 
infrastructure when it comes to testing, but that process is a lot more 
closed than it would be if run on Apache infrastructure. Compiling Derby 
and building the documentation in Hudson were the two first steps 
towards a more transparent process / community. I just want to provide a 
minimal level of services on ASF infrastructure, we'll still be 
dependent on external resources to cover our needs.


Regards,
-- 
Kristian

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

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

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.<init>(Channel.java:336)
>         at hudson.remoting.Channel.<init>(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

Hi,

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.<init>(Channel.java:336)
        at hudson.remoting.Channel.<init>(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/
-- 
Regards,
Bhuvaneswaran A
www.livecipher.com
GPG: 0x7A13E5B0

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

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

On 22/Nov/2009 18:19, Jukka Zitting wrote:
> On Sun, Nov 22, 2009 at 5:44 PM, Jukka Zitting <jukka.zitting@gmail.com> 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

Hi,

On Sun, Nov 22, 2009 at 5:44 PM, Jukka Zitting <jukka.zitting@gmail.com> 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.

BR,

Jukka Zitting

Hi,

The workspace of the Harmony-1.5-head-linux-x86_64-full-tests build is
1TB in size! Tim, can you look at that?

BR,

Jukka Zitting

Hi

/home is filled up on minerva and I'm not sure as to what can be deleted.

/niklas


---------- Forwarded message ----------
From: Apache Hudson Server <hudson@hudson.zones.apache.org>
Date: Sun, Nov 22, 2009 at 2:35 PM
Subject: Build failed in Hudson: vysper-trunk-jdk1.6-ubuntu #203
To: dev@mina.apache.org


See <http://hudson.zones.apache.org/hudson/job/vysper-trunk-jdk1.6-ubuntu/203/>

------------------------------------------
A SCM change trigger started this job
Building remotely on minerva.apache.org (Ubuntu)
Updating https://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk
ERROR: Failed to update
https://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk
org.tmatesoft.svn.core.SVNException: svn: Cannot write entries file
'<http://hudson.zones.apache.org/hudson/job/vysper-trunk-jdk1.6-ubuntu/ws/trunk/.svn/entries'>:
No space left on device
       at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
       at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
       at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:610)
       at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:273)
       at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:261)
       at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:266)
       at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1263)
       at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:820)
       at org.tmatesoft.svn.core.wc.SVNUpdateClient.update(SVNUpdateClient.java:558)
       at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:401)
       at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:217)
       at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:576)
       at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:543)
       at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2052)
       at hudson.remoting.UserRequest.perform(UserRequest.java:104)
       at hudson.remoting.UserRequest.perform(UserRequest.java:48)
       at hudson.remoting.Request$2.run(Request.java:236)
       at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
       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:886)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
       at java.lang.Thread.run(Thread.java:619)

Hey Gav,

On Thu, Nov 12, 2009 at 10:18 PM, Gavin <gavin@16degrees.com.au> 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.

Have you been able to finalize this?

/niklas

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

On Mon November 16 2009 11:23:42 am Nigel Daley wrote:
> I think anything currently *unbound* gets run on the master since it's
> the only 'slave' that isn't reserved for tied jobs (last I looked).

So would it make sense to "untick" that tick box for vesta and/or minerva? 

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

On Nov 16, 2009, at 3:52 PM, Tim Ellison wrote:

> On 16/Nov/2009 09:53, Jukka Zitting wrote:
>> On Mon, Nov 16, 2009 at 1:12 AM, Justin Mason <jm@jmason.org> wrote:
>>> On Mon, Nov 16, 2009 at 00:01, Nigel Daley <ndaley@yahoo-inc.com>  
>>> 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

I think anything currently *unbound* gets run on the master since it's  
the only 'slave' that isn't reserved for tied jobs (last I looked).

Nige