Remote access: run read-only client on STFC cloud

Tom-Willemsen commented 4 years ago

As a user working remotely, I would like to be able to monitor my experiment at ISIS.

To do this, I would like to be able to run a read-only client on the STFC cloud.

Acceptance Criteria

Create a definitive list of what is broken by running manual system tests
decide on whether fixing these are a good idea
NB time box for 2 days

Remote access requirements satisfied:

"View hidden items on the web dashboard, but these items remain hidden from public display"
"View the historic values of blocks (e.g. as a graph)"
"View the current script being run and anything being printed from the script" (this assumes running scripts via the script server + https://github.com/ISISComputingGroup/IBEX/issues/3022 being done to allow remote access to NICOS)
"View experiment details e.g. sample parameters, RB numbers"
"View individual device control screens (IBEX OPIs/ SECI LabVIEW VIs)"
"View the table of motors"
"View the IBEX instrument synoptic display"
"View information equivalent to that on the IBEX/SECI Journal Viewer"
"Visualise live neutron data (single spectra)"
"Visualise live neutron area (2D detector live view)"

Notes

This solution applies only to IBEX instruments
The client on linux currently builds and largely works, however there are some known issues which would need solving before this solution can be rolled out:
- Some rendering issues, especially in the blocks view (missing fonts?)
- Some windows-style paths - e.g. to python which would need adjusting to be platform-agnostic
- python doesn't currently start, and this stops instrument switching.

FreddieAkeroyd commented 4 years ago

Currently nicos script output is restricted to only be visible to localhost - this would need changing

FreddieAkeroyd commented 4 years ago

For easier deployment to STFC cloud #5509 would be needed, but is not strictly necessary

FreddieAkeroyd commented 4 years ago

See #5423

Tom-Willemsen commented 4 years ago

Current issues with linux build:

TLDR summary:

Most of the issues are just caused by widgets having a slightly different size under GTK as opposed to windows and their containers no longer being big enough. These should be easy to fix in most cases simply by increasing the size of the container.
Rendering issues in the blocks view and for synoptic PV read/writes
Many OPIs will need some minor adjustment to display nicely, the majority are still usable (but messy)
Some OPIs completely fail to load. Suspect this may be windows-style paths to linking containers and/or scripts.

Detailed list:

[x] The linux build isn't enabled
- Fixed in PR
[x] Instrument switching doesn't work as it indirectly requires python
- Fixed in PR
[x] RHEL7 defaults to using java 8, the client needs java 11
- Solution: bundle linux version of AdoptOpenJDK 11 with the client by placing it in the jre directory next to the executable. Our linux jenkins build will need to do this
[x] The client is not marked as executable by default (this may just be an issue with building the linux client on windows and then transferring it)
- Solution: chmod +x ./ibex-client
[x] Blocks view: rendering issues:
- Fixed in PR - see comment below for details
[x] Beam status perspective: Beam information: composite is not tall enough for it's content
- Solution: increase the height of the composite or look at using a layout which will size itself automatically.
[ ] DAE perspective: Experiment setup: time channels grouping container is not tall enough for it's content. This means that the last few rows are visually cut off for time regimes 4, 5 & 6
- Solution: increase composite height or look at using a layout which will size itself automatically.
[ ] DAE perspective: Experiment setup: data acquisition container is not tall enough
- Solution: increase height
[x] DAE perspective: Run information: labels are not wide enough and some label text is cut off slightly.
- Solution: increase width.
[ ] Device screens: OPIs: many OPIs have extra scroll bars due to content width being slightly different than windows. In most cases the information is still readable but messy. Typical example:
- Solution: to be discussed. I would suggest we try to fix the common OPIs and ask scientists to tell us which other ones need attention, but this is up for discussion.
[x] Device screens: some OPIs fail to open with errors like "pathToFileResource is null".
- These were using inconsistently-cased paths - windows is case insensitive so didn't matter, linux does matter. Fixed in PR
[ ] Experiment details: text is slightly too large for button
- Solution: I think it would be reasonable to ignore this as "not perfect but still usable". Alternatively increase width of button.
[ ] Motors: table of motors requires scrolling to fully see row 8.
- Solution: suggest ignoring this as it can be scrolled to see it. Not many instruments use controller 8 in any instance.
[ ] Scripting: not available as python is not available
- Solution: suggest ignoring this, remote users are unlikely to be running scripts on a read-only machine.
[x] Synoptic: rendering issues in PV read/writes
- Solution: Fixed in PR - same cause as rendering issues in blocks view
[x] Switch instrument menu: custom instrument: composite not tall enough
- Solution: increase height of composite
[x] Help -> About: composite not tall enough to display java path
- Solution: ignore as not important user-facing or increase height of composite

To build/test this:

checkout branch on windows and run build.bat
Copy base\uk.ac.stfc.isis.ibex.e4.client.product\target\products\ibex.product\linux to the babylon5 shares area.
Download AdoptOpenJDK as a .tar.gz and also put it in the babylon 5 area
Get a web/RDP session to a linux system from https://isis.analysis.stfc.ac.uk/ logging in with fedid and/or email address. Choose the smallest available system.
On a linux system, create a dir of your choice and open a terminal in it
Run cp -r "/babylon/Public/<your folder>/linux/gtk/x86_64/"* . to copy over the client
Run chmod +x ./ibex-client to mark the client as executable
Extract the jre .tar.gz that you downloaded so that it is in a directory called jre next to the client executable
Run the client

The automated build is best done as part of https://github.com/ISISComputingGroup/IBEX/issues/5509, which we should do if we want to go forwards with this solution.

Tom-Willemsen commented 4 years ago

The rendering issues in the blocks view were caused by a misuse of the SWT API - in a couple of places we were (indirectly) calling new Composite(parent, SWT.CENTER);. SWT.CENTER is not a valid flag for creating a composite, but unfortunately it shares a value with SWT.EMBEDDED (which tells SWT that this widget is non-native and will be drawn by another renderer). Windows doesn't support other renderers so this bit was being ignored - hence this not being an issue before.

FreddieAkeroyd commented 4 years ago

Great work @Tom-Willemsen. There is a genie python linux build taking shape in #5520, have you found any font issues or are all required fonts available on linux?

FreddieAkeroyd commented 4 years ago

Concerning "Device screens: some OPIs fail to open" - I think OPIs are OK regarding windows paths in linking container, but there were some windows style paths in opi_info.xml which i have pushed fix to branch. May be worth at some point:

creating a schema for opi_info.xml to check for windows paths
though it is not an issue, adding a check to the opi checker python script that opi_file is not a windows path may be worth doing

Tom-Willemsen commented 4 years ago

I've now run out of time on my timebox for this. The remaining known issues are listed above (unticked).

In particular I think the next thing to look at would be tidying some of the "common" opis (e.g. choppers, eurotherms, galils). Once we know which instruments might use this solution in cycle, we can also tidy instrument-specific OPIs as needed.

PR is at https://github.com/ISISComputingGroup/ibex_gui/pull/1141

Note that at the moment there is not an automated build for this - this would be covered by https://github.com/ISISComputingGroup/IBEX/issues/5509 . The instructions for a manual build are at the bottom of my comment above.

FreddieAkeroyd commented 4 years ago

Works pretty well, had one crash on startup with

Gtk-Message: 11:21:51.085: GtkDialog mapped without a transient parent. This is discouraged.

but only once. You get regular nicos zmq connection errors printed in console which I think will go when #3022 is done

FreddieAkeroyd commented 4 years ago

For info, now added Linux build gui and python pipelines, includes jre and publishes results to \\olympic\babylon5\Scratch\IBEX

ISISComputingGroup / IBEX