List view
The `production` container deployment already splits the `migrid` stack into a number of containers each handling one or more services. If possible it should be further compartmentalized for maximum granularity while of course not breaking fundamental internal service and state dependencies. This will require some adjustments and maybe even redesigning of internal migrid state and communication, which is mostly file system and ''named pipe'' based. Additional preparations are needed for completely distributed deployment of the containers onto separate hosts/VMs. Namely, it must be clarified exactly which shared state and communication takes place and how one can support the same when containers don't necessarily run on the same physical host or VM. This includes documenting and perhaps supplying an outline of such a distributed setup defining which file systems or folders must be shared or synchronized between containers. Perhaps this can in time be extended to a proper swarm-based deployment. The mig_system_run folder is one example of a folder that needs to be shared between containers for the internal account status and expiry to remain consistent across the stack. Rate limits and authentication notifications should also be considered in that context.
No due date•2/4 issues closedWe would prefer to move away from the slightly cumbersome and potentially less secure Docker setups to the native Podman container infrastructure shipped e.g. with RHEL/CentOS/Rocky. It is already possible to build and run the different container flavors as `root` with Podman on Rocky 8 and 9. The build process is [slow](https://github.com/containers/podman/issues/13226) compared to Docker even with the `overlay` driver and there may are still a few other rough edges.
No due date•2/2 issues closedWe've introduced a `rocky8` flavor of Dockerfile to provide `migrid` in Rocky8 containers. With Rocky8 moving from Python2 to Python3 and some of the dependencies we rely on gone it requires some work and testing to stabilize the set up. With CentOS7 going EoL on June 30th 2024 we need to move to Rocky so at least this 8.x series. Standard data migrid sites run well on Python2 and have been tested more with Python3. So they should mostly be no problem running on Rocky8. Sensitive data migrid sites run well on Python2 and only gained Python3 support more recently. So they may need more care and testing on the Rocky8 platform.
Overdue by 1 year(s)•Due by June 1, 2024•2/2 issues closedWe've introduced a `rocky9` flavor of Dockerfile to provide `migrid` in Rocky9 containers. With Rocky9 completely dropping Python2 support and some of the dependencies we rely on it requires some work and a lot of testing to stabilize the set up. With CentOS7 going EoL on June 30th 2024 we need to move to Rocky and if possible this 9.x series. Standard data migrid sites have been tested more with Python3, so they should mostly just run. Sensitive data migrid sites only gained Python3 support more recently, so they may need more care and testing on the Rocky9 platform.
No due date•13/17 issues closed