[Gluster-devel] Jenkins accounts for all devs.

Fri Jan 22 12:13:43 UTC 2016

On Fri, Jan 22, 2016 at 12:49:28PM +0100, Michael Scherer wrote:
> Le vendredi 22 janvier 2016 à 11:31 +0100, Niels de Vos a écrit :
> > On Fri, Jan 22, 2016 at 02:44:05PM +0530, Raghavendra Talur wrote:
> > > On Fri, Jan 22, 2016 at 2:41 PM, Michael Scherer <mscherer at redhat.com>
> > > wrote:
> > > 
> > > > Le vendredi 22 janvier 2016 à 11:31 +0530, Ravishankar N a écrit :
> > > > > On 01/14/2016 12:16 PM, Kaushal M wrote:
> > > > > > On Thu, Jan 14, 2016 at 10:33 AM, Raghavendra Talur <rtalur at redhat.com>
> > > > wrote:
> > > > > >>
> > > > > >> On Thu, Jan 14, 2016 at 10:32 AM, Ravishankar N <
> > > > ravishankar at redhat.com>
> > > > > >> wrote:
> > > > > >>> On 01/08/2016 12:03 PM, Raghavendra Talur wrote:
> > > > > >>>> P.S: Stop using the "universal" jenkins account to trigger jenkins
> > > > build
> > > > > >>>> if you are not a maintainer.
> > > > > >>>> If you are a maintainer and don't have your own jenkins account
> > > > then get
> > > > > >>>> one soon!
> > > > > >>>>
> > > > > >>> I would request for a jenkins account for non-maintainers too, at
> > > > least
> > > > > >>> for the devs who are actively contributing code (as opposed to random
> > > > > >>> one-off commits from persons). That way, if the regression failure is
> > > > > >>> *definitely* not in my patch (or) is a spurious failure (or) is
> > > > something
> > > > > >>> that I need to take a netbsd slave offline to debug etc.,  I don't
> > > > have to
> > > > > >>> be blocked on the Maintainer. Since the accounts are anyway tied to
> > > > an
> > > > > >>> individual, it should be easy to spot if someone habitually
> > > > re-trigger
> > > > > >>> regressions without any initial debugging.
> > > > > >>>
> > > > > >> +1
> > > > > > We'd like to give everyone accounts. But the way we're providing
> > > > > > accounts now gives admin accounts to all. This is not very secure.
> > > > > >
> > > > > > This was one of the reasons misc setup freeipa.gluster.org, to provide
> > > > > > controlled accounts for all. But it hasn't been used yet. We would
> > > > > > need to integrate jenkins and the slaves with freeipa, which would
> > > > > > give everyone easy access.
> > > > >
> > > > > Hi Michael,
> > > > > Do you think it is possible to have this integration soon so that all
> > > > > contributors can re-trigger/initiate builds by themselves?
> > > >
> > > > The thing that is missing is still the same, how do we consider that
> > > > someone is a contributor. IE, do we want people just say "add me" and
> > > > get root access to all our jenkins builder (because that's also what go
> > > > with jenkins way of restarting a build for now) ?
> > 
> > Contributors would need to get root permissions on the Jenkins slaves
> > (the machines that do the actual building/testing). 
> 
> I rather prefer to not have people have root access on the builder.
> 
> 1) they are used to build the rpms we distribute
> 2) root access also mean that some people might just do a quick fix to
> make some tests pass instead of making a proper long term fix where it
> is needed.

I mainly added this for the contributors that need to debug hanging test
cases. They need to login on the Jenkins slaves and without root
privileges they will not be able to attach gdb, strace or other tools to
the Gluster processes running as root. (We use the shared jenkins
account for that now, which is rather ugly.)

Ideally there would not be any need to retrigger tests. So there would
be little need for contributors to get an account to login on the
Jenkins webui. But unfortunately the regression tests are not stable
enough for that yet. In the future, only contributors that write jobs
for Jenkins would need accounts there.

RPMs that we distribute are built in Fedora Koji and the CentOS CBS. The
RPMs built on the Jenkins slaves are for QA teams and also build
verification. The tarball for releases is build on build.gluster.org,
hence the objection to give a big group of users root access there.

> >  There is no need
> > for root access on the Jenkins master (build.gluster.org). Because
> > Jenkins accounts are connected to the PAM cofiguration on
> > build.gluster.org, contributors would get an account there (does not
> > need to have a shell?).
> 
> This is something that can be fixed by using LDAP. 
> 
> > > > I did the technical stuff, but so far, no one did the organisational
> > > > part of giving a criteria for who has access to what. Without clear
> > > > process, I can't do much.
> > > >
> > > 
> > > 
> > > +ndevos +vijay
> > > 
> > > Something like "should have contributed 10 patches to Gluster and be
> > > supported by at least 1 maintainer" would do?
> > 
> > Works for me. Please send a new page with a description on what
> > requirements a (new) contributor needs to fullfill, what privileges are
> > given and a little on when/how to use those.
> > 
> >   http://gluster.readthedocs.org/en/latest/Contributors-Guide/Index/
> 
> Also, we expect people to request that access, or someone is in charge
> of picking them ?

Yes, this should all be documented. I suggest that access can be
requested by filing a bug against some specific/new component. We need
full tracking of who/when/why someone requests access. Other approaches
can work too, whatever the people handling the requests prefer.

> Also, do we have a formal list of maintainers ? And a process for
> becoming one ?

We have maintainers at gluster.org, but we do not really have a process for
becoming a maintainer. Maintainers are generally listed in the
MAINTAINERS file in the Gluster sources, but other add-on projects have
their own maintainers (and acceptance criteria)...

Niels
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160122/07f5a42f/attachment.sig>