Project

General

Profile

Bug #15919

Move Redmine to a new virtualization host

Added by intrigeri over 1 year ago. Updated about 1 month ago.

Status:
Rejected
Priority:
High
Assignee:
-
Category:
Infrastructure
Target version:
Start date:
09/06/2018
Due date:
12/31/2019
% Done:

0%

Feature Branch:
Type of work:
Communicate
Blueprint:
Starter:
Affected tool:

Description

We have to move out of the obsolete virtualization setup where our Redmine is currently hosted, worst case by the end of the Jessie LTS support (2020-06-30) but I think we're going to be expelled earlier than that.

Our options are:

  • install a fresh VM hosted by Riseup, redo the Redmine setup (and Puppetize it properly), copy the data
  • install a fresh VM on lizard, redo the Redmine setup (and Puppetize it properly), copy the data
  • copy the entire VM as-is to a new VM on lizard
  • copy the entire VM as-is to a new VM somewhere else than on lizard

Related issues

Duplicated by Tails - Feature #16035: Self-host our Redmine Duplicate 10/10/2018
Blocks Tails - Feature #13284: Core work: Sysadmin (Adapt our infrastructure) Confirmed 06/30/2017

History

#1 Updated by intrigeri over 1 year ago

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

#2 Updated by intrigeri over 1 year ago

  • Target version changed from 2019 to Tails_4.0

I'll try to do that by the end of 2019Q2. Worst case, it has to be done by the end of 2019.

#3 Updated by intrigeri over 1 year ago

#4 Updated by groente over 1 year ago

Our options are:

  • install a fresh VM hosted by Riseup, redo the Redmine setup (and Puppetize it properly), copy the data

That's one option, I'd like to add the option of installing a fresh VM hosted by another friendly collective, redoing the setup (in puppet), and copying the data.

  • install a fresh VM on lizard, redo the Redmine setup (and Puppetize it properly), copy the data
  • copy the entire VM as-is to a new VM on lizard

Having redmine not run on lizard would have the benefit of not losing important communication channels when lizard is down. We're starting to centralise quite a lot towards lizard, I'd like to emphasise the merits of a decentralised infrastructure in making a choice here.

#5 Updated by intrigeri over 1 year ago

Good points!

#6 Updated by intrigeri 11 months ago

  • Description updated (diff)
  • Due date set to 12/31/2019

intrigeri wrote:

I'll try to do that by the end of 2019Q2.

I'm 225% over budget on the "Needs that may pop up along the way" budget line, and that's without counting the work my team-mates did. So I won't do that before we have fresh budget for it.

Worst case, it has to be done by the end of 2019.

Still true.

#7 Updated by intrigeri 11 months ago

  • Assignee deleted (intrigeri)
  • Target version changed from Tails_4.0 to Tails_3.17

While it still makes sense to puppetize things we need to change as needs arise, which I did this year, now that we've added Switch to Gitlab (#15878) to our roadmap, I don't think it's worth spending time now on redoing and puppetizing the Redmine setup from scratch.

So I'm now strongly leaning towards copying the existing VM as-is, be it to the new Riseup virtualization farm (some centralization concerns), or to lizard (big centralization concerns), or to another friendly collective's virtualization farm (as proposed by groente). I think the last option is now my preferred one, if feasible.

#8 Updated by intrigeri 11 months ago

  • Subject changed from Move Redmine to a new VM to Move Redmine to a new virtualization host

(That's what we have to do. Whether it's a brand new VM or not remains to be decided.)

#9 Updated by intrigeri 8 months ago

  • Priority changed from Normal to High
  • Target version changed from Tails_3.17 to Tails_3.15

As Riseup folks told us, this has to happen really soon.

#10 Updated by CyrilBrulebois 6 months ago

  • Target version changed from Tails_3.15 to Tails_3.16

#11 Updated by groente 6 months ago

  • Assignee set to Sysadmins

#12 Updated by intrigeri 5 months ago

  • Target version changed from Tails_3.16 to Tails_3.17

Even if Riseup folks had time to do this with us before 3.16, we're too close to a release to disrupt our activities right now.

#13 Updated by intrigeri 4 months ago

  • Target version changed from Tails_3.17 to Tails_4.0

#14 Updated by intrigeri 4 months ago

  • Target version deleted (Tails_4.0)

(The exact timing is out of our hands so we can't realistically set any target version at this point.)

#15 Updated by intrigeri about 1 month ago

  • Assignee changed from Sysadmins to intrigeri
  • Target version set to Tails_4.2

As per today's team meeting:

I'll ask SeaCCP if it's OK to give up on this, as long as the VM can be decommissioned in May 2020 (we'll have migrated to GitLab).

If we give up, worst case, if the current host really dies before we've migrated to GitLab, we can restore Redmine from backups in a VM on lizard, or migrate the VM as-is (if it still works well enough for that). We would have to reclaim some RAM to do that, though, e.g. by turning off one isotester.

#16 Updated by intrigeri about 1 month ago

  • Target version changed from Tails_4.2 to Tails_4.3
  • Type of work changed from Sysadmin to Communicate

I've just emailed SeaCCP. If they don't answer earlier, I'll ping them in a month or so.

#17 Updated by intrigeri about 1 month ago

  • Status changed from Confirmed to Rejected
  • Assignee deleted (intrigeri)
  • Target version changed from Tails_4.3 to Tails_4.2

In the end, Riseup folks concur: they prefer not to spend time migrating us somewhere else only for such a short time.

Also available in: Atom PDF