Bug #15919

Move Redmine to a new virtualization host

Added by intrigeri 2018-09-06 15:30:05 . Updated 2019-12-17 13:00:23 .

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

0%

Feature Branch:
Type of work:
Communicate
Blueprint:

Starter:
Affected tool:
Deliverable for:

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

Subtasks

Related issues

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

History

#1 Updated by intrigeri 2018-09-06 15:31:00

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

#2 Updated by intrigeri 2018-09-11 10:13:39

  • 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 2018-10-10 10:31:08

#4 Updated by groente 2018-10-10 10:45:46

> 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 2018-10-10 11:15:03

Good points!

#6 Updated by intrigeri 2019-02-15 10:08:26

  • Description updated
  • Due date set to 2019-12-31

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 2019-02-15 10:13:38

  • 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 (Feature #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 2019-02-21 13:54:03

  • 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 2019-06-01 06:26:08

  • 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 2019-07-10 10:34:07

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

#11 Updated by groente 2019-08-01 09:32:22

  • Assignee set to Sysadmins

#12 Updated by intrigeri 2019-08-29 06:44:15

  • 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 2019-09-12 14:25:21

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

#14 Updated by intrigeri 2019-09-19 06:11:39

  • 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 2019-12-12 13:22:30

  • 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 2019-12-13 09:25:08

  • 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 2019-12-17 13:00:23

  • 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.