-
Notifications
You must be signed in to change notification settings - Fork 13
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
Transformation configuration and SchedulerConfig update #191
Conversation
Documentation for this branch can be viewed at https://sites.ecmwf.int/docs/loki/191/index.html |
0db5dd3
to
a6c3659
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #191 +/- ##
=======================================
Coverage 92.22% 92.23%
=======================================
Files 94 95 +1
Lines 16949 16972 +23
=======================================
+ Hits 15632 15654 +22
- Misses 1317 1318 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
4404c25
to
81b88fa
Compare
81b88fa
to
5899bf0
Compare
@reuterbal, apologies for the large diff in the tests due to the name restructuring. I can move this into a separate PR if that makes things easier. I'll also file PRs for the corresponding upstream changes in CLODUSC / ecWAM and reference this one here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First of all, this is a vast improvement in the appearance of the Scheduler config and unlocks an entirely new level of configurability and separation of transformation recipes from target code-specific hand-holding. I'm really pleased about this!
Also, conceptually I don't have much to add - this looks all sound and is in line with what we discussed offline. It needs a rebase, though, and Codecov seems a little confused right now as to what is covered by tests and what not. But I'd like at least additional testing for when the instantiation of transformations from config file entries fails, as I expect this to be a not too rare occurence.
Also, there is now a dependency on the transformations package in the tests of the Loki core library, which I would like to avoid.
8d40a64
to
21cec88
Compare
@reuterbal Ok, many thanks for the review (and good catches 😉). I think I've addressed them all now, so this is ready for another look. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Many thanks, this looks very good now and we could include it as is. For 100% gold-star test coverage, there's one combination that could be tested additionally but I'll leave it up to you if you think it's necessary.
However, to reduce the impact on the parallel scheduler rewrite, delaying the bulk->batch rename to a separate, later PR would help. Generally very much in favor of this, though!
And lastly, as discussed, I'll hold off merging until we have rolled a release as this incurs a breaking change.
} | ||
} | ||
with pytest.raises(ModuleNotFoundError): | ||
cfg = SchedulerConfig.from_dict(worse_config) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to point this out: For full coverage we would need a worst_config
with invalid options provided, that's the only bit currently not covered in the tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hehe, good catch; I'll add it to the rebased push with the removed renaming.
21cec88
to
1914f34
Compare
Ok, great, many thanks @reuterbal ! I've rebased this without the bulk->batch rename (please double-check), and pushed again (including the final test addition). Should be fine now, but waiting for CI to confirm. Please also note that there's a |
1914f34
to
a3e3a46
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fantastic, many thanks, very happy with this now!
This has currently a conflict, so needs a rebase over latest version of main. I would suggest to remove the [DO NOT MERGE]
commit in the process and accept the failing regression tests when merging.
Afterwards, we should see the checks turn green in the pending PRs on ecWAM and CLOUDSC and then merge them:
ecmwf-ifs/ecwam#7
ecmwf-ifs/dwarf-p-cloudsc#61
After both are merged, we can trigger a re-run of the regression tests on main to turn them green again.
This now allos us to encapulate individual Transformation objects, and their individual argument options, in a toml config file.
Since there is more refactoring needed to replace the full incvocation logic, we stick to the ones with custom constructor arguments.
These were previosuly handed down to the transformation constructors, but are not configured dirctly in config.
This avoids depending on the `transformations` sub-package.
a3e3a46
to
ffb6330
Compare
As discussed: Will merge this now and hope for PRs on regression test repositories to turn green, before merging those and re-running regression on Loki. |
Note: This change is not backward compatible for our regression test suite! We therefore temporarily point to custom CLOUDSC (ecWAM) branches - the respective branches need to be merged, and the respective commit(s) removed before merging this PR.
This change is part of the wider plan to make the transformation composition more configurable. It primarily brings in the ability to add configuration entries for transformations to the scheduler config file, and then allow the
SchedulerConfig
to directly instantiate them. This instantiation process allows two things that are important for further refactoring:Transformation
classes from any module (even external!)Dimension
objects via a custom placeholder notation that allows us to reuse the ones defined in theSchedulerConfig
already.In order to provide a more streamlined configuration file, this PR also removes some backward hand-holding, where we would generate dicts of Dimension/Routine objects with custom handling. Instead, we now utilise the native TOML dict/table nesting to use the name of a Dimension/Routine/Transformation directly form the processed TOML output.
Since this change also means we'll be putting more and more custom logic in
SchedulerConfig
, I've also moved this to a new sub-package and renamedloki.bulk
=>loki.batch
. @reuterbal, I hope this does not conflict too much for the sgraph rewrite?And finally, I'm filing this as a draft PR first, to see what breaks in the regression tests, etc. Please feel free to chime in though already, as this is somewhat invasive and might need some careful marshalling.