-
Notifications
You must be signed in to change notification settings - Fork 26
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
bugfix/walltime-conversion #414
Conversation
The flux calls need a different time format, should have tests for slurm, flux and pbs for worker alloc as well as run: flux: slurm:
pbs: |
I think instead we should use this function: Line 547 in 7e07b72
it takes a string and returns another string in the right format, which is an argument, and already has hooks into the proper pre presentation for slurm and flux. It also checks for ints vs strings Implementing should be something like (bad pseudo code) etc |
Yes, that function is used in the scriptadapter but not the batch alloc yet. |
Whoops I somehow didn't see that the Should we just ignore the walltime value if lsf is the scheduler since it doesn't seem to have a walltime flag? I did a little digging and they do have a walltime flag (-W) for bmod but not one for jsrun that I can find. |
I think your original plan to keep the string in the resulting yaml is a good one. We can just use convert_timestring internally. I don't think jsrun has a walltime flag either. On LSF you really need the bsub/jsrun combo. So the ultimate solution will be to emit a bsub script with the jsrun launch. |
I have a feeling that's going to require a lot of changes so maybe we hold off on that in this PR? |
Yes, that is a future improvement and a low priority. |
add test for walltime conversion modify changelog run fix-style and fix issue with unit tests modify walltime to work with different formats for all schedulers modify walltime tests
9d4d8fc
to
fe98083
Compare
I got the nod of approval on this from both Luc and Joe via teams so I'm merging this now. |
This is still a draft but it's a start to a solution for #412. In the comments on that issue I came up with two solutions and I'm using the one I think is best. I'm open to feedback and willing to change this if we think there's a better solution.
This is most likely an issue that I'll revisit in the future since @jwhite242 and I have talked about creating a one-size-fits all walltime value in Maestro at some point.