Plan for migration of servers

[drikusroor]

Right now we have a collection of old & new servers at our disposal. The old servers run a linux distribution that is not supported anymore and should be migrated to the new servers with a new linux distribution. This is supposed to happen before June 2024 as the old servers will be turned off due to security reasons. Some servers / applications have already been migrated (the AML website) or are in the midst of being migrated (MUSCLE test environment). Let's try to make clear which applications should be migrated to which servers, which applications we don't need anymore, which new servers we need. Perhaps this discussion can function as a plan and status document en can thereby help us do the migrations in an orderly fashion. I, or anyone who wants to can update this document whenever the plan or status needs to be updated.

Current situation / status (Feb 14, 2024)

Old servers

⚠️ illc-aml

This server can be archived already

• hooked.amsterdammusiclab.nl (experiments running from the hooked-on-music-server and hooked on music-client repositories) Do we still want to support this website/application?
• www.amsterdammusiclab.nl (the website) *The website is already migrated to a new server but still runs (inaccessible) on this server. I guess we can remove this from the server, right?
• https://api.amsterdammusiclab.nl/admin (the admin) What is this? The API for hooked?

⚠️ illc-aml2

• app.amsterdammusiclab.nl (our current production server for MUSCLE)

⚠️ illc-aml3

• toontjehoger.amsterdammusiclab.nl (only Toontjehoger games) Do we still want to support this application?

⚠️ illc-aml-acc

• acc.amsterdammusiclab.nl (acceptance environment MUSCLE)

New servers

✅ illc-aml-web

• (www.)amsterdammusiclab.nl will redirect here once set up Update: This has already been done
• Also reachable via https://illc-aml-web.science.uva.nl

✅ illc-aml-tst

• https://illc-aml-tst.science.uva.nl and https://tst.amsterdammusiclab.nl The MUSCLE application already runs on here, CI/CD works, but the PR hasn't been finished/merged yet.
  • Do we need to copy the data from Acceptance to this server or can we just start with a clean slate?

New servers we probably/may need

• illc-aml-acc-new - New MUSCLE Acceptance server
• illc-aml-prod-new - New MUSCLE Acceptance server
• 0 or more server(s) for hooked, api.amsterdammusiclab.nl, and toontjehoger

Plans / proposals / to do

Proposal 1

• If we want to keep the "old" applications (hooked, toontjehoger), should we move them to a single machine, just let them run there and never touch them? Something like illc-aml-legacy perhaps.

Plan for MUSCLE Test environment

• Request the new MUSCLE Test server (illc-aml-tst?)
• Create a Podman configuration for it.
  • The Github workflow automatically deploys every push to the develop branch
• Finish & merge PR

Plan for MUSCLE Acceptance environment

• Request the new MUSCLE Acceptance server (illc-aml-acc-new?) as a replacement of illc-aml-acc
• Create a Podman configuration for it (based on the one for the Test environment tst.amsterdammusiclab.nl)
  a. [ ] The Github workflow deploys to Acceptance after a "release/tag" has been created, and does not require an admin to approve running the workflow
  b. [ ] Or, alternatively, The Github workflow automatically deploys after every push to main and every "release/tag" and a manual trigger (workflow dispatch)
• (Optional) Migrate data from database as well

Plan for MUSCLE Production environment

• Request the new MUSCLE Acceptance server (illc-aml-prod-new?) as a replacement of illc-aml2
• Create a Podman configuration for it (based on the one for the Test environment tst.amsterdammusiclab.nl)
  • The Github workflow deploys to Production after a "release/tag" has been created, and always requires an admin to approve running the workflow (so we can test on Acceptance first)
• (Required) Migrate data from database as well

@jaburgoyne @BeritJanssen @Evert-R @albertas-jn (I'll tag & spam all of you)
Please let me know what you think, if you have questions, or anything that pops up in your head while reading this. 😄

[BeritJanssen]

This sounds reasonable!
As for your questions:
illcaml server can actually already be archived, all content that was on there has been migrated. The api route was indeed to access the admin interface. We now do this with deep routing instead, but if somebody should decide to give their experiment the slug "admin" they're in for a surprise... Will make an issue of that.

As for illc-aml3: the intention is definitely to support Toontjehoger longer. A children's version of Toontjehoger will even be launched. My work on #606 is actually also in preparation for integrating the Toontjehoger code fully again. That being said, we should still decide whether Toontjehoger should keep its dedicated server. If integration is finished, this may actually not be necessary. One special aspect about Toontjehoger is that it has educational purposes, so whatever Toontjehoger writes to the database will not be used for research. We can defer the decision about Toontjehoger until April, then decide whether we want to keep the old server in the air for the Snaartjes festival (which will have the children's version), set it up on the production server, or even go for a new dedicated server. I also don't think that EOL for CentOS necessarily means that June is a hard deadline for migration, just that as time progresses after June, we'd be getting into less stable territory.

As for the steps: I agree completely: test deploys are triggered by merges to develop, acc by merges to main, and production by/after admin approval from main. The steps for test may already be partially checked off, I believe? At least the server is already a RedHat one. Perhaps the suffix could be rdh for RedHat, instead of new? With Linux distributions' support coming and going, I don't think this is the last server migration the MUSCLE app is going to face. So the new server will be the old one in a couple of years' time.