Project

General

Profile

Bug #10093

Upgrade to Gitolite v3 on puppet-git.lizard

Added by intrigeri over 3 years ago. Updated about 2 months ago.

Status:
Confirmed
Priority:
Elevated
Assignee:
Category:
Infrastructure
Target version:
Start date:
08/25/2015
Due date:
% Done:

0%

QA Check:
Dev Needed
Feature Branch:
Type of work:
Sysadmin
Blueprint:
Starter:
Affected tool:

Description

Gitolite v2 is not in Jessie.

The main difficulties I expect are: hooks handling (we do complicated stuff there), and migrating from ADC to some replacement.

Resources:


Related issues

Blocks Tails - Feature #13284: Core work: Sysadmin (Adapt our infrastructure) Confirmed 06/30/2017
Copied to Tails - Bug #14587: Remove Gitolite from buse Resolved 08/25/2015

History

#1 Updated by sajolida over 3 years ago

  • Target version changed from 246 to Tails_2.0

#2 Updated by intrigeri over 3 years ago

  • Assignee set to intrigeri

Either I'll manage to do it by the end of the year, or it'll be postponed to the last call for upgrades from Wheezy, I guess.

#3 Updated by intrigeri over 3 years ago

  • Target version changed from Tails_2.0 to Tails_2.6

#4 Updated by intrigeri over 2 years ago

  • Target version changed from Tails_2.6 to Tails_2.7

Let's see if we manage to handle that in September. If we don't, we'll need to reschedule this to some later sysadmin sprint.

#5 Updated by intrigeri over 2 years ago

  • Target version changed from Tails_2.7 to 284

Best case I'll work on this around December 17-20.

#6 Updated by anonym over 2 years ago

  • Target version changed from 284 to Tails 2.10

#7 Updated by intrigeri over 2 years ago

  • Target version changed from Tails 2.10 to Tails_2.11

I had to take over a number of more urgent sysadmin tasks, so this'll have to wait.

#8 Updated by intrigeri about 2 years ago

  • Target version changed from Tails_2.11 to Tails_3.2

I don't see myself working on this before 3.0 is out, and probably not during summer.

#9 Updated by intrigeri almost 2 years ago

  • Target version changed from Tails_3.2 to Tails_3.3

#10 Updated by intrigeri almost 2 years ago

  • Target version changed from Tails_3.3 to 2018

#11 Updated by intrigeri over 1 year ago

  • Subject changed from Upgrade to Gitolite v3 to Upgrade to Gitolite v3 on puppet-git.lizard

#12 Updated by intrigeri over 1 year ago

  • Copied to Bug #14587: Remove Gitolite from buse added

#13 Updated by intrigeri over 1 year ago

#14 Updated by intrigeri over 1 year ago

  • Blocks Feature #13284: Core work: Sysadmin (Adapt our infrastructure) added

#15 Updated by intrigeri over 1 year ago

  • Description updated (diff)

#16 Updated by intrigeri over 1 year ago

  • Blocks deleted (Feature #13529: Upgrade puppet-git.lizard to Stretch)

#17 Updated by intrigeri over 1 year ago

(I've quickly tested gitolite/wheezy on current sid and at least basic operations work fine, so let's not block on this.)

#18 Updated by intrigeri over 1 year ago

  • Assignee changed from intrigeri to groente

#19 Updated by groente 6 months ago

A short inventory of how step 4 on http://gitolite.com/gitolite/migr/ (does not) affects us:

- we don't use NAME rules
- we don't use subconf
- we use git-hooks for mirroring and not the gitolite mirror functionality, so we're not affected by changes there
- we're not affected by changes in GL_ALL_INCLUDES_SPECIAL since we don't use @all
- we have GL_NO_DAEMON_NO_GITWEB and GL_NO_SETUP_AUTHKEYS are both set to 0, we are not affected by changes there.
- we're not affected by ADMIN_POST_UPDATE_CHAINS_TO and UPDATE_CHAINS_TO
- we don't have gl-creater nor gl-perms files

So atleast we won't have to worry much about that part...

#20 Updated by groente 6 months ago

  • Assignee changed from groente to intrigeri
  • QA Check set to Info Needed

a short local test has shown that dummy-versions of our hooks still work after updating to gitolite3.

we'll have to decide whether we want gitolite3 to run as user gitolite3 (debian default) or keep it running as user gitolite (with the advantage of not having to replace the username in our entire setup). the same goes for the basedir, debian default is /var/lib/gitolite3, but this will break various references to /var/lib/gitolite in our setup.

i'm tempted to stick to debian defaults.

what we could do as a dirty hack is to replace the uid/gid/homedir/shell attributes of the existing gitolite user with the gitolite3 values, so we'll have two identical users and the old gitolite@puppet-git will keep working. furthermore, /var/lib/gitolite can be replaced by a symlink to /var/lib/gitolite3.

what needs to be done is add a ~160GB disk to puppet-git to store the backups of all the repositories during the migation.

after that, it's a matter of:
- backing up all the repositories and hooks
- dpkg --purge gitolite
- rm rf /var/lib/gitolite
install gitolite3
- putting the repositories and hooks back in place
- running
gitolite compile
gitolite setup --hooks-only
gitolite trigger POST_COMPILE
- give the gitolite-admin repo a push.

then optionally we add a hacky fake user gitolite and a symlink, or we adapt all the puppet-references to /var/lib/gitolite and gitolite@puppet-git.

i'd quite like your opinion on this before working things out further.

TODO: i still need to test git-annex.

#21 Updated by intrigeri 6 months ago

  • Assignee changed from intrigeri to groente
  • QA Check changed from Info Needed to Dev Needed

we'll have to decide whether we want gitolite3 to run as user gitolite3 (debian default) or keep it running as user gitolite (with the advantage of not having to replace the username in our entire setup). the same goes for the basedir, debian default is /var/lib/gitolite3, but this will break various references to /var/lib/gitolite in our setup.

i'm tempted to stick to debian defaults.

I'd love to fully switch to the defaults too but our canonical Git repo got migrated a couple months ago there so there's already quite a few people with gitolite hard-coded in many Git remote URLs that we cannot update for them. So:

what we could do as a dirty hack is to replace the uid/gid/homedir/shell attributes of the existing gitolite user with the gitolite3 values, so we'll have two identical users and the old gitolite@puppet-git will keep working. furthermore, /var/lib/gitolite can be replaced by a symlink to /var/lib/gitolite3.

… yes, this seems to be the cheapest way to get backwards compat with existing Git remote URLs.

what needs to be done is add a ~160GB disk to puppet-git to store the backups of all the repositories during the migation.

after that, it's a matter of:

+ timing this right: we can chat on XMPP to figure out when would be a good time for such a disruptive operation. Then you can ask moire & sajolida (who are running our end of year fundraiser at the moment and need a working web site) if the proposed dates work for them.

I see nothing about Puppet in there. What about tails::gitolite and the gitolite Puppet module it uses?

TODO: i still need to test git-annex.

Ah, the ADC thing. This one has quite some potential to be loads of fun :P

#22 Updated by intrigeri about 2 months ago

  • Target version changed from 2018 to Tails_3.15

2018 is over but it'll will definitely be done by end of 2019Q2 so setting target version to the first release after that.

Also available in: Atom PDF