Keep Resubmission spec and json data consistent #10789
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Jenkins results:
|
|
Jenkins results:
|
|
Jenkins results:
|
|
Jenkins results:
|
|
And voilà! Finally, this is working as expected. Time to squash it, update the description, and fire up a review request. |
Fix default EventStreams; fixed Resubmission tweaks fixed TimePerEvent and Memory for ACDC of StepChain fix how Resubmission setters are called; fix StepChain
more unit tests for StepChain and ReReco
|
Jenkins results:
|
|
Thanks a lot Alan! I read the description and it all looks good to me. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #10788
Status
ready
Description
The only logic change - regarding the recent changes to this Resubmission spec - is keeping the JSON vs the Workload config data in sync, thus, iterating over the Tasks/Steps (when existing) and updating those accordingly to the new parameters provided by the user.
The behaviour implemented in this PR was also quickly discussed with Hasan, and in summary, this is how it will behave during Resubmission workflow creation:
Memory | TimePerEvent | Multicore | EventStreamsare either of type int or float, so regardless whether they are overwritten or not, both the JSON and the workload object will always contain the up-to-date and consistent value;Memory | TimePerEvent | Multicore | EventStreamscan be either int/float or a dictionary.Memory | TimePerEventhave simple type (int/float), whileMulticore | EventStreamscan be either int/float or a dictionary.Memory | TimePerEventis provided as a dictionary, workflow creation fails;Multicore | EventStreamstop level parameter will be set to None, while Memory | TimePerEvent remains untouched (workload object isn't touched).Multicore | EventStreamsis provided as int/float, it gets applied to both top and ALL inner steps. If value is provided as a dictionary, top level will contain the dictionary, and the steps will be updated after their keyname/value as provided by the user (NOTE that the workload object has a bug Override of Multicore/EventStreams in Resubmission of StepChains not functional #10791).Is it backward compatible (if not, which system it affects?)
YES
Related PRs
Complement to #10781
External dependencies / deployment changes
None