remove "unknown" job state, simplify poll logic#329
Draft
kellyrowland wants to merge 10 commits intojupyterhub:mainfrom
Draft
remove "unknown" job state, simplify poll logic#329kellyrowland wants to merge 10 commits intojupyterhub:mainfrom
kellyrowland wants to merge 10 commits intojupyterhub:mainfrom
Conversation
comment out test_poll_fails for now
…r output status is only set to notfound if we receive the specific scheduler query output that indicates that the job is not in the system currently only implemented for slurm, needs other scheduler syntax added
…proc kill cleanup
for more information, see https://pre-commit.ci
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
draft PR for anyone interested in this work, possibly related to #314. this removes the "unknown" job status and simplifies the logic in
poll.with the project version of the polling logic, we were seeing the hub 'losing track' of batchspawner servers which required manual intervention to delete the users from the hub db in order to clear out the server's bad child state and allow the user to spawn another batch server.
we're been running the version of batchspawner from my branch here for several months now which has addressed the issue; we are no longer seeing this behavior.
I'm opening this PR as a draft since it's incomplete in that:
I'm not familiar enough with other schedulers to update other tests in the code so this would need some help if the community is interested in upstreaming the work.