Project

General

Profile

Bug #15919

Move Redmine to a new virtualization host

Added by intrigeri 9 months ago. Updated 3 months ago.

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

0%

QA Check:
Feature Branch:
Type of work:
Sysadmin
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 9 months ago

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

#2 Updated by intrigeri 8 months 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 7 months ago

#4 Updated by groente 7 months 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 7 months ago

Good points!

#6 Updated by intrigeri 3 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 3 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 3 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.)

Also available in: Atom PDF