Open oliver-sanders opened 1 year ago
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)
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.
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
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.
Currently the communications method can be configured for job -> scheduler communication, however, this config does not apply to any other connections.
The problem
So currently we can configure the comms method for:
But not for:
cylc trigger
)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.
Questions
1) Ok with this? 2) The
localhost
platform already configures:The scheduler host itself (e.g. auto-restart uses the
ssh command
fromlocalhost
).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!