Regards, -Prashanth Pai ----- Original Message ----- > From: "Prashanth Pai" <ppai@xxxxxxxxxx> > To: "Michael Scherer" <mscherer@xxxxxxxxxx> > Cc: "Gluster Devel" <gluster-devel@xxxxxxxxxxx>, "gluster-infra" <gluster-infra@xxxxxxxxxxx>, "Niels de Vos" > <ndevos@xxxxxxxxxx> > Sent: Friday, January 22, 2016 6:03:55 PM > Subject: Re: Jenkins accounts for all devs. > > > ----- Original Message ----- > > From: "Niels de Vos" <ndevos@xxxxxxxxxx> > > To: "Michael Scherer" <mscherer@xxxxxxxxxx> > > Cc: "Gluster Devel" <gluster-devel@xxxxxxxxxxx>, "gluster-infra" > > <gluster-infra@xxxxxxxxxxx> > > Sent: Friday, January 22, 2016 5:43:43 PM > > Subject: Re: 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@xxxxxxxxxx> > > > > > 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@xxxxxxxxxx> > > > > > > wrote: > > > > > > > >> > > > > > > > >> On Thu, Jan 14, 2016 at 10:32 AM, Ravishankar N < > > > > > > ravishankar@xxxxxxxxxx> > > > > > > > >> 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@xxxxxxxxxxx, 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. Recent versions of gerrit trigger plugin seems to have the capability to trigger builds when comments match a regex pattern : https://github.com/jenkinsci/gerrit-trigger-plugin/pull/170 > > Thanks. > > > > > Niels > > > > _______________________________________________ > > Gluster-devel mailing list > > Gluster-devel@xxxxxxxxxxx > > http://www.gluster.org/mailman/listinfo/gluster-devel > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
