List view
We currently have a number of clean up tasks implemented as cron jobs. This milestone is about implementing a dedicated janitor service (say, `grid_janitor.py`) , which apart from handling our current cron clean up tasks should also take over the vgrid cache updates and check that pending requests are valid and mark or simply reject them if not. The current client-driven concurrent vgrid cache updates with http timeout after 300s are fragile and inefficient. They should really be replaced by a single handler without such time limits. The janitor would be an obvious place for taking care of the updates in a simple and efficient way. It can be adjusted to use memory caching of owners and members in `mig_system_run` for better performance when netfs is a bottleneck. Site operators report that there's quite a bit of overhead in the existing account handling process and in several cases simple errors or mismatches render the process moot midway through. E.g. if the user already has an account with a slightly different ID or if trying to renew an expired account and not providing the existing password to authenticate it. The janitor could therefore check pending requests and detect password mismatch, ID clash and invalid peers for starters. Having password checks in a detached service like that rather than during form submission also allows delaying the check/reject long enough for password guessing that way to remain infeasible. On-going work to simplify account renewal and password change from the Accounts page will reduce some of the hurdles in account handling but this service would still help reduce the remaining nuisances.
No due date•0/1 issues closedWe have decided to begin moving scripts from `./`, `./mig/` and `./mig/server/` into the new FHS-compliant and easier to find `./bin/` at the root. Similarly the service launchers in `./mig/server/` and any other system or service executables will migrate into `./sbin/` . In relation to the move we have also decided to introduce a `./mig/lib/` for hosting supporting code modules or collections of such in sub-directories. We will use the opportunity to clean up and lint the modules migrating there and add github actions to monitor for regressions once there.
No due date•2/2 issues closedWith Python officially unsupported upstream and vendors only providing important security fixes for it we need to migrate completely to Python3 ASAP. The core code base is mostly ported in terms of the backends and facilities related to general data handling, but especially the original grid compute parts are less tested on Python3. We're testing and weeding out any remaining issues on development systems and a few smaller production sites. Any issues related to the original complete grid compute stack should be gradually tested and handled here.
Due by December 31, 2025•9/10 issues closedWe have gradually phased in OpenID Connect authentication support in the migrid stack and will continue in that direction. There are some rough corners and missing pieces in relation to completing the move away from OpenID 2.0 completely. This milestone tries to sum up and work as an umbrella for the associated tasks. * The built-in _external_ user account auth handling implemented in grid_openid is OpenID 2.0 - we need a corresponding grid_openidc service * Jupyter sessions fail ("Protected Location") on OpenID Connect (e.g. `Start DAG`) unless also logged in on OpenID 2.0. * OpenID Connect login currently does _not_ auto-renew _local_ user accounts like OpenID 2.0 logins does. * Explicit sign up should no longer be necessary for _local_ users with OpenID Connect * Log out may or may not be completely supported - in particular with WAYF OpenID Connect * Further testing of _local_ user OpenID Connect sign up and handling of affiliation+role values is needed
Due by September 1, 2025•11/11 issues closedWe are in the process of updating the user interface and polish various details both in relation to user feedback and to address our own findings. This milestone is an umbrella to group all such user interface updates and improvements.
No due date•6/12 issues closedHaving the full X509 distinguished name as primary user ID and a slightly modified version for the on-disk home directory made sense back when migrid started and relied on user certificates, but with the introduction of other authentication methods etc. it has become ever more clear that it introduces artificial limitations and complicates quite a few things in the stack. We're looking into reworking the handling of IDs and home directories to sever that rigid binding. Changing it now of course is a bit tricky because quite a few places in the code and Apache setup more or less clearly make assumptions about it being so. Still it makes a lot of sense to proceed to allow things like easy adjustment of user affiliation fields without e.g. a costly full home directory renaming.
No due date•3/4 issues closedWith Python officially unsupported upstream and vendors only providing important security fixes for it we need to migrate completely to Python3 ASAP. The core code base is mostly ported in terms of the backends and facilities related to hosting general research data. We have basically ported the components related to hosting sensitive data as well, but it needs more testing to discover and fix any remaining issues. We're testing and weeding out any remaining issues on development systems and will continue with production sites. Any issues related to the basic research data and the original complete grid compute stack should be gradually tested and handled in the separate milestones for those parts specifically.
No due date•43/46 issues closedWith Python officially unsupported upstream and vendors only providing important security fixes for it we need to migrate completely to Python3 ASAP. The core code base is mostly ported in terms of the backends and facilities related to hosting general research data. We're testing and weeding out any remaining issues on development systems and a few smaller production sites. Any issues related to the original complete grid compute stack should be gradually tested and handled in the separate milestone for that part specifically.
No due date•62/78 issues closed