Le vendredi 22 janvier 2016 à 14:51 +0530, Kaushal M a écrit : > 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) ? > > > > 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
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
