-
Notifications
You must be signed in to change notification settings - Fork 118
Add support for combining system:partition and features/extras in valid_systems #3613
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
base: develop
Are you sure you want to change the base?
Add support for combining system:partition and features/extras in valid_systems #3613
Conversation
…id_systems, as requested in reframe-hpc#2820
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #3613 +/- ##
========================================
Coverage 91.37% 91.37%
========================================
Files 62 62
Lines 13484 13484
========================================
Hits 12321 12321
Misses 1163 1163 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
I've done some concrete testing to prove this works. Note that I have 4 partitions (rome, genoa, gpu_A100, gpu_H100), of which the first two have the **Case 1: traditional `system:partition` assignment**Output: **Case 2: Combining system:partition with +feat1**Output: **Case 3: Combining system:partition with -feat1**Output: **Case 4: Using only features**This case clearly doesn't make any sense, because it'll create tests where the first element of Output: |
|
Hm, I have to recheck how the current |
This was requested in #2820 , although that was eventually closed with a suggestion for a workaround.
However, I hit it again when trying to use
reframe.utils.find_modules(substr, ...)in combination with wanting to specify additional features. Example use cases (and there's many more one can come up with):CPUfeature to my CPU partitions (but not to my GPU partitions) and then requesting theCPUfeature from my CPU-only tests.infinibandfeature.In both cases, we want to test all modules with
XorYrespectively that are available on our system, hence we want to use thefind_modulesfunction. However, the first element of the tuple this returns is thesystem:partitionstring for which it found the module matching the requested substring. This is clearly meant to be used invalid_systemsdirectly (as is confirmed by the example in the docs), but for the examples above, you may want to only run on a subset of thesesystem:partitioncombinations (based on the required features. It would be very natural to then do:To make sure that a partition is only valid if it provides the right module and the right feature.
It turned out that the code changes needed are very limited (it seems like a lot because the indentation changed, but the key part is:
elifon the subspec:And adding that
syspart_matchto the return logic:Note that this logic does not assume the
system:partitionto strictly come before or after the features/extras, so I've adapted the valid syntax specification to allow both:If anything, I feel the code has become cleaner by not handling
system:partitionas a special, separate case, but as 'just another item' that may occur as a subspec.