Re: [Hudson] Clerezza builds seem to be failing to finish
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
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
Re: Hudson access for non-PMC member
On Fri, Jan 29, 2010 at 10:24 AM, Tim Ellison wrote: >> 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. +1 > Or reducing/removing the responsibility of the "Hudson admin team" and > making these 'real' ASF Infra managed machines. +1 /niklas
Re: Hudson access for non-PMC member
On Fri, Jan 29, 2010 at 09:24, Tim Ellison wrote: >> 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. +1 >> 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. True. >> 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 ;) 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. 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. --j.
Hudson machines admin (was: Re: Hudson access for non-PMC member)
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
Re: [Hudson] Clerezza builds seem to be failing to finish
We were having problem with some NullPointerExceptions in Hudson (sent a mail earlier on this list). Now I tried changing maven version, manually starting abuild might have killed an ongoing one, but I never purposely killed a build. Cheers, reto On Fri, Jan 29, 2010 at 10:08 AM, Tim Ellison wrote: > 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 > >
Adding the Sonar plugin to Hudson
Hi, I had a few spare moments so I set up a Sonar instance at http://sonar.zitting.name/ (to be moved to Apache hardware later, see INFRA-2140 [1]) and I'm planning to install the Sonar plugin in Hudson and set up a test build job that uses this feature. The new plugin may require a Hudson restart. [1] https://issues.apache.org/jira/browse/INFRA-2140 BR, Jukka Zitting
