component version compatibility

[hjoliver]

We need a strategy to handle cross-component version compatibility.

We can make a Cylc meta-package that installs the right, compatible, versions of all components at once, but that doesn't solve the problem of already-running workflows at a large site: new version of Cylc UI and UIS have to be able to handle older WFS versions nicely.

[hjoliver]

(taken from Riot chat post by @oliver-sanders):

GraphQL schema and versioning...

The UIS provides one GraphQL endpoint for the UI to connect to. The schema for this endpoint is imported from the associated installation of Cylc Flow.

This means that we can represent all workflows with a common schema allowing cross-workflow subscriptions etc. The downside is that in reality each workflow could be running under a different Cylc Version and so have a different schema.

So the UIS becomes the translation layer, when schema changes happen back-compat gets written there to upgrade old schema and fit them into the new model. Because we are using protobuff between the UIS and WS it's not changes in the GraphQL schema but the protobuff schema we need to protect against but it's the same concept.

This approach makes sense, the UI gets a nice stable GraphQL schema to work with. The issue is when we want to handle compatability at the UI rather than the UIS.

At the moment I'm working on mutations in the UI and the whole api-on-the-fly stuff. For this we need the UI to use the same GraphQL schema that the WS is running so that we are working with the correct set of mutations.

So how to give the UI access to this?

• Don't, always use the most contemporary schema.
  • Unhelpful as it could offer functionality which isn't available or conflicting documentation.
• Add new GraphQL endpoints at the UIS.
  • Makes cross-workflow mutations a conceptually interesting.
• Serve the Schema as a JSON object via a new endpoint at the UIS.
  • Mutations get sent to the UIS as JSON, the UIS does the rest.
• Something else?

For the moment I'm working with the GraphQL schema the UIS provides which is fine for now but towards 1.0.0 we will need to work out what the long-term plan is here.

[hjoliver]

response from @dwsutherland
I think Matt mentioned, and I agree; the WFS should be restarted by the UIS if the API version is incompatible to keep uniform (or ignored? as is done now)...

Does/should the hub version dictate the UIS version? And hence the versions seen by the UI? (or are we thinking cross hub?!)

response from @kinow
What I have seen is the client be aware of the server version, and fail if it's not a supported version.

@oliver-sanders again

Well that would be nice from our perspective, don't think that our users would agree necessarily. We will introduce breaking changes which mean this isn't an option between certain versions, at present we have no way of recording what those versions are.
I think the new UI infrastructure should be able to support any Cylc8 suite (perhaps with certain limitations).
We will accumulate some back-compat in the UI Server during the lifetime of Cylc8 (providing default values to new values in the GraphQL schema or whatever) which we can drop at Cylc9.
(but it would be pretty awesome if users could restart their suite under a more recent version via the UI)

[oliver-sanders]

This issue is now a bit outdated, the hub version is now irrelevant, the compatibility issue between flow-uiserver-ui remains.

At the time of writing, the UIS presents a single GraphQL schema to the UI. The UI only sees the UIS schema (not the workflow's actual schema) so the mutations, their options and documentation come from the UIS version. Issue to resolve this:

cylc/cylc-ui#1225

I've created an issue for the auto-restart problem:

cylc/cylc-uiserver#423

Closing as superseded by these issues.