wiki:MoveOffTrac

Version 13 (modified by btlogy, at 2024-09-03T17:31:22Z) (diff)

--

Move Off Trac

The goal of this page is to cover the phases of a project aiming at moving some critical features from Trac to an other solution (or combination of).

More information about the start of this project can be found in ticket #4095.

Discussions also happened in Nuts&Bolts meetings: see from WeeklyMeeting#April22024.

Scope

Goals and Requirements

  1. MUST replace Trac as currently used for Ticket and Wiki by some alternative(s):
    • MUST look better: current UI looks old which makes the Tahoe-LAFS project looking dead
    • MUST be better maintained: Trac is dying? max 2 contributors per month - ​https://openhub.net/p/trac
    • MUST be easier to maintain: Trac is difficult to update (current = v1.0.13/2016-09-11, latest = v1.6.0/2023-09-23)?
    • MUST allow Self-Registration (Trac requires manual registration via email)
    • COULD support OAuth2 with Github?
    • MUST be (F)OSS
    • MUST be self-hostable
      • note "able": MUST be a story for getting to a self-hosted instance if we want
      • ..but doesn't have to be self-hosted right away
  2. MUST replace the current landing page (start/home page from the Trac/Wiki?):
  3. MUST replace the current binary repository for Tahoe-LAFS releases (​https://tahoe-lafs.org/downloads)
    • by providing at least a similar way to transfer files via ssh
  4. COULD be used to replace:
    • Github code hosting and review (pull request), keeping only a mirrored clone
    • Github Actions (to avoid leaving secrets in environment variables)
    • Circle CI (to avoid giving them too many permissions)

Inclusions

  • Trac users of the Tahoe-LAFS project
  • Trac issues of the Tahoe-LAFS project
  • Trac wiki pages of the Tahoe-LAFS project
  • Trac HTML home page of the Tahoe-LAFS project
  • Hall of Fame HTML page of the Tahoe-LAFS project
  • The related DNS records (mostly: tahoe-lafs.org)

Exclusions

  • Other Trac projects (see DevInfra)
  • Buildbot master instances for some other Trac projects
  • DARCS SCM for some of the other Trac projects
  • Any other services provided by the current server and not yet documented in DevInfra

Deliverables

  1. A VPS (hosted by Hetzner) providing the following features powered by NixOS and Gitea:
    • a tracking system provisioned with the issues migrated from Trac (same numbers)
    • a Wiki system provisioned with the relevant pages migrated from Trac (same names)
    • a static website replacing the landing page from Trac with the code required for CI and CD
    • a blog post for the Hall of Fame page (if sensible - fallback = static page)
    • a (Git) repository defining the VPS it-self and its configuration as code (including the secrets using sops)
    • optionally including the terraform code allowing to manage the related DNS records (if Gandi supports it)
  2. A detailed migration plan to handle the transition (DNS changes and/or redirections)
    • documented in a this wiki page
    • covering the possible manual steps related to DNS records, HTTP redirections or URL rewriting
    • with a (Git) repository including/referring to the tools used to actually migrate
  3. An high-level migration plan for the features hosted on the VPS described to be later hosted on Codeberg SaaS (assuming it is possible)
    • documented in this wiki page too

Deliverable 1 - self-hosted Gitea/Forgejo? on NixOS

  1. Testing
  2. Production
    • TBD

Deliverable 2 - migration plan from Trac to self-hosted Gitea/Forgejo?

  1. Testing
  2. Production
    1. new alias legacy.tahoe-lafs.org hostname + cert renew? req:
      • root access > meejah OK
      • DNS zone access > brian + meejah OK (gandi.net)
    2. migrate from Trac to new VPS
    3. tahoe-lafs.org to new VPS + redirect/proxy to legacy

Choice:

  • short or middle term intermediate? meejah says self-hosted OF SaaS w/o intermediate : new legacy link to take care or not.

Deliverable 3 - high-level migration plan from Forgejo to Codeberg

  1. Testing
    • Issues and Wiki page have been migrated from Forgejo to Codeberg:
    • Known issues:
      • all links to contributors are broken (likely because Codeberg does not allow this? maybe the user needs to be local and in the org first?! )
      • all links to comments are broken (likely because they use the ID from the source!)
      • all the link to attachement are broken
  2. Production
    • TBD

Pros and Cons of self-hosted vs SaaS

self-hosted Gitea

Pros:

  • Links to issues and wiki pages should work (WiP)
  • Links to comments work
  • Links to attachments work
  • Links to authors work (if pre-provisioned)
  • Nearly ready to MoveOffTrac
  • Many options to fix content later (e.g.: full access to DB)
  • Website already works with CI/CD
  • CI/CD works like Github and CAN cover all platform

Cons:

  • VPS required (8$/m)
  • Decent baby-sitting required: updates, monitoring and backup/restore (how many h/m?)
  • Poorly scalable, but could perform better than SaaS (DoS protection?)

SaaS Forgejo on Codeberg

Pros:

  • Smaller VPS (5$/m), but still required for redirection (statless, maybe possible w/o?)
  • Minimal baby-sitting: updates and monitoring (how many h/m?)
  • Free of extra charge on Codeberg (20$/user/m on Gitea!)
  • Should be scalable, but performance could be a problem (at least on Codeberg!)

Cons:

  • Links to comments are broken
  • Links to attachments are broken (or no attachement at all?)
  • Links to authors are broken (likely on purpose)
  • Delays MoveOffTrac (unless we agree on 2 steps)
  • Reduced options to fix the content later (e.g.: no access to the DB)
  • website needs to be adapted to work on Codeberg
  • CI/CD works differently from Github/Gitea? (but possible)

Remarks:

  • Should we test a free plan on Gitea.com (with CI/CD)?
  • What cost CI/CD on Codeberg vs Gitea.com (for Win and Mac?)