The "Cylc Review" web services display suite job logs and other information in web pages. To click through tasks in your collaborators' suite runs, you need to start the web service inside your persistent session. As long as you have the permission to view their ~/cylc-run  directory and the corresponding suite job logs, you can monitor the job progress as a team. 

Start the Web Service

To launch `cylc review` service in a persistent session, follow the example below. You can remotely launch the web service from any Gadi login nodes or ARE VDI sessions. In this example, the user jpg777 has already a meta-scheduler session called `demo.jpg777.hr22.ps.gadi.nci.org.au` running under the project hr22, please replace them with your own details. If you don't understand those details yet, please have a look at this page first.

ssh demo.jpg777.hr22.ps.gadi.nci.org.au ~/launch_cylc_review

where the `launch_cylc_review` script reads as

$ cat ~/launch_cylc_review 

#!/bin/bash
module use /g/data/hr22/modulefiles
module load cylc7/23.09
cylc review start 1234

with the file permission 

$ ls -l ~/launch_cylc_review
-rwxr--r-- 1 jpg777  90 Aug 29 16:45 /home/777/jpg777/launch_cylc_review

Now the service should start at `http://demo.jpg777.hr22.ps.gadi.nci.org.au:1234`. If you want the service to be hosted on another port, please change the number `1234` in the file `~/launch_cylc_review`. The replacement can be any integer between 1024 and 65536. 

Access the Web Interface

First,  start an VDI session. To do so, please go to ARE site: are.nci.org.au, and

• Fill out the VDI request form
• Walltime (hours): 1
• Queue: normalbw
• Compute Size: tiny
• Project:  <project>
• Storage: <any storage string for project(s) needed for other tasks>

• Click Advanced options and fill in the following fields
• Jobfs size: 10GB  

• Click the button "Launch" 
• Click the button “Launch VDI Desktop” when the session is ready

Given that the main task is to look up suite progress in a web browser, the actual VDI session requests only a single Broadwell CPU core and 4.5GiB memory.  In case any temporary files need to be created on the local disk, it requests 10GiB storage on the compute node. 

Please replace "<project>" with the real project code and the storage string with any necessary ones. For example, if you plan to do any other tasks inside the VDI session require access to `/g/data/dk92` and `/scratch/ab01`, fill in the "Storage" field with the string "gdata/dk92+scratch/ab01". For the task of monitoring suite progress itself, it doesn't require any storage access.

Once inside the VDI session, the window is very similar to the one shown below. Click the Firefox icon to launch a browser. 

and type in the address <hostname>:<port>. An example is shown below. The exact address is user and session specific, but the structure should be very similar. 

Notes on Permissions

To allow your colleagues looking up the progress/result of your jobs through the cylc review interface, we recommend to set $HOME directory with the permission 711. It maximises the protection while enabling the collaboration. The 711 permission is enough for your collaborators to stat your $HOME/cylc-run directory without risking to over expose all the children directories inside your $HOME directory to them.

If you don't want to share all the suites inside your $HOME/cylc-run directory, we recommend to further set the permission of your $HOME/cylc-run directory to 711. In this way, only the members of the project which runs the suite can find details of the relevant suites. That is to say, no one but yourself can see the entire list of your suites through the url <hostname>:<port>/suites/<user>. The file permission stops their access to complete list. Instead, your colleagues can look up the progress of a suite through urls such as <hostname>:<port>/taskjobs/<user>/?suite=<suite> and <hostname>:<port>/cycles/<user>?&suite=<suite> as long as they have the right group permission to access the corresponding files and directories inside the corresponding project directory on /scartch  and/or /g/data.

To summarise, with the permission 711 set to both the directory $HOME  and $HOME/cylc-run, the accessibility of urls pointing to your suite job logs looks like 

relative path to <hostname>:<port>/	accessibility to others	who get access
suites/<user>		self
taskjobs/<user>/?suite=<suite>		project members
cycles/<user>?&suite=<suite>		project members

If you find this recommendation is too abstract, please read through the following example.

Permission Example

Assuming the structure of the $HOME directory of the user jpg777 reads as the following.  

and the permissions set to the relevant directories are

$ ls -ld /home/777/jpg777
drwx------ 42 jpg777 ab01 8192 Aug 28 15:34 /home/777/jpg777
$ ls -ld /home/777/jpg777/cylc-run/
drwxr-xr-x 2 jpg777 xy89 4096 Aug 23 15:59 /home/777/jpg777/cylc-run/

By default, all $HOME directories on Gadi are set to 700 allowing no access by other Gadi users. If you are not familiar with posix permissions, have a look at this page in the Gadi User Guide.

To change both of them to the recommended 711, run

$ chmod g+x,o+x /home/777/jpg777
$ chmod g-r,o-r /home/777/jpg777/cylc-run

and the current permission should read as

$ ls -ld /home/777/jpg777
drwx--x--x 42 jpg777 ab01 8192 Aug 28 15:34 /home/777/jpg777
$ ls -ld /home/777/jpg777/cylc-run/
drwx--x--x 2 jpg777 xy89 4096 Aug 23 15:59 /home/777/jpg777/cylc-run/

Once these two permission is set, no one but the user jpg777 can read the `/home/777/jpg777/cylc-run` directory, and therefore, no one but jpg777 can reach <hostname>:<port>/suites/jpg777. The file permission blocks others' access.

For the individual suites u-cz168 and u-cs809, because they are symlinks to the project directory on /scratch, the access to any files and directories inside them are defined by the permission set in their corresponding /scratch project directory.

By default, the project directory is set to have the permission that enables collaborations within the project and forbids access from outside the group. No action is needed if you want to share the suite result and progress with the corresponding project members.

Take the suite u-cz168  as an example, it runs under the project ab01, and the symlink points to /scratch/ab01/jpg777/cylc-run/u-cz168.

$ readlink -f ~/cylc-run/u-cz168/
/scratch/ab01/jpg777/cylc-run/u-cz168

On the project directory level, it gives every member of the project ab01, read, write and execute permissions.

$ ls -ld /scratch/ab01/
drwxrws--- 9 root ab01 4096 Aug 28 17:23 /scratch/ab01/

and inside the directory for jpg777, the project members have only read and execute permissions. Please note here, non ab01 members cannot access the directory /scratch/ab01/jpg777 as their access is stopped at the level `/scartch/ab01`.

$ ls -ld /scratch/ab01/jpg777
drwxr-sr-x 9 jpg777 ab01 4096 Aug 23 13:10 /scratch/ab01/jpg777

Both the directories `/scratch/ab01/jpg777` and `/scratch/ab01/jpg777/cylc-run` by default inherit the permission from their parent directory.

$ ls -ld /scratch/ab01/jpg777/cylc-run
drwxr-sr-x 9 yxs900 fp0 4096 Aug 28 17:23 /scratch/ab01/jpg777/cylc-run
$ ls -ld /scratch/ab01/jpg777/cylc-run/u-cz168
drwxr-sr-x 9 yxs900 fp0 4096 Aug 28 17:23 /scratch/ab01/jpg777/cylc-run/u-cz168

This project directory default permission allows read and execute by members of project ab01, therefore, they by default have the access to the suite details through <hostname>:<port>/taskjobs/jpg777/?suite=u-cz168 and <hostname>:<port>/cycles/jpg777?&suite=u-cz168.

In the same way, members of the project xy89 can access details of the suite u-cs809 through the webpages <hostname>:<port>/taskjobs/jpg777/?suite=u-cs809 and <hostname>:<port>/cycles/jpg777?&suite=u-cs809 while they cannot see details of the suite u-cz168 through neither <hostname>:<port>/taskjobs/jpg777/?suite=u-cz168 nor <hostname>:<port>/cycles/jpg777?&suite=u-cz168 because they don't have access to the directory `/scratch/ab01` if they are not also a member of the project ab01.