Questions about cylc-8 usage
The following lists a whole bunch of assumptions/hopes about how Cylc8 might run for us in production. Due to my not being able to have 2 images in one post, I will respond to this with how we use Cylc7 in production to provide context.
- All of the relevant machines on this diagram are generally on the same network and can talk to each other.
- Cylc8 is installed on all of the blue VMs, including the new light-blue Cylc8 virtual machines (plus as necessarily on the HPCs as well).
- Only the workflow machines (in the special box) run suites and submit jobs to PBS and thus to the HPCs.
- Systems Administrators directly install suites onto the workflow machines via the command line.
- How do the UI servers get connected to installed (and potentially running) suites?
- Suites run with the permissions of certain production realm accounts. For example the atmosphere user might “own” 10 suites, and the oceans user might “own” 5 suites etc etc.
- JupyterHub can run UI servers locally and on configurable extra VMs (hence the second light blue circle). I am not concerned if the remote UI servers are not possible, but earlier documentation suggested they are/were.
- Suite Owners can log into JupyterHub – as themselves - and scan and find all available suites (just like logging into a machine and running gscan) even where they don’t have write-access to those suites (just like with gscan). The can filter by user/workflow-vm/other filterables, or searching for suite name. Suite owners cannot perform edit runs, change the suite.rc.processed via edit functionality or do any other edits on production suites (because they cannot raise their privileges to the realm account).
- Suite Owners don’t have to log out and log back in again or clear their cookies to view other suites running as different production users because it’s just read-only (just like with gscan and the cylc GUI).
- Support Staff can connect to JupyterHub and scan and find all available suites, with the same filtering as above, and make limited changes (pause, restart, change environment variables in edit runs…) to all the suites they have permission to affect.
- Support Staff don’t have to log out and log back in again or clear their cookies to act as different production users.
- Ideally we’d be able to use their Active Directory roles as an indication of which production users they can act on behalf of. (Edit authorisation needs to be checked both at the GUI level and again at the cylc daemon level, so the user’s Active Directory roles will have to be passed to the daemon as well, while being as minimally spoofable as possible.)
- For example Bob might be able to affect all suites running as atmosphere, while Jane might be able to affect all atmosphere and ocean suites.
- It would be good if cylc-8 allows for any equivalent of “user” and “acting-as user” and always check the permissions of the “acting-as user” for authorisation with a default that “user” and “acting-as user” are identical, but allow authentication/authorisation plugins that differentiate
- Systems Administrators can do everything Support Users can and more, with full GUI functionality as well using command line access when necessary.
- Suite interactions via the command line also check for user authorisation – with the same “user” and “acting-as user” style plugin or equivalent.
From a user (suite-owner, systems administrator, support staff) point of view, given the above, what are the UI servers? Who needs to know about them?