[CentOS-devel] Proposal: CBS/Infrastructure Meeting 15-Sep-2014 13:00 UTC

[Karanbir Singh]

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