On 09/17/2014 09:46 PM, Stephen John Smoogen wrote: > > Well I am not sure that FAS allows for federation yet :). I like to > think of FAS as Kerberos done by people who hated Kerberos but generally > adding in various features over time :). One of the key issues we need to solve, and I am not sure how we are going to do this is git-branch to user to sig mapping. Consider this: - git.centos.org hosts git repos, one repo per package name ( eg. there is only one kernel.git repo ). - master branch for each of those git repos is locked and will not allow content beyond the readme file. - the distro branches are locked, in that only core sig people and the rhel release process can write to those branches. eg. c5/c6/c7 are not available to commit and push into by anyone other than the buildsystem for the distros. - every sig gets commit access to the git repos they want ( and anyone can ask for any repo ); however, they can only push to git.centos.org into a branch name that matches that signame. assume virt-sig has 'virtsig' as their ID, then their kernel will and can live in the same git repo as the distro kernel, but in a branch called virtsig. Out git infra can ( and already does ) handle this level of user to group to gitbranch mapping. - we need the auth mechanism used for koji, the lookaside cache upload and whatever interface is exposed to git.centos.org, to also work with this. Note: 1) we might need to find a schema that allows a sig to push multiple branches. eg. if the virtsig is doing a kernel-mainline and a kernel-xen, they might need two branches to handle those in. I've tested that with a tag_* schema, where virtsig_<whatever> would be accepted from a member of the virtsig team; but this might be creating uneeded constraints on the sig folks, so am open to conversation around that. 2) the git.centos.org resource is completely multi-master federated and replicated. Recently some people in Canada complained about perf issues against it, and I can quite imagine us putting more of the replica's public ( this includes the entire api and git interface, not just the web interface ) - so the auth mechanism we end up with needs to support that as well ( i dont see it as being a problem, but its worth mentioning ). Regards -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc