As part of the work to transfer functionality from
rose suite run to cylc
it is proposed that the options available in global, user and suite config
files are brought into alignment. This file sets out a specification for the
cylc-flow.rc file, although for the foreseeable future
will also be read in the same way.
To reduce changes required for end users this file format is based on
suite.rc: Where aspects of the file are described as unchanged this implies
that file contents are exactly the same as they would be in a
Users of the
global.rc are usually admins or power users and thus changes
to the format of this file are preferable.
It should be noted that although it will be possible to modify all settings in all contexts, that some settings are more likely to be used in global contexts and some are more likely to be used in suite configs. It has been proposed that it ought to be possible for sysadmins to lock some settings in site configurations.
The new file will be based on
suite.rc and so items in the new file
will be the same as in
suite.rc unless explicitly stated.
It is likely that most users will continue to have these set by site admins.
[suite servers] to be renamed
[suite run platforms] for consistency
with job platforms.
[test battery] will be removed entirely.
[task events] will be moved to
[suite run platforms]
This is the dictionary key formerly known as
[suite servers]. Changed only
for the purpose of keeping the name “platforms” consistent. This is expected to
be set only by system administrators. It should include the former top-level
[[suite host self-identification]].
[cylc] is be renamed
global.rc[cylc] at present contains a subset of the items available in
suite.rc[cylc] for this section so it is proposed that the new fill just has
the larger set. These items are:
[cylc] health check interval = 600 task event mail interval = 300 [[events]]
All config items in the form
[global][event]mail * will be moved to a new
top level section
Many of the options in this section will be very similar to items formerly in
It is expected that these will mainly be set at site level, but that
small numbers of power users may wish to over-ride them.
The key items in this config are
batch system and
as these between them define way the cluster will function.
Cases for this include
[job platforms] [[example platform]] run directory = work directory = task communication method = submission polling intervals = execution polling intervals = scp command = ssh command = use login shell = login hosts = # list of possible login hosts batch system = # name of batch system cylc executable = global init-script = retrieve job logs = retrieve job logs command = retrieve job logs max size = retrieve job logs retry delays = task event handler retry delays = tail command template = [[batch systems]] err tailer = out tailer = err viewer = out viewer = job name length maximum = execution time limit polling intervals = [[default directives]] # This is probably something to do --some-directive="directive here!" # sometime after cylc8
job platform to use will be set for a task in the top level of the
[runtime][task] definition using the key
platform = <name of platform>
All the items in
[runtime][TASK][remote] will be deprecated in favour of equivalent
items in a
job platform. The following items from
[runtime][TASK][job] will also
be deprecated in favour of items in
batch submit command template
submission polling intervals
submission retry delays
[runtime][TASK][remote]hosts will be deprecated but we need to ensure that
we can handle deprecated usage in a sophisticated way. For back compatibility
host is a login node defined in
[job platforms] then that job
will use that platform. If a user wishes to over-ride this they can over-ride the
The other settings to be moved to
job platforms could be subject to these
job platformselected using the value in
There should be a mechanism by which system administrators can lock global
settings for their sites. This should probably be a
within those settings that we wish to make lockable. If unset these will
False. If set to
True a user who tries to over-ride that setting
will see a warning explaining that the setting has been over-ridden by a site