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