-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/08/15 22:01, Brian Stinson wrote: > Hi All, > > We're working on testing instances of FAS for storing our > user/group membership information used by the CBS. I'd like to talk > about group naming and the permissions model to get some input. The > goal is to get these discussions going so we can set up our test > environment to mirror what we'll roll out in production. Consider > this a proposal, and please send comments my way (on-list > please!). > > Groups will use the convention 'sig-<shortname>', for example: > people in the Cloud SIG will be members of the FAS group > 'sig-cloud'. This convention will allow push access in dist-git to > any branch that starts with sig-cloud (sig-cloud7, > sig-cloud7-openstack, sig-cloud7-openstack-juno) and grant build > permissions under the SIG tags in Koji[0]. > > FAS has 3 types of membership in a group: Admin, Sponsor, and User. > All 3 levels will be granted commit/build permissions, while only > Admins and Sponsors can modify members of the group. > > To match our permissions model[1], I propose: - We populate the > 'Accounts' (Global Admin) group with the members of the CentOS > Board. - The Board member responsible for each SIG will create the > appropriate SIG group in FAS - The Board member will add > him/herself as an admin of the group - The Board member will > sponsor the SIG Chair as a sponsor for the group - From then on, > the SIG Chair and Board member can sponsor others into the group as > users (and optionally add more sponsors to the group) > > Anyone have thoughts? Once we reach consensus, I'll get this > written up for the SIG wiki page. > > Cheers! Brian > > [0]: http://wiki.centos.org/BrianStinson/GitBranchesandKojiTags > [1]: http://wiki.centos.org/SpecialInterestGroup So in that configuration, that also means that a SIG Chair has now more "power" but then also more responsabilities. As FAS will be a "self-service" user registration tool, it will be easy for someone to create an account, then be sponsorized within a SIG by a Chair, to then be able to build in Koji (against tags for that SIG) and also commit/push to the correct hierarchy on git.centos.org. I guess (and it's the common scenario now) that we don't want to restrict things like some people from a SIG being able to build only, and not commit to git, or the reverse, but if we want to do it, we can still filter on group membership, like this : - - FAS TopLevel - SIG-$example - SIG-$example-build - SIG-$example-git - -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlXDEXsACgkQnVkHo1a+xU5UuACfUl/qI/VfBY+aHx4FXDv+ijXi 95YAnjJcu+qL4rtXRCtrZ1inDVZcrVmA =YwGT -----END PGP SIGNATURE-----