How to configure the QS Host / run the QS as a client?

[prjemian]

3. queuserver host: how is the QS host defined? And follow up question: how do I start the queueserver as a client? does it need a separate/different installation?

Originally posted by @rodolakis in #2 (comment)

[prjemian]

The QS host interacts with redis at this network host:port:

bs_model_instrument/qs/qs-config.yml

Line 13 in dda801d

redis_addr: localhost:6379

QS clients do not need to know about this connection. They interact only with the QS host.

[prjemian]

Right. If the QS host wanted to use the redis service which was running on a different workstation (say example.server.org), then change qs-config.yml as you said:

  redis_addr: example.server.org:6379 

[prjemian]

Basic instructions to run/test the queueserver ...

I'm sure we wrote these instructions in one of the BDP demo presentations. I'll dig that up.

[rodolakis]

I am happy to write those

Basic instructions to run/test the queueserver ...

I'm sure we wrote these instructions in one of the BDP demo presentations. I'll dig that up.

[rodolakis]

So, you ONLY need to change the qs-config.yml?
In this case the I am a bit confused about the comment here in qs_host.sh:

# Host name (from $hostname) where the queueserver host process runs.
# QS_HOSTNAME=amber.xray.aps.anl.gov  # if a specific host is required
QS_HOSTNAME="$(hostname)" 

Right. If the QS host wanted to use the redis service which was running on a different workstation (say example.server.org), then change qs-config.yml as you said:

  redis_addr: example.server.org:6379 

[prjemian]

comment moved

[prjemian]

QS Host and QS clients are separate processes.

• QS Host process is started from a workstation with access to:
  • the qs-config.yml file
  • a redis service
  • the instrument package with the RE, devices, and plans
• Any QS client is started from a workstation with network access to the QS Host process

[prjemian]

Your question involved the qs-config.yml file and port 6379 (port used by the redis service). This configuration file is used when running start-re-manager (the program that actually operates the queueserver host process).

I'll look again at the qs_host.sh (which calls start-re-manager) to make sure that its comments and code agree with our documentation. The shell script has some defense against certain beamline staff trying to start the QS host on random workstations. (To avoid having multiple RE instances running at the same time, actively running plans on the same hardware.)

By team agreement, we chose one, specific workstation to run the QS Host. The code checks for that. This additional configuration must be known and checked before start-re-manager is run.

[rodolakis]

QS Host and QS clients are separate processes.

• QS Host process is started from a workstation with access to:

  • the qs-config.yml file
  • a redis service
  • the instrument package with the RE, devices, and plans

Right, I am perfectly good with that part. But I am still unclear about how, in practice, do you achieve that:

• Any QS client is started from a workstation with network access to the QS Host process

Do you need that (QS client) workstation to have the package installed with a different set of settings for qs-config.yml? Or a lighter version of the package (since it does not need to know about the RE, devices and plans, which are handled by the host)? How do you start the Queuemonitor from that workstation?

[prjemian]

QS clients will never use the qs-config.yml file.

[prjemian]

Or a lighter version

The packages required depend on which client program is to be run. For example, the standard GUI (queue-monitor) comes from the bluesky_widgets package.

[prjemian]

To run a client, follow the installation steps for that client. They don't need the same suite of packages that the server needs.

[prjemian]

Q: Does a QS client need to know about the redis server or the qs-config.yml file?
A: No. It only needs to know how to communicate with the QS Host process.