On Wed, Feb 17, 2016 at 12:11:09PM +0100, Pierre-Yves Chibon wrote: > Good morning everyone, Good morning, Pingou. Thanks for writing this up! :) > For a little while now I have been wondering about dropping gitolite for pagure. > Gitolite has quite a lot of advantages: > - well known > - well documented > - very flexible > > But for pagure's use-case it also has some drawbacks: > - perl > - "too powerful" > > Let me explain the later point, pagure use-case is currently: either you have > commit or you don't. There is no per-branch ACLs (yet?) and no need for a number > of the fancy features gitolite offers (VREF, aliases...). > > Basically it could be replaced with: > - a simple async service queried upon login (ssh login) allowing read/write access, > shell access or denying access > - a git hook for branch ACLs (this would become a pagure plugin I think, like > the other hooks). As said above this isn't there atm, so this could also come > in a later stage anyway. > > That's also how gitolite works, a script called upon login allowing access or > not and a git hook for more fine-grain ACLs. > > While looking into this I have also been thinking if we would like to drop > gitolite for pkgs.fp.o as well. Just as a point of clarification -- there are two systems in play for pkgs.fp.o currently: - There is 'cgit' which provides the web-based view of the repos. - There is 'gitolite' which provides the backend ACL controls over who is allowed to push to what. Using pagure as the read-only view of the repos is definitely a good idea. What's being discussed here is the "if we should" and "how we should" of replacing the backend acl controls with pagure. Generally, I think it's a good direction to move in. Maybe we're already on the same page about that. > We could have the async service directly linked to pkgdb's DB. This means: > - Changes to pkgdb are directly propagated to pkgs.fp.o > - We can rely on the collections information directly retrieved from the DB > - We can use our current set-up (one shell account / packager) and not tweak > gitolite until it behaves as we want (which is only supported by gitolite to > please us). > - No need for the alias warning for namespacing, we can check if a namespace was > specified and use ``rpms`` if not > - May be easier to hack/maintain in the long term (may be not, hard to say in a > way :)) I'm not sure about querying pkgdb DB directly from the git hook -- or even querying pkgdb's JSON API directly. - If we connect directly to the DB, it exposes the internals of pkgdb in a way that could make it much harder to upgrade that schema in the future. Better to connect over the REST API. - If we connect over the REST API, we could run into system interdependence problems in the future. If pkgdb goes down accidentally, or if it needs to go down for maintenance, then the dist-git repos will be dead in the water. No one will be able to push anything. - Right now, we basically cache *all* of the pkgdb acls on disk as gitolite perms. This has the advantage of decoupling the systems at request time. It has the disadvantage of synchronization lag. When ACLs get updated in pkgdb, we have to wait for those to sync to gitolite to be meaningful in practice. We used to have a cronjob on which we waited forever.. we now have that fedmsg-genacls updater that makes it much quicker, but not instant. Can we keep this same arrangement for a pagure replacement of gitolite? > We would still need to have a service to create the git repo and eventually the > branches. > And for pkgs.fp.o we will definitely need a git hook (but there is already one) > to prevent branch from being deleted and do branch-based ACL control. Yeah, since we still need a service to create the git repo and the branches, we might as well sync pagure ACLs at the same time, no? > One question though, looking at our current setup, we allow people to create > their own branch, and not to delete it, right? > I am curious if anyone can create a branch on a package, I'm not seeing > something in the gitolite repo that would prevent me from creating a branch on a > package I don't maintain (assuming I am not provenpackager), but maybe I've > missed it. I'm not sure. I think I tried once long in the past to create a branch, and was denied. But maybe that was with our gitolite2 setup. > So what do you think of this? > > Would you be ok with me breaking pkgs.stg.fp.o to do some testing? If so I will > try not to break things in a non-reversible way :). > AFAICS, the only thing I'd need to change is the ~/.ssh/authorized_keys files > for the users and add an pkgdb_async_client RPM or so that would be call upon > login and contain the git hook. +1 to breaking stg for a time. :) > Thoughts? Rotten tomatoes? Soup? > > > Note that I might still pursue this for pagure, not entirely sure yet though. > Just a thought while writing this, using this approach might actually make it > easier to deploy pagure for pkgs.fp.o since then we could indeed just use pkgdb > as data source and have a fedmsg-based updater to sync ACLs from pkgdb to > pagure. I guess I don't understand what's easier about using pkgdb as a data source for pagure. It seems harder to me (both to write up front as well as to maintain long term). > Thanks for reading it this far :) Cheers!
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
