On Sunday, 7 September 2014 21:27:44 CEST, Eike Hein wrote:
I'm curious however, what's the state of manifesto-compliance[1]
for the Gerrit instance? Does KDE Sysadmin have admin access and
the ability to get the data out if needed?
This is a very good question. Right now, only I (and other CESNET's
staffers) have root access in there, the PostgreSQL DB is not being backed
up automatically and the refs/changes/* is not being replicated to KDE's
git for technical reasons [1]. This is, however, not a final state -- I
simply had to show up something at Akademy :).
There's a page at the wiki [2] where I'm collecting various missing bits.
Giving out both root SSH access and Gerrit admin access is already listed
in there; some people (thanks Frederik) have already agreed to volunteer as
Gerrit admins, and I'll be more than happy to give this role to other
people with some Gerrit experience as well. Automatic backups to KDE's own
machines are also definitely planned. Can someone help me with these? Are
there volunteers to help manage this service? If so, please make yourselves
known.
The VM itself runs on CESNET's/XIFI's OpenStack-based cloud. There's
currently a small limitation with the version of Keystone which is used
where apparently the administration can only happen through a shared
OpenStack account (in OS's speach, there are just tenants, not groups of
accounts). I'll be happy to share the respective credentials with KDE's
sysadmins so that they're able to reboot the VM or do anything else with it
in case it's needed. It's a pity that I cannot just point you to FI-WARE's
cloud portal to register in there and ask for some credentials so that I
could add you to some group...
The VM is installed and managed through Puppet. I'll be sharing the recipes
once I get an approval at work (and this one will probably take some time).
Once everything described above is done, the worst case (in a very unlikely
situation where CESNET has to discontinue this service on a short notice),
it will be easy to migrate everything to any other cloud provider (and
trivial if the other cloud provider happens to use OpenStack). Even if the
impossible happened and CESNET decided to be actively hostile against KDE,
the only thing which you would have to do would be:
a) launch a RHEL6-compatible machine somewhere and get it Puppetized,
b) apply the manifests,
c) restore from backup.
Again, thanks for asking this -- it's a very important question and I would
hate to be a troublemaker here.
Cheers,
Jan
[1] Hooks would fire, which means that anybody who e.g. submits a change
proposal with e.g. a CCMAIL: or BUG: keywords would be able to modify stuff
even though they are no KDE developer. That's how the hooks at git.k.o work
and changing this is not trivial -- the hooks coould be made to ignore the
change based on the ref being pushed to, but then there's a problem because
they hooks are also designed to ignore any commit which is already in
another ref. This means that if, say, refs/changes/01/1/1 did not trigger a
BUG: notification, once it's approved and get pushed to git.k.o's
refs/heads/master, it *won't* fire again. Patches to hooks within
sysadmin/repo-management.git are welcome, but Ben says these are a bit
fragile.
[2] https://techbase.kde.org/Development/Gerrit#TODO_list
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
