Skip to content

[Tune][Air] Fix MLflowLoggerCallback to enable its use with PBT (#27783)#42182

Merged
matthewdeng merged 12 commits intoray-project:masterfrom
sjp611:new-feature
Jun 11, 2025
Merged

[Tune][Air] Fix MLflowLoggerCallback to enable its use with PBT (#27783)#42182
matthewdeng merged 12 commits intoray-project:masterfrom
sjp611:new-feature

Conversation

@sjp611
Copy link
Copy Markdown
Contributor

@sjp611 sjp611 commented Jan 4, 2024

Why are these changes needed?

In the current MLflowLoggerCallback implementation, the function to store parameters in MLflow (mlflow_util.log_param) is only used in log_trial_start.

The problem is that PBT explores various parameters. The initially stored parameters are almost always different from the optimal parameters.

We need to be able to verify not only the initial parameters but also the optimal parameters in MLflow. The current implementation only allows us to verify the initial parameters.

This contribution modifies the MLflowLoggerCallback function to enable the storage of both the final and initial parameters in MLflow.

Related issue number

"Open #27783"

Checks

  • I've signed off every commit(by using the -s flag, i.e., git commit -s) in this PR.
  • I've run scripts/format.sh to lint the changes in this PR.
  • I've included any doc changes needed for https://docs.ray.io/en/master/.
    • I've added any new APIs to the API Reference. For example, if I added a
      method in Tune, I've added it in doc/source/tune/api/ under the
      corresponding .rst file.
  • I've made sure the tests are passing. Note that there might be a few flaky tests, see the recent failures at https://flakey-tests.ray.io/
  • Testing Strategy
    • Unit tests
    • Release tests
    • This PR is not tested :(

@anyscalesam anyscalesam added the tune Tune-related issues label Feb 28, 2024
@stale
Copy link
Copy Markdown

stale bot commented Apr 22, 2024

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

  • If you'd like to keep this open, just leave any comment, and the stale label will be removed.

@sjp611
Copy link
Copy Markdown
Contributor Author

sjp611 commented Apr 23, 2024

I have specifically modified my comment

@anyscalesam anyscalesam added the triage Needs triage (eg: priority, bug/not-bug, and owning component) label May 14, 2024
@hainesmichaelc hainesmichaelc added the community-contribution Contributed by the community label Apr 4, 2025
@github-actions
Copy link
Copy Markdown

github-actions bot commented Jun 1, 2025

This pull request has been automatically marked as stale because it has not had
any activity for 14 days. It will be closed in another 14 days if no further activity occurs.
Thank you for your contributions.

You can always ask for help on our discussion forum or Ray's public slack channel.

If you'd like to keep this open, just leave any comment, and the stale label will be removed.

@github-actions github-actions bot added the stale The issue is stale. It will be closed within 7 days unless there are further conversation label Jun 1, 2025
@github-actions github-actions bot removed the stale The issue is stale. It will be closed within 7 days unless there are further conversation label Jun 4, 2025
Copy link
Copy Markdown
Contributor

@TimothySeah TimothySeah left a comment

Choose a reason for hiding this comment

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

Also please add a unit test for this, thanks!

@sjp611 sjp611 force-pushed the new-feature branch 2 times, most recently from 07e68b5 to 46e20ae Compare June 9, 2025 12:46
@sjp611 sjp611 requested a review from WangTaoTheTonic as a code owner June 9, 2025 12:46
@sjp611 sjp611 closed this Jun 9, 2025
@sjp611 sjp611 deleted the new-feature branch June 9, 2025 12:50
@sjp611 sjp611 restored the new-feature branch June 9, 2025 12:54
@sjp611 sjp611 reopened this Jun 9, 2025
@sjp611 sjp611 closed this Jun 9, 2025
@sjp611 sjp611 deleted the new-feature branch June 9, 2025 13:04
@sjp611 sjp611 restored the new-feature branch June 9, 2025 13:12
@sjp611 sjp611 reopened this Jun 9, 2025
…project#27783)

Why are these changes needed?

In the current MLflowLoggerCallback implementation, the function to store parameters in MLflow (mlflow_util.log_param) is only used in log_trial_start.

The problem is that PBT explores various parameters. The initially stored parameters are almost always different from the optimal parameters.

We need to be able to verify not only the initial parameters but also the optimal parameters in MLflow. The current implementation only allows us to verify the initial parameters.

This contribution modifies the MLflowLoggerCallback function to enable the storage of both the final and initial parameters in MLflow.

Related issue number
"Open ray-project#27783"

Checks
  - [x] I've signed off every commit(by using the -s flag, i.e., git commit -s) in this PR.
  - [x]  I've run scripts/format.sh to lint the changes in this PR.
 - [  ] I've included any doc changes needed for https://docs.ray.io/en/master/.
 - [  ] I've added any new APIs to the API Reference. For example, if I added a method in Tune, I've added it in doc/source/tune/api/ under the corresponding .rst file.
 I've made sure the tests are passing. Note that there might be a few flaky tests, see the recent failures at https://flakey-tests.ray.io/

Testing Strategy
- [x] Unit tests
- [  ] Release tests
- [  ] This PR is not tested :(

Signed-off-by: Sung Joon Park <sjp611@gmail.com>
@sjp611
Copy link
Copy Markdown
Contributor Author

sjp611 commented Jun 9, 2025

My apologies for the multiple notifications while I was cleaning up the PR 🥲

@eicherseiji eicherseiji removed request for a team June 9, 2025 14:48
@sjp611 sjp611 requested a review from TimothySeah June 9, 2025 23:13
sjp611 added 2 commits June 12, 2025 07:29
…project#27783)

Why are these changes needed?

In the current MLflowLoggerCallback implementation, the function to store parameters in MLflow (mlflow_util.log_param) is only used in log_trial_start.

The problem is that PBT explores various parameters. The initially stored parameters are almost always different from the optimal parameters.

We need to be able to verify not only the initial parameters but also the optimal parameters in MLflow. The current implementation only allows us to verify the initial parameters.

This contribution modifies the MLflowLoggerCallback function to enable the storage of both the final and initial parameters in MLflow.

Related issue number
"Open ray-project#27783"

Checks
  - [x] I've signed off every commit(by using the -s flag, i.e., git commit -s) in this PR.
 - [x]  I've run scripts/format.sh to lint the changes in this PR.
 - [ ] I've included any doc changes needed for https://docs.ray.io/en/master/.
 - [ ] I've added any new APIs to the API Reference. For example, if I added a method in Tune, I've added it in doc/source/tune/api/ under the corresponding .rst file.
 I've made sure the tests are passing. Note that there might be a few flaky tests, see the recent failures at https://flakey-tests.ray.io/

Testing Strategy
- [x] Unit tests
- [ ] Release tests
- [ ] This PR is not tested :(

Signed-off-by: Sung Joon Park <sjp611@gmail.com>
@matthewdeng matthewdeng enabled auto-merge (squash) June 11, 2025 22:34
@github-actions github-actions bot added the go add ONLY when ready to merge, run all tests label Jun 11, 2025
@matthewdeng matthewdeng merged commit f0f29e9 into ray-project:master Jun 11, 2025
6 of 7 checks passed
can-anyscale pushed a commit that referenced this pull request Jun 13, 2025
…) (#42182)

In the current MLflowLoggerCallback implementation, the function to
store parameters in MLflow (mlflow_util.log_param) is only used in
log_trial_start.

The problem is that PBT explores various parameters. The initially
stored parameters are almost always different from the optimal
parameters.

We need to be able to verify not only the initial parameters but also
the optimal parameters in MLflow. The current implementation only allows
us to verify the initial parameters.

This contribution modifies the MLflowLoggerCallback function to enable
the storage of both the final and initial parameters in MLflow.

Signed-off-by: Sungjoon Park <sjp611@gmail.com>
Signed-off-by: Sung Joon Park <sjp611@gmail.com>
Signed-off-by: can <can@anyscale.com>
elliot-barn pushed a commit that referenced this pull request Jun 18, 2025
…) (#42182)

In the current MLflowLoggerCallback implementation, the function to
store parameters in MLflow (mlflow_util.log_param) is only used in
log_trial_start.

The problem is that PBT explores various parameters. The initially
stored parameters are almost always different from the optimal
parameters.

We need to be able to verify not only the initial parameters but also
the optimal parameters in MLflow. The current implementation only allows
us to verify the initial parameters.

This contribution modifies the MLflowLoggerCallback function to enable
the storage of both the final and initial parameters in MLflow.

Signed-off-by: Sungjoon Park <sjp611@gmail.com>
Signed-off-by: Sung Joon Park <sjp611@gmail.com>
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
elliot-barn pushed a commit that referenced this pull request Jul 2, 2025
…) (#42182)

In the current MLflowLoggerCallback implementation, the function to
store parameters in MLflow (mlflow_util.log_param) is only used in
log_trial_start.

The problem is that PBT explores various parameters. The initially
stored parameters are almost always different from the optimal
parameters.

We need to be able to verify not only the initial parameters but also
the optimal parameters in MLflow. The current implementation only allows
us to verify the initial parameters.

This contribution modifies the MLflowLoggerCallback function to enable
the storage of both the final and initial parameters in MLflow.

Signed-off-by: Sungjoon Park <sjp611@gmail.com>
Signed-off-by: Sung Joon Park <sjp611@gmail.com>
Signed-off-by: elliot-barn <elliot.barnwell@anyscale.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

community-contribution Contributed by the community go add ONLY when ready to merge, run all tests triage Needs triage (eg: priority, bug/not-bug, and owning component) tune Tune-related issues

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants