We use environment variables and jinja2 to add project-specific elements to what our workflows see when they load the global.cylc file. However, we’ve noticed that when we run cylc reload workflow that the global.cylc file does not appear to be re-evaluated. This means that our variables are not updated in the workflows.
For example, we inject project-specific variables into their init-scripts:
Is there a way to tell Cylc to always re-evaluate the global.cylc file on a workflow reload? We would prefer to not have to stop/play, but if that’s what we have to do, we need to tell our users.
We are aware of one use case for having a dynamic global config, configuring the [symlink dirs] on a per-project basis (this can now be controlled by env vars in a rose-suite.conf file).
But, I’m not aware of any use case for having a global config that is both dynamic to the workflow and which varies over the life of the workflow? Which of the global.cylc configs are dynamic in this setup?
We did consider getting Cylc to reload the global config at a configured interval, however, we haven’t started on this work yet. Whilst trivial to implement as a main-loop plugin, Cylc has a number of caches and object states which would need to be cleared in order for this to work correctly, so there would be a little work involved in getting it off the ground.
It has been our practice (in cylc 7) to make certain updates to workflows as follows:
Pause workflow
Deploy change
Reload workflow
In cylc 7 we didn’t have an especially dynamic global.rc file so whether or not it was re-evaluated didn’t matter.
Because cylc 8’s global.flow is far more powerful, we’ve made it much more dynamic. One of our most important goals was to provide workflows with variables that were correct regardless of whether the workflow is running in dev, test or prod. These provide the correct paths to the sym link locations as you mentioned but they also provide updated paths to versioned deployment artifacts.
I don’t need the workflows to re-evaluate the whole global.flow file, in full, every X period of time, but it would be great if there was an argument to cylc reload that told it to do so on demand. If such an option existed, we would use it every reload.
Our recommendation is to encapsulate the requirements of the workflow within the workflow itself, so we don’t hardcode paths/environments at the global level. We configure environments at the workflow level and also make use of Rose file-installation to automatically pull in artifacts as required (both apply at the reinstall state).
Getting cylc reload to refresh the global config is perfectly possible and fairly easy to achieve, however, a lot of different parts of Cylc read in items from the global config and cache them locally or derive state from them. As a result, there is a lot of state within the Cylc application which may need to be cleared and rebuilt in order for any changes to be consistently applied, so getting this functioning correctly is going to be a bit of work (requires a review of glbl_cfg() calls and Cylc caches).
Cylc 7 did not refresh the global config on reload either.