You are viewing a plain text version of this content. The canonical link for it is here.
Posted to builds@apache.org by Philip Zeyliger <ph...@apache.org> on 2010/01/23 02:01:01 UTC
Hudson access for non-PMC member
Hi there,
I'd like to setup a Hudson build for the AVRO subproject of Hadoop.
The current policy is to only allow such accounts for PMC/PPMC
members. Might the policy be loosened to allow accounts for
committers or an exception be made?
Thanks,
-- Philip
Re: Hudson access for non-PMC member
Posted by Justin Mason <jm...@jmason.org>.
hi Uwe -- sorry for the lack of response at the time :( The same
would apply in your case, IMO.
On Wed, Jan 27, 2010 at 11:47, Uwe Schindler <us...@apache.org> wrote:
> Hi Justin,
>
> Grant Ingersoll and I were asking for the same before xmas and we also proposed that the Lucene PMC could vote for me to be added as a Hudson user. But we got no definitive response.
>
> It would be fine for me (only committer) to have such access as I currently fix and have fixed lots of probs in the Lucene Java build. Currently I have to ask another committer (Mike McCandless) to do the changes. We also added support for Clover 2.6.x to our Hudson builds.
>
> Uwe
>
> -----
> Uwe Schindler
> uschindler@apache.org
> Apache Lucene Java Committer
> Bremen, Germany
> http://lucene.apache.org/java/docs/
>
>> -----Original Message-----
>> From: jmason@gmail.com [mailto:jmason@gmail.com] On Behalf Of Justin
>> Mason
>> Sent: Wednesday, January 27, 2010 12:26 PM
>> To: builds@apache.org
>> Subject: Re: Hudson access for non-PMC member
>>
>> Hi Philip --
>> it's purely because the user accounts on the Hudson machines have
>> quite a lot of privileges.
>>
>> 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.
>>
>> --j.
>>
>> On Sat, Jan 23, 2010 at 01:01, Philip Zeyliger <ph...@apache.org>
>> wrote:
>> > Hi there,
>> >
>> > I'd like to setup a Hudson build for the AVRO subproject of Hadoop.
>> > The current policy is to only allow such accounts for PMC/PPMC
>> > members. Might the policy be loosened to allow accounts for
>> > committers or an exception be made?
>> >
>> > Thanks,
>> >
>> > -- Philip
>> >
>> >
>>
>>
>>
>> --
>> --j.
>
>
--
--j.
RE: Hudson access for non-PMC member
Posted by Uwe Schindler <us...@apache.org>.
Hi Justin,
Grant Ingersoll and I were asking for the same before xmas and we also proposed that the Lucene PMC could vote for me to be added as a Hudson user. But we got no definitive response.
It would be fine for me (only committer) to have such access as I currently fix and have fixed lots of probs in the Lucene Java build. Currently I have to ask another committer (Mike McCandless) to do the changes. We also added support for Clover 2.6.x to our Hudson builds.
Uwe
-----
Uwe Schindler
uschindler@apache.org
Apache Lucene Java Committer
Bremen, Germany
http://lucene.apache.org/java/docs/
> -----Original Message-----
> From: jmason@gmail.com [mailto:jmason@gmail.com] On Behalf Of Justin
> Mason
> Sent: Wednesday, January 27, 2010 12:26 PM
> To: builds@apache.org
> Subject: Re: Hudson access for non-PMC member
>
> Hi Philip --
> it's purely because the user accounts on the Hudson machines have
> quite a lot of privileges.
>
> 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.
>
> --j.
>
> On Sat, Jan 23, 2010 at 01:01, Philip Zeyliger <ph...@apache.org>
> wrote:
> > Hi there,
> >
> > I'd like to setup a Hudson build for the AVRO subproject of Hadoop.
> > The current policy is to only allow such accounts for PMC/PPMC
> > members. Might the policy be loosened to allow accounts for
> > committers or an exception be made?
> >
> > Thanks,
> >
> > -- Philip
> >
> >
>
>
>
> --
> --j.
Re: Hudson access for non-PMC member
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Wed, Jan 27, 2010 at 12:26 PM, Justin Mason <jm...@jmason.org> wrote:
> 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.
+1
BR,
Jukka Zitting
RE: Hudson access for non-PMC member
Posted by Uwe Schindler <us...@apache.org>.
> > that would be an option, but during our work, Mike and me only
> activated the "start new build" button in the GUI, everything else was
> and had to be done in the shell:
> > - 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)
> > - Killing stuck builds (to get a stack trace you have to send a
> SIGHUP to the stuck JVM first)
> >
>
> We can certainly get you access to the Lucene Zone as that is up to the
> Lucene PMC, as that is where Hudson always runs Lucene jobs. So, that
> plus Hudson UI access would likely solve most issues right?
Yes.
Re: Hudson access for non-PMC member
Posted by Grant Ingersoll <gs...@apache.org>.
On Jan 27, 2010, at 1:45 PM, Uwe Schindler wrote:
> Hi Grant,
>
> that would be an option, but during our work, Mike and me only activated the "start new build" button in the GUI, everything else was and had to be done in the shell:
> - 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)
> - Killing stuck builds (to get a stack trace you have to send a SIGHUP to the stuck JVM first)
>
We can certainly get you access to the Lucene Zone as that is up to the Lucene PMC, as that is where Hudson always runs Lucene jobs. So, that plus Hudson UI access would likely solve most issues right?
-Grant
RE: Hudson access for non-PMC member
Posted by Uwe Schindler <us...@apache.org>.
> - Updating lucene's private SVN tools for the new lucene rev-based
> backwards branch (sparse checkout)
By the way, that's related to https://issues.apache.org/jira/browse/INFRA-2442, we solved it with a private version extracted from the recent SVN stable branch solaris build, which is done in a workspace on lucene-zones :-)
As soon as this is fixed, we will change out ANT properties to use the "official" SVN client 1.6.x.
Uwe
RE: Hudson access for non-PMC member
Posted by Uwe Schindler <uw...@thetaphi.de>.
Approx 10 MB as of clover 2.6.3: http://repo2.maven.org/maven2/com/cenqua/clover/clover/2.6.3/
This or 2.6.2 is the version Lucene uses.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Gav... [mailto:gavin@16degrees.com.au]
> Sent: Thursday, January 28, 2010 1:22 PM
> To: builds@apache.org
> Subject: RE: Hudson access for non-PMC member
>
>
>
> > -----Original Message-----
> > From: Uwe Schindler [mailto:uschindler@apache.org]
> > Sent: Thursday, 28 January 2010 5:21 PM
> > To: builds@apache.org
> > Cc: 'Uwe Schindler'; gsiasf@gmail.com
> > Subject: RE: Hudson access for non-PMC member
> >
> > > > Upgrading hudson's clover version for our new coverage reports
> > (that
> > > work correct with backwards branch)
> > >
> > > With the new Apache specific license you can now commit the key
> into
> > > your svn repository and therefore you might not need to do anything
> > at
> > > the shell at all. That was my experience with the Cayenne project
> > when
> > > setting it up with maven.
> >
> > Yeah, I communicated this with Nick Pellow from Atlassian! But you
> have
> > to place the clover JAR file somewhere if using ANT not maven. We do
> > not want to have it in our repository, as it is rather large.
>
> Huh? The clover Jar I'm looking at is 1.71 MB
>
>
> Gav...
>
> > The other idea (not yet implemented) is to download the JAR into the
> > workspace from the ANT build script.
> >
> > For other things (get a stack trace of hung tests) you still need a
> > shell.
> >
> > Uwe
>
>
RE: Hudson access for non-PMC member
Posted by Uwe Schindler <us...@apache.org>.
Approx 10 MB as of clover 2.6.3: http://repo2.maven.org/maven2/com/cenqua/clover/clover/2.6.3/
This or 2.6.2 is the version Lucene uses.
Uwe
-----
Uwe Schindler
uschindler@apache.org
Apache Lucene Java Committer
Bremen, Germany
http://lucene.apache.org/java/docs/
> -----Original Message-----
> From: Gav... [mailto:gavin@16degrees.com.au]
> Sent: Thursday, January 28, 2010 1:22 PM
> To: builds@apache.org
> Subject: RE: Hudson access for non-PMC member
>
>
>
> > -----Original Message-----
> > From: Uwe Schindler [mailto:uschindler@apache.org]
> > Sent: Thursday, 28 January 2010 5:21 PM
> > To: builds@apache.org
> > Cc: 'Uwe Schindler'; gsiasf@gmail.com
> > Subject: RE: Hudson access for non-PMC member
> >
> > > > Upgrading hudson's clover version for our new coverage reports
> > (that
> > > work correct with backwards branch)
> > >
> > > With the new Apache specific license you can now commit the key
> into
> > > your svn repository and therefore you might not need to do anything
> > at
> > > the shell at all. That was my experience with the Cayenne project
> > when
> > > setting it up with maven.
> >
> > Yeah, I communicated this with Nick Pellow from Atlassian! But you
> have
> > to place the clover JAR file somewhere if using ANT not maven. We do
> > not want to have it in our repository, as it is rather large.
>
> Huh? The clover Jar I'm looking at is 1.71 MB
>
>
> Gav...
>
> > The other idea (not yet implemented) is to download the JAR into the
> > workspace from the ANT build script.
> >
> > For other things (get a stack trace of hung tests) you still need a
> > shell.
> >
> > Uwe
>
>
RE: Hudson access for non-PMC member
Posted by "Gav..." <ga...@16degrees.com.au>.
> -----Original Message-----
> From: Uwe Schindler [mailto:uschindler@apache.org]
> Sent: Thursday, 28 January 2010 5:21 PM
> To: builds@apache.org
> Cc: 'Uwe Schindler'; gsiasf@gmail.com
> Subject: RE: Hudson access for non-PMC member
>
> > > Upgrading hudson's clover version for our new coverage reports
> (that
> > work correct with backwards branch)
> >
> > With the new Apache specific license you can now commit the key into
> > your svn repository and therefore you might not need to do anything
> at
> > the shell at all. That was my experience with the Cayenne project
> when
> > setting it up with maven.
>
> Yeah, I communicated this with Nick Pellow from Atlassian! But you have
> to place the clover JAR file somewhere if using ANT not maven. We do
> not want to have it in our repository, as it is rather large.
Huh? The clover Jar I'm looking at is 1.71 MB
Gav...
> The other idea (not yet implemented) is to download the JAR into the
> workspace from the ANT build script.
>
> For other things (get a stack trace of hung tests) you still need a
> shell.
>
> Uwe
RE: Hudson access for non-PMC member
Posted by Uwe Schindler <us...@apache.org>.
> > Upgrading hudson's clover version for our new coverage reports (that
> work correct with backwards branch)
>
> With the new Apache specific license you can now commit the key into
> your svn repository and therefore you might not need to do anything at
> the shell at all. That was my experience with the Cayenne project when
> setting it up with maven.
Yeah, I communicated this with Nick Pellow from Atlassian! But you have to place the clover JAR file somewhere if using ANT not maven. We do not want to have it in our repository, as it is rather large.
The other idea (not yet implemented) is to download the JAR into the workspace from the ANT build script.
For other things (get a stack trace of hung tests) you still need a shell.
Uwe
Re: Hudson access for non-PMC member
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 28/01/10 5:45 AM, Uwe Schindler wrote:
> Upgrading hudson's clover version for our new coverage reports (that work correct with backwards branch)
With the new Apache specific license you can now commit the key into your svn repository and therefore you might not need to do anything at the shell at all. That was my experience with the Cayenne project when setting it up with maven.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
RE: Hudson access for non-PMC member
Posted by Uwe Schindler <us...@apache.org>.
Hi Grant,
that would be an option, but during our work, Mike and me only activated the "start new build" button in the GUI, everything else was and had to be done in the shell:
- 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)
- Killing stuck builds (to get a stack trace you have to send a SIGHUP to the stuck JVM first)
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 :-)
On the other hand, you can always configure a job that runs with the Hudson account and does a "rm -rf /hudsoninstalldir" in it - so where is the security?
Uwe
-----
Uwe Schindler
uschindler@apache.org
Apache Lucene Java Committer
Bremen, Germany
http://lucene.apache.org/java/docs/
> -----Original Message-----
> From: Grant Ingersoll [mailto:gsiasf@gmail.com] On Behalf Of Grant
> Ingersoll
> Sent: Wednesday, January 27, 2010 6:38 PM
> To: builds@apache.org
> Subject: Re: Hudson access for non-PMC member
>
> Perhaps there is an in-between here, too. Can't we give access to
> Hudson itself w/o giving access to the machine? That way, Uwe could
> run and configure the jobs (which is the most common task) w/o
> necessarily needing to deal w/ the machine level stuff.
>
> -Grant
>
> On Jan 27, 2010, at 11:04 AM, Tim Ellison wrote:
>
> > 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 access for non-PMC member
Posted by Justin Mason <jm...@jmason.org>.
yeah, that's an easy way to do it. +1
On Wed, Jan 27, 2010 at 17:38, Grant Ingersoll <gs...@apache.org> wrote:
> Perhaps there is an in-between here, too. Can't we give access to Hudson itself w/o giving access to the machine? That way, Uwe could run and configure the jobs (which is the most common task) w/o necessarily needing to deal w/ the machine level stuff.
>
> -Grant
>
> On Jan 27, 2010, at 11:04 AM, Tim Ellison wrote:
>
>> 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
>
>
>
--
--j.
Re: Hudson access for non-PMC member
Posted by Grant Ingersoll <gs...@apache.org>.
Perhaps there is an in-between here, too. Can't we give access to Hudson itself w/o giving access to the machine? That way, Uwe could run and configure the jobs (which is the most common task) w/o necessarily needing to deal w/ the machine level stuff.
-Grant
On Jan 27, 2010, at 11:04 AM, Tim Ellison wrote:
> 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
Hudson machines admin (was: Re: Hudson access for non-PMC member)
Posted by Tim Ellison <t....@gmail.com>.
On 29/Jan/2010 10:24, Justin Mason wrote:
> On Fri, Jan 29, 2010 at 09:24, Tim Ellison <t....@gmail.com> 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 access for non-PMC member
Posted by Justin Mason <jm...@jmason.org>.
On Fri, Jan 29, 2010 at 09:24, Tim Ellison <t....@gmail.com> 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.
Re: Hudson access for non-PMC member
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Fri, Jan 29, 2010 at 10:24 AM, Tim Ellison <t....@gmail.com> 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
Posted by Tim Ellison <t....@gmail.com>.
On 28/Jan/2010 12:46, Gav... wrote:
>> -----Original Message-----
>> From: Tim Ellison [mailto:t.p.ellison@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
Posted by "Gav..." <ga...@16degrees.com.au>.
> -----Original Message-----
> From: Tim Ellison [mailto:t.p.ellison@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.
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.
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.
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.
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.
Gav...
>
> Regards,
> Tim
Re: Hudson access for non-PMC member
Posted by Tim Ellison <t....@gmail.com>.
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 access for non-PMC member
Posted by Philip Zeyliger <ph...@cloudera.com>.
Thanks for your responses, and the interesting thread. I'm asking the
Hadoop PMC to petition this list on my behalf.
Having used Hudson quite a bit recently internally to my company, it is
sometimes tricky to debug the configuration of the build without shell
access. That said, a ticket-based system like Gav... proposes would work
too. It's easy enough to run Hudson locally to prepare Hudson's XML
configuration files and have those managed via SVN.
Cheers,
-- Philip
On Wed, Jan 27, 2010 at 3:26 AM, Justin Mason <jm...@jmason.org> wrote:
> Hi Philip --
> it's purely because the user accounts on the Hudson machines have
> quite a lot of privileges.
>
> 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.
>
> --j.
>
> On Sat, Jan 23, 2010 at 01:01, Philip Zeyliger <ph...@apache.org> wrote:
> > Hi there,
> >
> > I'd like to setup a Hudson build for the AVRO subproject of Hadoop.
> > The current policy is to only allow such accounts for PMC/PPMC
> > members. Might the policy be loosened to allow accounts for
> > committers or an exception be made?
> >
> > Thanks,
> >
> > -- Philip
> >
> >
>
>
>
> --
> --j.
>
Re: Hudson access for non-PMC member
Posted by Justin Mason <jm...@jmason.org>.
Hi Philip --
it's purely because the user accounts on the Hudson machines have
quite a lot of privileges.
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.
--j.
On Sat, Jan 23, 2010 at 01:01, Philip Zeyliger <ph...@apache.org> wrote:
> Hi there,
>
> I'd like to setup a Hudson build for the AVRO subproject of Hadoop.
> The current policy is to only allow such accounts for PMC/PPMC
> members. Might the policy be loosened to allow accounts for
> committers or an exception be made?
>
> Thanks,
>
> -- Philip
>
>
--
--j.