| 10 Jan 2020 |
 David Sutherland | 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?!) | 03:19:11 |
 @kinow:matrix.org | What I have seen is the client be aware of the server version, and fail if it's not a supported version.
David Sutherland quite sure someone was implementing that for EcoConnect too. Adding a web service in mintaka to return telemetry data about the server. Then the Desktop would alert if you used the V2 client, pointing to a V3 server, for instance (no idea if that's done or if it was discarded).
| 03:53:21 |
| David Sutherland | The UIS could definitely pass on a warning that WFS(s) found at incompatible versions and list them | 08:10:27 |
| David Sutherland | and perhaps give an option to auto-“upgrade”/restart to respective version | 08:12:16 |
| David Sutherland | (although that would fail if the incompatibility is in the stop/restart bits) | 08:13:34 |
| David Sutherland | (however maybe there might be a way of stopping using the target Cylc version) | 08:15:00 |
| David Sutherland | * (although that would fail if the incompatibility is in the stop bits) | 08:15:09 |
| 12 Jan 2020 |
 oliver sanders | In reply to @dwsutherland:matrix.org
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?!) er, heck, okay. 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. | 19:37:54 |
| oliver sanders | I think the new UI infrastructure should be able to support any Cylc8 suite (perhaps with certain limitations). | 19:41:50 |
| oliver sanders | 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. | 19:41:53 |
| oliver sanders | (but it would be pretty awesome if users could restart their suite under a more recent version via the UI) | 19:44:14 |
| oliver sanders | See this issue on Cylc Admin relating to testing for breaking changes between Cylc versions - https://github.com/cylc/cylc-admin/issues/34 | 19:45:20 |
| oliver sanders | We have a habit of introducing these within major versions, for example the parameter interface changed multiple times within Cylc7, not much of a biggie as it was kinda a new / experimental feature not many people were using anyway, but would have resulted in nasty breakages in certain cases. | 19:46:42 |
| oliver sanders | * We have a [bad] habit of introducing these within major versions, for example the parameter interface changed multiple times within Cylc7, not much of a biggie as it was kinda a new / experimental feature not many people were using anyway, but would have resulted in nasty breakages in certain cases. | 19:46:54 |
 Hilary Oliver | Personally I think users have a responsibility to keep up with changes and take action on deprecations. | 20:28:10 |
| Hilary Oliver | (flame bait) | 20:28:17 |
| David Sutherland |
er, heck, okay. 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.
At present we have the WFS API & Cylc version in the contact file, and the UI Server (which the user/organisation chose to run) ignores different API versions.
So as long as the contact file/processing doesn’t break between versions we’ll have a way to know.. | 21:12:13 |
| oliver sanders | The contact file interface is easy enough to maintain, we've kept it stable since introduction. | 21:39:19 |
| 13 Jan 2020 |
| oliver sanders | Is there a way to up the logging for the cylc-uiserver process? | 00:07:54 |
| oliver sanders | I've got GraphQL errors somewhere in the resolvers (f my making) | 00:08:18 |
| oliver sanders | The returned GraphQL error is less than useful | 00:08:55 |
| @kinow:matrix.org | The easiest way, if you have an editable installation (pip install -e), is to try to edit the file cylc-uiserver/cylc/uiserver/logging_config.json | 00:09:45 |
| @kinow:matrix.org | Or change jupyterhub_config.py, specifying an extra --logging-config LOGGING_CONFIG with the path for an external JSON. | 00:10:26 |
| oliver sanders | Should I modify logging.handlers.console.strean? | 00:10:37 |
| @kinow:matrix.org | Looks like it's already set to DEBUG. Actually everything in cylc.uiserver appears to be set to DEBUG already. | 00:11:45 |
| @kinow:matrix.org | And I think the ROOT logger is not used as we are not propagating logs. Is there a logger.info() or some other .debug() statement that is being executed, but not emitting anything to the console output? | 00:12:33 |
| @kinow:matrix.org | (last time I had problems with GraphQL, I remember debugging it with the IDE, and also enabling PYTHONASYNCIODEBUG =1, to get asyncio errors, just in case that's helpful) | 00:13:40 |
| oliver sanders | For a mutation I'm getting this response: | 00:13:46 |
| oliver sanders | {
"errors": [
{
"message": "'name'",
"locations": [
{
"line": 2,
"column": 3
}
],
"path": [
"hold"
]
}
],
"data": {
"hold": null
}
}
| 00:14:15 |
| oliver sanders | (error of my creating) | 00:14:38 |
