tacaswell
commented
3 months ago Another benefit of a second service living in the same code base is that it can leverage the same config files to keep all the (user facing) names in sync.
I am very concerned about the prospect of adding the ability to subscribe to PVs via the same process that hosts the executing RE. One possible issue is that the user subscribes to a very noisy signal and the RE process gets swamped handling that to the detriment of its main job (running plans). A second concern is that if the worker is running a plan and the user tries to set a PV it is reasonable to expect that the PV value will change right away (as it would if they poked at CSS while a plan was running). If the process that is hosting the RE is also responsible for servicing PV tweaks, then either we have to go even-farther in on concurrency (maybe OK, but adds complexity we don't need) or to defer setting PVs until the plan is done (which at that point, just put it on the queue!)
Submitting this issue that is the result of many recent discussions with many people over the last few days.
When running a measurement it is always useful to additionally have a live/prompt update of parameters like ring current and shutter status. These are critical to knowing whether the experiment can be started and help to understand why it has stopped. This should update even while plans are being run by the queueserver, implying a connection to the device which bypasses the queueserver.
Additionally there are cases where it would be useful to change the parameters of a given device (change integration time of a detector, or gain etc). This can be performed using a set or
configureplan being passed to the queueserver. This only needs to be called when the queuserver is NOT running a plan. It can be called withqueueserver run_immediately set ….Finally sometimes a user does not have a script for aligning or maximizing/minimizing a parameter and instead they want to tweak a motor and observe the output of a detector (0 or 1 or 2D) and use this to find some optimal setting before the start running a plan.
The queue server contains an http server that provides the ability to see and modify QS plan state. To make a fully useful application, several facilities have created their own http service (generally RESTful) exposing ophyd call to http, that allows the user to do things like random motor movements.
Proposal: Add endpoints to the Queue Server http service to all of for sets and gets. Putting this into the Queue Server directly rather than writing a separate http/zmq bridge allows the service to take advantage of several key pieces of the Queue Server infrastructure: The service can take advantage of the same authentication and authorization infrastructure that was built into the Queue Server Building on to authorization, the service can take advantage of the Queue Server list of ophyd devices that the user has access to.
At a meeting at NSLS-II last week, we talked about a few architectural ideas.
One idea (@tacaswell ) was to distribute this as a separate process using the same code base as a way to use the common authorization functionality. We also discussed the possibility of using an ApI gateway, saving each individual component of the queueserver from having to carry the weight of authentication (though they still have to deal with authorization in their own way.)