Seen today in firefox devtools, running UI 2.0.0 out the last conda releases:

Warning: fragment with name WorkflowData already exists.
graphql-tag enforces all fragment names across your application to be unique; read more about
this in the docs: http://dev.apollodata.com/core/fragments.html#unique-names index-4d6c7840.js:174:5631
Warning: fragment with name Deltas already exists.
graphql-tag enforces all fragment names across your application to be unique; read more about
this in the docs: http://dev.apollodata.com/core/fragments.html#unique-names index-4d6c7840.js:174:5631
Warning: fragment with name AddedDelta already exists.
graphql-tag enforces all fragment names across your application to be unique; read more about
this in the docs: http://dev.apollodata.com/core/fragments.html#unique-names index-4d6c7840.js:174:5631
Warning: fragment with name UpdatedDelta already exists.
graphql-tag enforces all fragment names across your application to be unique; read more about
this in the docs: http://dev.apollodata.com/core/fragments.html#unique-names index-4d6c7840.js:174:5631
Warning: fragment with name AddedDelta already exists.
graphql-tag enforces all fragment names across your application to be unique; read more about
this in the docs: http://dev.apollodata.com/core/fragments.html#unique-names index-4d6c7840.js:174:5631
Warning: fragment with name UpdatedDelta already exists.
graphql-tag enforces all fragment names across your application to be unique; read more about
this in the docs: http://dev.apollodata.com/core/fragments.html#unique-names index-4d6c7840.js:174:5631
Warning: fragment with name PrunedDelta already exists.
graphql-tag enforces all fragment names across your application to be unique; read more about
this in the docs: http://dev.apollodata.com/core/fragments.html#unique-names index-4d6c7840.js:174:5631

Node 16 is hitting end of life soon.

Make sure you're able to work with Node 18+ (note even numbers = long term support, odd numbers = more experimental).

mamba install nodejs=18

Multi-user hub work at BOM

Heads up, I just got a demo from Jacinta and Jez at BOM on their progress with the hub. A quick summary from what I understood:

• Hub config: define groups of users who are allowed to see others' servers
• When you log in to the hub, you see a hub-admin-like page with a table of those users, and buttons to start and connect to their servers
• Ideally the hub groups would flow through to UIS authorization, so we don't have to double up on the config
• The new page is injected into JupyterHub without changing Hub or Cylc code 🎉 via React templates (J-Hub is React based).
• The new page will need to be bundled with cylc-uiserver, like cylc-ui is
• It will presumably need its own repo (and build) under the Cylc org on GitHub. (However, before then, Jez may need to get permission or rewrite some code taken straight from the JupyterHub project)

Long story short, this looks really good to me.

I have encouraged jarich and Jez to engage with the team on next steps.

A demo and discussion at the upcoming project meeting might be possible, by Jacinta if not Jez, bearing in mind that 7 am in Melbourne might not be feasible.

I've asked Jez to copy his internal docs either to here or to a short proposal on cylc-admin.

When you log in to the hub, you see a hub-admin-like page with a table of those users, and buttons to start and connect to their servers

Presumably only admin users see this table?

Sounds good.

When you log in to the hub, you see a hub-admin-like page with a table of those users, and buttons to start and connect to their servers

Presumably only admin users see this table?

Sounds good. Might be interested in seeing a demo at a Cylc VC.

When you log in to the hub, you see a hub-admin-like page with a table of those users, and buttons to start and connect to their servers

Presumably only admin users see this table?

Note, with the latest Cylc / Jupyter component versions:

• Any user can now be granted permission to spawn another user's server.
• To do this, they open the GUI and type the other users username into the box in the top left and press go.
• In the next release this dropdown box will remember previously entered values (storing them in browser LocalStorage).

(It might be useful in cases where you login as a user which doesn't have a local account so can't run the uiserver?)

They would presumably have to authenticate in order to view this page. Note that users do not require a local account to authenticate with Jupyter Hub as there are other Jupyter Hub authenticators which do not rely on PAM.

Presumably only admin users see this table?

Nope, you don't have to be a hub admin. You don't see other admin-y options such as shutting down the hub.

To do this, they open the GUI and type the other users username into the box in the top left and press go.

Yes, which is really just a much nicer way of doing what we could do already by manually typing the other user in the browser URL bar.

We'll have to ask the BOM peeps, but I think what they're getting at is central hub config that determines the list of other users that you see in the table. If so, that seems quite nice to me. You don't have to know the exact user name and type it in manually.

Obviously we could tweak it so that going straight through to your own UI Server first is an option, or the default, if that's desirable.

They would presumably have to authenticate in order to view this page

Correct.

I just cleaned my _Very Messy_™ ~/cylc-run dir and found that the gui waits a long time in this state:

Might we reasonably close it and replace it with a notification that something is happening which doesn't hog the GUI screen?