Move off Trac - Initiation #4095

New Issue

btlogy · 2024-03-06T16:14:54Z

btlogy commented

2024-03-06 16:14:54 +00:00

As discussed during the nuts-and-bolts meeting this Tue 5th of Mars 2024, I'm creating this issue to initiate the possible migration of Trac.

The main deliverable of this task would be a document (Wiki page?) describing, at least:

the goals and initial requirements
the current situation
the possible foreseeable options

As discussed during the nuts-and-bolts meeting this Tue 5th of Mars 2024, I'm creating this issue to initiate the possible migration of Trac. The main deliverable of this task would be a document (Wiki page?) describing, at least: * the goals and initial requirements * the current situation * the possible foreseeable options

btlogy added the

labels 2024-03-06 16:14:54 +00:00

btlogy added this to the undecided milestone 2024-03-06 16:14:54 +00:00

btlogy commented

2024-03-06 16:47:00 +00:00

I've already compiled some notes from the last Tuesday meeting and assessed the current situation to some extend.

But I'm unsure if I should/could share what I have so far in a Wiki page or an other live document (cryptpad.fr) before we have something sound to start the next phase (planning) - if we do.

I've already compiled some notes from the last Tuesday meeting and assessed the current situation to some extend. But I'm unsure if I should/could share what I have so far in a Wiki page or an other live document (cryptpad.fr) before we have something sound to start the next phase (planning) - if we do.

btlogy commented

2024-03-08 14:36:34 +00:00

I've a few questions I'd like to find the answer in order to update my notes about this task:

#3742 is about a repository on gitlab.com for infra/Terraform code : does it exist? is it used to deploy this Trac instance? how is it deployed otherwise?
there are many other services running on the same system, including 7 other Trac projects, a Darks server and at least 3 Builbot masters: should those be in the scope too?
the version of this Trac instance (v1.0.13) and the system hosting it (Ubuntu 19) have a few new releases (Trac 1.6.0 / Ubuntu 22): is there something blocking some upgrade?
as mentioned in my previous comment: what would be the best way to share my notes so we can collaborate to improve them (cryptpad.fr)?

I've a few questions I'd like to find the answer in order to update my notes about this task: 1. #3742 is about a repository on gitlab.com for infra/Terraform code : does it exist? is it used to deploy this Trac instance? how is it deployed otherwise? 2. there are many other services running on the same system, including 7 other Trac projects, a Darks server and at least 3 Builbot masters: should those be in the scope too? 3. the version of this Trac instance (v1.0.13) and the system hosting it (Ubuntu 19) have a few new releases (Trac 1.6.0 / Ubuntu 22): is there something blocking some upgrade? 4. as mentioned in my previous comment: what would be the best way to share my notes so we can collaborate to improve them (cryptpad.fr)?

meejah commented

2024-03-08 18:49:15 +00:00

I'm not aware of any infratructure repository, and don't immediately see anything on gitlab.com (at least under tahoe-lafs org).

Sharing notes could be done on cryptpad.fr for sure. Another option could be to find a suitable place in docs/* and do that via a pull-request.

I'm not aware of any infratructure repository, and don't immediately see anything on gitlab.com (at least under tahoe-lafs org). Sharing notes could be done on cryptpad.fr for sure. Another option could be to find a suitable place in docs/* and do that via a pull-request.

btlogy commented

2024-03-19 17:09:09 +00:00

As discussed last week in the Nuts and Bolt meeting, I've published a summary of my assessment of the current state of the infrastructure around Trac in a new Wiki page: DevInfra

As discussed last week in the Nuts and Bolt meeting, I've published a summary of my assessment of the current state of the infrastructure around Trac in a new Wiki page: [DevInfra](wiki/DevInfra)

btlogy commented

2024-05-30 09:00:03 +00:00

Wherever the Trac data will end up being moved, here are the notes I've collected while trying to reproduce the current Trac setup from a hotcopy to a docker environment:

Initiate trac-admin <project> then hotcopy <path> on the source
Remove log directory from the hotcopy path/log
Purge session from the hotcopy with trac-admin path and session purge ...
Compact the DB with sqlit3 path/db/trac.db 'VACUUM;'
Prepare to transfer the curated hotcopy directory with public_html folder and trac.htdigest file
Checkout https://code.lafs.eval.latfa.net/tahoe-lafs/MoveOffTrac on the target
Transfer and restore Trac hotcopy in trac/tahoe-lafs on the target
Transfer and restore extra files (living outside of Trac so far) on the target:
- trac/public_html
- trac/trac.htdigest
Clone the Git repo: git clone <https://github.com/tahoe-lafs/tahoe-lafs.git> trac/repos/tahoe-lafs.git
Create missing folders (e.g.: trac/thaoe-lafs/log)
Patch trac/tahoe-lafs/conf/trac.ini
Gain admin access (if needed):
1. docker-compose run --rm --entrypoint bash trac
2. trac-admin tahoe-lafs
3. permission add <username_here> admin
4. exit and exit
Start the local Trac: docker-compose run --rm trac
Login on http://localhost:8000/tahoe-lafs/login
Edit the http://localhost:8000/tahoe-lafs/wiki/WikiStart?action=edit page to replace link: /~trac/ -> ../chrome/site/ or transform them as attachment

These steps will likely be improved with more iteration, but they should help reproducing a workable environment to actually test/start the migration.

Wherever the Trac data will end up being moved, here are the notes I've collected while trying to reproduce the current Trac setup from a hotcopy to a docker environment: 1. Initiate `trac-admin <project>` then `hotcopy <path>` on the source 2. Remove log directory from the hotcopy `path/log` 3. Purge session from the hotcopy with `trac-admin path` and `session purge ...` 4. Compact the DB with `sqlit3 path/db/trac.db 'VACUUM;'` 5. Prepare to transfer the curated hotcopy directory with `public_html` folder and `trac.htdigest` file 6. Checkout <https://code.lafs.eval.latfa.net/tahoe-lafs/MoveOffTrac> on the target 7. Transfer and restore Trac hotcopy in `trac/tahoe-lafs` on the target 8. Transfer and restore extra files (living outside of Trac so far) on the target: - `trac/public_html` - `trac/trac.htdigest` 9. Clone the Git repo: `git clone <https://github.com/tahoe-lafs/tahoe-lafs.git> trac/repos/tahoe-lafs.git` 10. Create missing folders (e.g.: `trac/thaoe-lafs/log`) 11. Patch `trac/tahoe-lafs/conf/trac.ini` 12. Gain admin access (if needed): 1. `docker-compose run --rm --entrypoint bash trac` 2. `trac-admin tahoe-lafs` 3. `permission add <username_here> admin` 4. `exit` and `exit` 13. Start the local Trac: `docker-compose run --rm trac` 14. Login on <http://localhost:8000/tahoe-lafs/login> 15. Edit the <http://localhost:8000/tahoe-lafs/wiki/WikiStart?action=edit> page to replace link: `/~trac/` -> `../chrome/site/` or transform them as attachment These steps will likely be improved with more iteration, but they should help reproducing a workable environment to actually test/start the migration.

btlogy commented

2024-06-11 10:18:29 +00:00

While the execution phase has already been started (test of migration to Gitea), we'd better agree on the final definition of the scope and the deliverables so we can plan the actual migration:

Scope of the migration:
- INCLUDES:
  - 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)
- EXCLUDES:
  - Binary repository for Tahoe-LAFS releases (https://tahoe-lafs.org/downloads)
  - 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 4 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 repository defining the VPS it-self and its configuration as code (including the secrets)
2. A detailed migration plan to handle the transition (DNS changes and/or redirections)
3. An high-level migration plan for the 3 first features above to be later hosted on Codeberg SaaS (assuming it is possible)

I'll discuss this proposal in the next Nuts&Bolts meeting (Tue 11th of June).

While the execution phase has already been started (test of migration to Gitea), we'd better agree on the final definition of the scope and the deliverables so we can plan the actual migration: * Scope of the migration: * INCLUDES: * 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) * EXCLUDES: * Binary repository for Tahoe-LAFS releases (<https://tahoe-lafs.org/downloads>) * Other Trac projects (see [DevInfra](wiki/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](wiki/DevInfra) * Deliverables: 1. A VPS (hosted by Hetzner) providing 4 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 repository defining the VPS it-self and its configuration as code (including the secrets) 2. A detailed migration plan to handle the transition (DNS changes and/or redirections) 3. An high-level migration plan for the 3 first features above to be later hosted on Codeberg SaaS (assuming it is possible) I'll discuss this proposal in the next Nuts&Bolts meeting (Tue 11th of June).

Sign in to join this conversation.