[tor-bugs] #32025 [Internal Services/Service - git]: Stop using corpsvn and disable it as a service

[Tor Bug Tracker & Wiki]

#32025: Stop using corpsvn and disable it as a service
---------------------------------------------+----------------------------
 Reporter:  arma                             |          Owner:  tor-gitadm
     Type:  project                          |         Status:  new
 Priority:  Medium                           |      Milestone:
Component:  Internal Services/Service - git  |        Version:
 Severity:  Normal                           |     Resolution:
 Keywords:                                   |  Actual Points:
Parent ID:  #17202                           |         Points:
 Reviewer:                                   |        Sponsor:
---------------------------------------------+----------------------------

Comment (by anarcat):

 So here's the gist of it, from what I understand (thanks for the details!
 :)

  1. corpsvn readonly
  2. move Sue files somewhere, only live files without history
  3. archival policy (#32273)
  4. switch to new archival policy

 This looks like a great roadmap. Can we do at least (1) and (2) (with
 Nextcloud) right now?

 > We could do (3) before we do (1), and then we would never need to do
 (2). It depends how eager we are to shut down corpsvn.

 I'm pretty eager to shutdown the SVN server.

 We have the gayi shutdown scheduled for march in the roadmap (#17202).
 It's part of a train of service migration from the old KVM/libvirt
 infrastructure to the new ganeti cluster. gayi was one of the *first*
 machines I wanted to shutdown, because it was on a machine (textile/kvm1)
 that was almost empty. Alas, it was simpler to just migrate it than to
 wrangle this bag of knots. :)

 The next milestone that's coming is the stretch to buster upgrade. That
 deadline is roughly "this summer". It would be important to shut down gayi
 before that, otherwise it's more needless work (like the migration I had
 to do) that we would need to do here. That work is not currently factored
 in our roadmap.

 But we still have to maintain that box now, and worse we migrated it to
 new infra, so it's taking precious room that should be reserved for
 *other* machines that need to migrate. If we want to run Nextcloud and SVN
 concurrently, which we are *both* paying for in one way or another, I
 would argue that we (TPA) should be provided with the budget to do so
 accordingly. Otherwise SVN should be on its way out.

 And if it's not on its way out, TPA should be clearly notified and given
 the means to handle that change.

 > Any plan where we put off (3) indefinitely is dangerous though. For
 example, we could be open to gdpr messes in our current state -- plus
 actual security failures too.

 I agree with this, but inertia is likely to bring us there. I think the
 plan of archiving the stuff somewhere and moving only "live" documents in
 NC is, in the short term, a good one. But it's true we should not let go
 of this bug and fix it, otherwise it will certainly come and bite us in
 the bottom in the future.

 That said, I really don't like the feeling I have right now that the gayi
 virtual host is being held in ransom against that work. ;) Someone needs
 to own up to the archival problem (#32273, specifically) and just do it,
 and it can be orthogonal to the migration to Nextcloud (or else).

 > Make a comprehensive plan for how files of each category should be
 stored, and who should have read or write access per category. For
 example, there's no reason that HR documents should go into the same
 database, or even the same storage service, as grant proposals.

 Maybe this discussion belongs to #32273, but I should just note that if we
 want a different "storage service" per type of document, we're going to
 end up creating a lot of nextcloud instances. :) I'm not sure how we would
 do this otherwise. I keep hearing that we're worried about Nextcloud's
 access controls and security, but I have yet to hear an actual solution to
 that problem.

 So for now, can we just move ahead on some plan? :)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32025#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online