Skip to content
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

Fix logic which drops input blocks to be transferred #10928

Merged
merged 1 commit into from
Dec 17, 2021

Conversation

amaltaro
Copy link
Contributor

@amaltaro amaltaro commented Dec 16, 2021

Fixes #10927

Status

ready

Description

If we have a workflow, with either run or lumi list, and we happen to drop all the blocks from the initial input list, the initial list of blocks is kept and used for input data placement.

With this patch, if a workflow drops all the previously matched input blocks, it will pass an empty dictionary upstream which should not trigger any input data placement.

Is it backward compatible (if not, which system it affects?)

YES

Related PRs

None

External dependencies / deployment changes

None

@cmsdmwmbot
Copy link

Jenkins results:

  • Python2 Unit tests: failed
    • 1 new failures
  • Python3 Unit tests: failed
    • 1 new failures
    • 4 changes in unstable tests
  • Python2 Pylint check: succeeded
    • 1 warnings
    • 11 comments to review
  • Python3 Pylint check: succeeded
  • Pylint py3k check: succeeded
  • Pycodestyle check: succeeded

Details at https://cmssdt.cern.ch/dmwm-jenkins/view/All/job/DMWM-WMCore-PR-test/12630/artifact/artifacts/PullRequestReport.html

@amaltaro
Copy link
Contributor Author

test this please

Copy link
Contributor

@todor-ivanov todor-ivanov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for those changes @amaltaro They look OK to me. I have only one minor comment, which is not a show stopper here. It is about the new naming of the variables. I would rather call them: runAllowedList and runForbiddenList so that while reading later in the code one does not get the wrong impression it is a single valued item. The List suffix still marks the plural in the variable's nature :) But both ways would do I think. As you find it better.

@cmsdmwmbot
Copy link

Jenkins results:

  • Python2 Unit tests: failed
    • 1 new failures
  • Python3 Unit tests: failed
    • 1 new failures
    • 1 changes in unstable tests
  • Python2 Pylint check: succeeded
    • 1 warnings
    • 11 comments to review
  • Python3 Pylint check: succeeded
  • Pylint py3k check: succeeded
  • Pycodestyle check: succeeded

Details at https://cmssdt.cern.ch/dmwm-jenkins/view/All/job/DMWM-WMCore-PR-test/12634/artifact/artifacts/PullRequestReport.html

rename variables with a List suffix
@amaltaro
Copy link
Contributor Author

@todor-ivanov thanks for the review, Todor. Indeed renaming those variables will be better. I have just updated the code.

@cmsdmwmbot
Copy link

Jenkins results:

  • Python2 Unit tests: failed
    • 1 new failures
  • Python3 Unit tests: succeeded
  • Python2 Pylint check: succeeded
    • 1 warnings
    • 11 comments to review
  • Python3 Pylint check: succeeded
  • Pylint py3k check: succeeded
  • Pycodestyle check: succeeded

Details at https://cmssdt.cern.ch/dmwm-jenkins/view/All/job/DMWM-WMCore-PR-test/12635/artifact/artifacts/PullRequestReport.html

@amaltaro amaltaro merged commit 39e1ecd into dmwm:master Dec 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Wrong input data placement performed by MSTransferor in specific scenario
3 participants