[tune] Refactor TrialRunner to separate out executor calls #33448
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
added 8 commits
March 10, 2023 18:21
Signed-off-by: Kai Fricke <kai@anyscale.com>
…-refactor # Conflicts: # python/ray/tune/execution/ray_trial_executor.py # python/ray/tune/execution/trial_runner.py # python/ray/tune/experiment/trial.py
Signed-off-by: Kai Fricke <kai@anyscale.com>
Signed-off-by: Kai Fricke <kai@anyscale.com>
Signed-off-by: Kai Fricke <kai@anyscale.com>
Signed-off-by: Kai Fricke <kai@anyscale.com>
added 2 commits
March 20, 2023 09:01
krfricke
added
the
tests-ok
xwjiang2010
approved these changes
Mar 21, 2023
There was a problem hiding this comment.
Approve to unblock the remaining one PR, since this PR is mostly splitting the logic in TrialRunner into executor-independent, and executor-dependent one (to be replaced by the new controller).
Overall feedback is that TrialRunner (minus anything searcher/scheduler related) and Trial possibly should become "AIR concept" rather than "Tune concept".
edoakes
pushed a commit
to edoakes/ray
that referenced
this pull request
Mar 22, 2023
…ct#33448) We are planning to refactor the Ray Tune trial lifecycle management by offering an improved execution engine. The TrialRunner currently encapsulates most of the execution logic. When switching the Ray execution backend, we would like to retain most of this logic. Thus, we prepare the refactor by restructuring the TrialRunner: - The TrialRunner is split into a _TrialRunnerBase and TrialRunner class - The _TrialRunnerBase contains all lifecycle logic that is independent from execution. For instance, processing trial results, and scheduling trial training - The TrialRunner class contains the communication with the RayTrialExecutor - Our future TuneController (which is prototyped) will also inherit from _TrialRunnerBase Please note that this PR does not change any logic. Is only renames some internal methods and changes the class structure. Signed-off-by: Kai Fricke <kai@anyscale.com> Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
clarng
pushed a commit
to clarng/ray
that referenced
this pull request
Mar 23, 2023
…ct#33448) We are planning to refactor the Ray Tune trial lifecycle management by offering an improved execution engine. The TrialRunner currently encapsulates most of the execution logic. When switching the Ray execution backend, we would like to retain most of this logic. Thus, we prepare the refactor by restructuring the TrialRunner: - The TrialRunner is split into a _TrialRunnerBase and TrialRunner class - The _TrialRunnerBase contains all lifecycle logic that is independent from execution. For instance, processing trial results, and scheduling trial training - The TrialRunner class contains the communication with the RayTrialExecutor - Our future TuneController (which is prototyped) will also inherit from _TrialRunnerBase Please note that this PR does not change any logic. Is only renames some internal methods and changes the class structure. Signed-off-by: Kai Fricke <kai@anyscale.com>
elliottower
pushed a commit
to elliottower/ray
that referenced
this pull request
Apr 22, 2023
…ct#33448) We are planning to refactor the Ray Tune trial lifecycle management by offering an improved execution engine. The TrialRunner currently encapsulates most of the execution logic. When switching the Ray execution backend, we would like to retain most of this logic. Thus, we prepare the refactor by restructuring the TrialRunner: - The TrialRunner is split into a _TrialRunnerBase and TrialRunner class - The _TrialRunnerBase contains all lifecycle logic that is independent from execution. For instance, processing trial results, and scheduling trial training - The TrialRunner class contains the communication with the RayTrialExecutor - Our future TuneController (which is prototyped) will also inherit from _TrialRunnerBase Please note that this PR does not change any logic. Is only renames some internal methods and changes the class structure. Signed-off-by: Kai Fricke <kai@anyscale.com> Signed-off-by: elliottower <elliot@elliottower.com>
ProjectsByJackHe
pushed a commit
to ProjectsByJackHe/ray
that referenced
this pull request
May 4, 2023
…ct#33448) We are planning to refactor the Ray Tune trial lifecycle management by offering an improved execution engine. The TrialRunner currently encapsulates most of the execution logic. When switching the Ray execution backend, we would like to retain most of this logic. Thus, we prepare the refactor by restructuring the TrialRunner: - The TrialRunner is split into a _TrialRunnerBase and TrialRunner class - The _TrialRunnerBase contains all lifecycle logic that is independent from execution. For instance, processing trial results, and scheduling trial training - The TrialRunner class contains the communication with the RayTrialExecutor - Our future TuneController (which is prototyped) will also inherit from _TrialRunnerBase Please note that this PR does not change any logic. Is only renames some internal methods and changes the class structure. Signed-off-by: Kai Fricke <kai@anyscale.com> Signed-off-by: Jack He <jackhe2345@gmail.com>
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.
Why are these changes needed?
We are planning to refactor the Ray Tune trial lifecycle management by offering an improved execution engine. The TrialRunner currently encapsulates most of the execution logic. When switching the Ray execution backend, we would like to retain most of this logic. Thus, we prepare the refactor by restructuring the TrialRunner:
Please note that this PR does not change any logic. Is only renames some internal methods and changes the class structure.
Related issue number
Checks
git commit -s) in this PR.scripts/format.shto lint the changes in this PR.method in Tune, I've added it in
doc/source/tune/api/under thecorresponding
.rstfile.