Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

aotf: load the schema for each workflow #1225

Open
oliver-sanders opened this issue Feb 6, 2023 · 2 comments
Open

aotf: load the schema for each workflow #1225

oliver-sanders opened this issue Feb 6, 2023 · 2 comments
Milestone

Comments

@oliver-sanders
Copy link
Member

See also cylc/cylc-uiserver#419

Presently the UI loads the UIS schema from which it gets the list of mutations.

This means that if the UIS is talking to two schedulers with different mutations (e.g. different Cylc versions), then mutations issued to one of the two will be drawn up with the wrong schema and will fail if the interfaces differ.

Rather than loading the schema once per-app, we should load it once-per-workflow.

Note: Since the AOTF work was put in, we have come to rely on introspection for the edit-runtime forms too, the same problem applies here also.

Pull requests welcome!

@oliver-sanders oliver-sanders added this to the Pending milestone Feb 6, 2023
oliver-sanders added a commit to oliver-sanders/cylc-ui that referenced this issue Feb 6, 2023
* Closes cylc#1222
* Note this solution is hardcoded in the UI and must stay that way
  until cylc#1225 is done.
@dwsutherland
Copy link
Member

dwsutherland commented Feb 24, 2023

Since the UI only interacts with the UIS, how does it make sense to load a scheduler schema that might be incompatible with the UIS?
(even if the UIS is just a pass-through for most mutations, can we guarantee this will always work?)

@oliver-sanders
Copy link
Member Author

oliver-sanders commented Feb 24, 2023

Providing that the UIS passes the mutations through to the scheduler without meddling with them this should work fine.

  • The scheduler declares its capabilities.
  • The UI requests actions based on those capabilities.
  • The UIS acts as a forwarding layer passing these requests on to the scheduler.

The design and motive are documented here - cylc/cylc-flow#2123

tldr; We keep fiddling the workflow interfaces for valid reasons, adding mutations, options, etc. But our users have valid reasons for working with different versions of Cylc simultaneously (e.g. research & production workloads). This has caused a number of problems with GUIs over the years and has made user-facing documentation tricky.

Note this is only for mutations, for queries / subscriptions the only thing we can do is to add back-compat in the UIS and try to handle forward compatibility breakages gracefully. In general we should expect the UI/UIS to be running at more recent versions. Related ideas (not documented anywhere yet):

  • Hub service to shut down inactive UI Servers.
  • UIS service to restart old schedulers with newer versions of Cylc.
  • UIS to list workflows which are running with incompatible versions (due to schema changes), UI to mark them as incompatible in the GScan view.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants