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!