[Gluster-devel] Jenkins accounts for all devs.

[Michael Scherer]

Le vendredi 22 janvier 2016 à 14:51 +0530, Kaushal M a écrit :
> 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) ?
> >
> > 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.
> 
> The need right now is the ability for some of the developers to be
> able to re-trigger jobs in Jenkins. Access to the builders is not
> required right away (this would also require changes to the builders
> IIRC). 

Depend how clean you want the access to be. since jenkins is root there,
you can just add your ssh keys to the builders if you can define a new
job.

> What I had in mind was to create 3 groups - admins,
> maintainers, developers.

>  Then we configure Jenkins to give admins full
> access, maintainers access to manually trigger and retrigger, and
> developers the ability to retrigger. 

Why the difference between maintainers and developpers, ie, why not let
manual trigger ?

> Jenkins can do this with either
> unix groups, using build.gluster.org's groups and users, or via LDAP.
> Since we'd like to move to freeipa later, I thought it'd be better not
> to create more users/groups on build.gluster.org.

But we still miss the "who decide what go in what group".

Also, that's 3 groups for just jenkins, and we already have 23 teams on
github. I am a bit concerned about having more groups than builder for
EL6, and would really see a simpler model access. 


-- 
Michael Scherer
Sysadmin, Community Infrastructure and Platform, OSAS


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160122/84bf1ac8/attachment-0001.sig>