-
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
Config spec deprecations #3404
Comments
I suggest |
This is now the only item left in the reference test section. I suggest we get rid of the section, and amend the above events section:
(it doesn't really matter that this feature is currently only used in reference tests ... I think it could potentially be useful elsewhere). (I think @oliver-sanders agreed with this on the origin discussion). |
@hjoliver This does not really belong under general (or misc). It is specifically the environment of the server program. Which used to be one way of handing static information to event handlers. Not sure it is ever needed now (do you know @oliver-sanders ?). If we keep it, can we change it to top level server environment? Assuming that we don't want to delete it, do you mean suite host by server, or something else? I think it makes sense to be able to configure the environment of the server program for xtriggers and, especially looking forward to Python API. |
The @oliver-sanders Seems like we have multiple "server" settings, perhaps group them in a section... |
|
Is I think(?) it is only used to set the value of CYLC_SUITE_DEF_PATH in job file environment, which in turn is used to put the suite bin directory in PATH ... if so we should change to a more sensible way of doing that (e.g. CYLC_SUITE_BIN_DIR or whatever ... actually these days everything gets installed to the run dir, should never need the "definition dir" on job hosts. |
There was a comment somewhere else recently on the confusing nature of run vs work dir configuration. (One is a sub-dir of the other by default, but they are configured separately at the top run-dir level). Can we make this less confusing? |
Beta Send feedback Does anyone ever use these two? They are (I think?) an ancient bodge made obsolete by R1 graphs. (i.e. can we drop them?) Seems reasonable, but I'd like thoughts from @oliver-sanders and @dpmatthews These aren't deprecated so it would be pretty cheeky to drop them, however, none of the 600 suites currently running use these either... (again, by drop I meant deprecate grimacing ... we never just literally remove items) |
I know runtime dates back forever, but it is ambiguous (server program runtime, or task jobs?). Can we change it to something like task runtime, or job configuration, or jobs? (probably not jobs) I like this idea, but again this is one for further comment from @oliver-sanders and @dpmatthews. Other possibilities we might consider (just throwing ideas about):
@oliver-sanders Is it really worth the user pain to change this? Only if we can agree a definitively better term?
Yes! Changing a single item name by deprecation (perhaps supported longer-term because it's a big one) is not much pain. In light of recent discussions we need to be getting rid of anything that looks non-standard (where there is a "standard" terminology) or quirky or confusing. I took a step back from what I'm used to seeing every day, and thought "what in hell does 'runtime' mean" - there is nothing in that word that suggests it is a job configuration section, as opposed to server program, or even validation etc. (it all involves a "runtime"). |
@hjoliver Now that everything else has been moved out of the job section, I think we can move these two items up to the top level (next to script etc.). Shouldn't the submission equivalents be here too? |
@hjoliver task outputs? (to be clearer...) (or job outputs). Actually: custom outputs? (these are after all, the user-defined outputs that can be triggered off, as opposed to the automatic ones like "started" and "succeeded"). This is another one where I think discussion might be sensible... We might want to consider how exit code mapping might look in the future? |
Superseded by #3422 |
Taken from: #3348 (review)
Copying to 1 item per comment below, because most items have too much discussion for a simple list in the description here.
The text was updated successfully, but these errors were encountered: