-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pass registered suite name to Jinja2 environment #3904
Comments
Unfortunately due to "offline commands" such as We could leave the title blank for these cases, however, that would leave you with a workflow which would fail validation until it is installed. Probably not a big issue for your use case though I would guess? |
For offline (I.e. by file path not reg name) validate etc. we could set a default name - UNKNOWN or whatever - to avoid the undefined variable error, and users could deal with the consequences of that: either handle the offline case explicitly in name switches or don’t validate by file path. |
Not a big issue indeed, although you could potentially pass the directory name of |
Come to think about it, having other suite variables available in Jinja (e.g. CYLC_SUITE_INITIAL_CYCLE_POINT) could be useful too. |
Could just expose the CLI options object (or a dict form of it). Again there is the risk of workflow logic being developed which can only work when executed by |
Turns out |
Yes, this will still be available in Cylc8, we will probably add something like However, using the suite name as a programming interface is going to be fragile as you have no control over how the person who runs the flow decides to register it. For example they might decide to register their flows hierarchically (e.g. With Cylc8 it will be much more likely that the registration will not match
The last point means that the name you want might not actually be the lowest level in the hierarchy. |
Great!
Duly noted and I'm well aware of it.
Does this means that it will be possible to rename/re-register suites without re-installation? (That would be awesome.)
Thanks for listing out possible problems with this. Of course, I wouldn't go with an implementation that requires suite registration to be such and such in order to work - you would be still able to supply the configuration name independently from the suite name. It's more of a convenience feature for devs/operators. Say, you run a particular configuration by selecting an optional config The other use case I'm thinking of is option-less suite start (which is required by our operational tooling). Unless you rely on something like suite name, The alternative solution I'm thinking of:
opts=(main)
This does require some changes, but at least no edits to the source. And these symlinks could be made permanent, e.g. in dedicated deployment branches (at the cost of maintenance of said branches). I'm still mulling over my options here, so if you have any other ideas I'm all ears. |
Not what I was getting at, but if you What I meant is that a run dir is aware of its installation source now that
I wonder if the install-run separation at Cylc8 will help here. The convolution of In Cylc8 Rose optional configs will be applied by # installing multiple flows with different optional configs from a single source directory
# roughly equivalent to rose suite-run -l
cylc install --flow-name abc -O 123 -O x
cylc install --flow-name bcd -O 234 -O y Then operate on them without specifying the opt conf key again for the lifetime of the run: # opt conf keys are recorded during installation and do not need to be specified again
cylc run abc
cylc stop abc
cylc restart abc
cylc run --rerun abc An outstanding question I'm not quite sure of the answer to is what should happen with re-installation. # equivalent to rose suite-run --reload
cylc reinstall abc
cylc reload abc Should we continue with the previously specified opt conf keys, that would certainly be nice, especially for this use case. Though presumably we should permit the opt conf keys to change during re-installation.
|
Update: We think reinstall should preserve optional configs from previous installations, however, will look to provide additional options to remove specified optional configs or rebuild from scratch. Added to the Rose plugin issue - #3819 (comment) |
Yes, I remember getting this change in a couple of years ago, as I wanted it for NIWA operations... And use it in Jinja2, i.e.
(this is for a suite that monitors our suites) |
For a while now we've been using the following snippet in our single-source multiple-suites set-up: {% if SUITE_NAME is undefined %}
{% set SUITE_NAME = environ['CYLC_SUITE_NAME'].split('/')[-1].split('_')[0] %}
{% endif %} where Moving to Cylc 8 in the future we could possibly use |
In my team we tend to develop suites that get configured and deployed from a common source code into running instances. It could be useful to know the name of the suite, so that the relevant configuration could be picked automatically rather than require extra command line options or source code changes.
The text was updated successfully, but these errors were encountered: