[Gluster-devel] Jenkins accounts for all devs.

Fri Jan 22 12:33:55 UTC 2016

----- Original Message -----
> From: "Niels de Vos" <ndevos at redhat.com>
> To: "Michael Scherer" <mscherer at redhat.com>
> Cc: "Gluster Devel" <gluster-devel at gluster.org>, "gluster-infra" <gluster-infra at gluster.org>
> Sent: Friday, January 22, 2016 5:43:43 PM
> Subject: Re: [Gluster-devel] Jenkins accounts for all devs.
> 
> 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)...

Thanks for noticing this. There are other projects (like gluster-swift) on Gerrit that need to create and maintain jobs there.
I was in the middle of configuring a job when I was locked out from the common account that we've been judiciously using.

Here's a useful tip: In Openstack Gerrit (review.openstack.org), whenever there is a spurious regression failure, anyone can comment on
the change with this text - "recheck no bug" and the system will re-run the test suite. This would alleviate the need to have account
if re-triggering tests is the only requirement. I do not know the details on how this is implemented there but I assume it isn't that
hard. Folks on #openstack-infra should know further.

Thanks.

> 
> Niels
> 
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel