client: comms method configuration

[oliver-sanders]

Currently the communications method can be configured for job -> scheduler communication, however, this config does not apply to any other connections.

How it works: When a job is submitted the comms method for that platform is extracted from the global config on the Scheduler host and written into the job script as an environment variable. When we get the communication client instance this environment variable is checked and an instance of the relevant client implementation is returned.

The problem

So currently we can configure the comms method for:

• job-scheduler

But not for:

1. local -> scheduler (shared filesystem to scheduler e.g. cylc trigger)
2. remote -> scheduler (remote job platform to scheduler but not from a job script)
3. really remote -> scheduler (somewhere where there isn't a contact file to read)

We need to be able to configure the comms method for (1) & (2) for https://github.com/cylc/cylc-flow/issues/5235#issuecomment-1340604947. We may one day wish to support (3) too.

Proposal

If CYLC_TASK_COMMS_METHOD is not set, use the [platforms][localhost]communications method configuration from the global config.

With the exception that if we are already on the scheduler host we should always use the TCP client.

Efficiency: Note that the global configuration would NOT need to be read for cylc message commands from jobs because the CYLC_TASK_COMMS_METHOD would overrule the config anyway.

Questions

1) Ok with this? 2) The localhost platform already configures:

• Jobs on the scheduler host.
• Jobs on hosts which share a FS with the scheduler host.

• The scheduler host itself (e.g. auto-restart uses the ssh command from localhost).

  Adding this fourth meaning does convolute this a little, but it was convoluted already so does it matter? Can we thing of something better?

Pull requests welcome!

[dwsutherland]

Yes, agreed. and partially addressed in #5235 .. The difference being, job communications can include ssh and poll where the latter doesn't appear to make sense for non-job CLI usage..

So I found it hard to justify using [platforms][localhost]communications method for the CLI if it was intentionally set to poll for use with jobs.. (is this a valid concern?)

Which is why I made something else [CLI]communications method
(we can change this to anything, but not sure it could be the same)

[oliver-sanders]

In practice sites would want to set [platforms][localhost]communications method to match [CLI]communications method so I don't think there is any benefit to separating the two.

[dwsutherland]

In practice sites would want to set [platforms][localhost]communications method to match [CLI]communications method so I don't think there is any benefit to separating the two.

If they ever set it to poll, it would likely break things... Because some commands don't make sense as poll

[oliver-sanders]

I don't think poll makes any sense as a localhost configuration. All of the other comms methods ultimately require local TCP so it is an installation requirement that [platform][localhost]communications method = tcp works on the Scheduler hosts. There should be no use case for polling here.