MyAEGEE v2

Unmet needs

The micro services architecture is fine, however it is impacting the time-to-deploy at times. Changes that require manipulation of all repos (submodules) are generally rare, but possible - especially for big maintenance.

Additionally, one example maintenance we can envision in this case is the upgrade of traefik from v1.7.4. to v2.x. Traefik v.1.7.4 reached EOL and it should be replaced asap.

 Objectives

1. Have a repository structure where a global change does not involve changing multiple repositories.

   1. This could mean: bring the submodules in MyAEGEE adopting a mono repo way of handling the project

   2. It could also mean: create a repository of MyAEGEE that is exclusively for production use

2. Upgrade traefik to v2.10 and the labels on each exposed container

Dev-prod parity

With this change there is a high chance to have parity between production and development highly swaying: for instance, currently our VMs for development run Ubuntu18.04 LTS (and this should be bumped to 20.04), whereas our production machine is running Ubuntu16.04!

Docker version:

This means that a work to implement in production all the changes should happen soon after the development has been completed.

 Previous attempts

See GitHub - AEGEE/myaegee-nomodules-test: The version of the repository oms-docker that has no submodules. Note: the scope of the repo was for quick infrastructure tests; not for development

Fallback plan

About point 1a: the worst case scenario is to make repos of the submodules read-only, and remove the submodules + re-adding them, therefore losing history “in-repo” and only reading them by going to the archived module.

Alternative plan

We could have GitHub - AEGEE/MyAEGEE: A docker environment to bootstrap the whole membership system renamed to MyAEGEE-dev; and v2 is simply (like) the one previously tested.

Which has a pro point: why should there be code in production?

 Releases (monorepo way)

No matter what is the path we take, we have to make sure about the following:

1. there should be a FEATURE FREEZE for all development

2. The goal for dev-prod parity is set to Saturday night of Autumn Agora i.e. Last weekend of October

3. The released version will be as following

This table means that after releasing v1.37.0 of core, no more code will be checked in/merged and the repo will be frozen. The next changes that can happen is either

1. MyAEGEE v2 will be a monorepo

2. MyAEGEE v2 is a different repo

 Next steps

 Impact

 Other documents