Skip to content

Conversation

ryanaoleary
Copy link
Contributor

@ryanaoleary ryanaoleary commented Mar 26, 2025

Why are these changes needed?

Adds the label_selector option to Ray tasks/actors through _common_options, to specify labels used for scheduling on Ray nodes.

Related issue number

#51564

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 :(

Signed-off-by: Ryan O'Leary <ryanaoleary@google.com>
Signed-off-by: Ryan O'Leary <ryanaoleary@google.com>
Signed-off-by: Ryan O'Leary <ryanaoleary@google.com>
@ryanaoleary ryanaoleary marked this pull request as ready for review March 26, 2025 10:32
@jcotant1 jcotant1 added the core Issues that should be addressed in Ray Core label Mar 26, 2025
@MengjinYan MengjinYan self-assigned this Mar 26, 2025
@MengjinYan MengjinYan self-requested a review March 26, 2025 20:45
Copy link
Contributor

@MengjinYan MengjinYan 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 the effort!

I have one general question: It seems that this PR only contains the logic to add the options. For the validation logic, are you planning to add it in a future PR?

ryanaoleary and others added 4 commits March 26, 2025 23:47
Co-authored-by: Mengjin Yan <mengjinyan3@gmail.com>
Signed-off-by: ryanaoleary <113500783+ryanaoleary@users.noreply.github.com>
Co-authored-by: Mengjin Yan <mengjinyan3@gmail.com>
Signed-off-by: ryanaoleary <113500783+ryanaoleary@users.noreply.github.com>
Co-authored-by: Mengjin Yan <mengjinyan3@gmail.com>
Signed-off-by: ryanaoleary <113500783+ryanaoleary@users.noreply.github.com>
Signed-off-by: Ryan O'Leary <ryanaoleary@google.com>
@ryanaoleary
Copy link
Contributor Author

Thanks for the effort!

I have one general question: It seems that this PR only contains the logic to add the options. For the validation logic, are you planning to add it in a future PR?

It already validates that label_selector is a valid remote function option here. For other Actor options, I don't see additional validation about what's passed in as an argument besides that check. Should we be validating here that the labels passed in follow the expected syntax (the same as we do for the node labels) and that the conditions are supported? Or is it sufficient just to allow the user to pass in the label_selector and only schedule it to the node if they are valid.

@ryanaoleary ryanaoleary requested a review from MengjinYan March 27, 2025 08:59
@MengjinYan
Copy link
Contributor

Thanks for the effort!
I have one general question: It seems that this PR only contains the logic to add the options. For the validation logic, are you planning to add it in a future PR?

It already validates that label_selector is a valid remote function option here. For other Actor options, I don't see additional validation about what's passed in as an argument besides that check. Should we be validating here that the labels passed in follow the expected syntax (the same as we do for the node labels) and that the conditions are supported? Or is it sufficient just to allow the user to pass in the label_selector and only schedule it to the node if they are valid.

I think we definitely shouldn't silently ignore the selectors if they are not valid. We need to give users explicitly warnings to users. Personally, I would prefer we check the syntax here and raise an error early so that the users can be aware of the invalid syntax and fix accordingly.

ryanaoleary and others added 5 commits March 27, 2025 10:39
Co-authored-by: Mengjin Yan <mengjinyan3@gmail.com>
Signed-off-by: ryanaoleary <113500783+ryanaoleary@users.noreply.github.com>
Co-authored-by: Mengjin Yan <mengjinyan3@gmail.com>
Signed-off-by: ryanaoleary <113500783+ryanaoleary@users.noreply.github.com>
Signed-off-by: Ryan O'Leary <ryanaoleary@google.com>
Signed-off-by: Ryan O'Leary <ryanaoleary@google.com>
Signed-off-by: Ryan O'Leary <ryanaoleary@google.com>
@ryanaoleary ryanaoleary requested a review from MengjinYan March 28, 2025 01:13
@ryanaoleary
Copy link
Contributor Author

[2fa06a2](/ray-project/ray/pull/51707/commits/2fa06a26515c1824e915c2485674c62674247bd8)

That makes sense to me, I updated the tests and added validation logic for label_selector in 4465d1b. I moved a lot of the validation logic from #51706 to this PR instead since we can re-use some of the same functions for validating the node labels.

ryanaoleary and others added 3 commits March 28, 2025 16:30
Co-authored-by: Mengjin Yan <mengjinyan3@gmail.com>
Signed-off-by: ryanaoleary <113500783+ryanaoleary@users.noreply.github.com>
Signed-off-by: Ryan O'Leary <ryanaoleary@google.com>
Signed-off-by: Ryan O'Leary <ryanaoleary@google.com>
Signed-off-by: Ryan O'Leary <ryanaoleary@google.com>
Signed-off-by: Ryan O'Leary <ryanaoleary@google.com>
Signed-off-by: Ryan O'Leary <ryanaoleary@google.com>
Signed-off-by: Ryan O'Leary <ryanaoleary@google.com>
Signed-off-by: Ryan O'Leary <ryanaoleary@google.com>
Signed-off-by: Ryan O'Leary <ryanaoleary@google.com>
Signed-off-by: Ryan O'Leary <ryanaoleary@google.com>
Signed-off-by: Ryan O'Leary <ryanaoleary@google.com>
@edoakes
Copy link
Collaborator

edoakes commented Apr 11, 2025

@ryanaoleary there are some merge conflicts due to the revert, pls fix one the other PR is re-merged

ryanaoleary and others added 3 commits April 15, 2025 13:35
Signed-off-by: ryanaoleary <113500783+ryanaoleary@users.noreply.github.com>
Signed-off-by: Ryan O'Leary <ryanaoleary@google.com>
Signed-off-by: Ryan O'Leary <ryanaoleary@google.com>
@ryanaoleary
Copy link
Contributor Author

@ryanaoleary there are some merge conflicts due to the revert, pls fix one the other PR is re-merged

@edoakes I've fixed the merge conflicts now that the other PR is merged, I also updated the validation logic to retain the previous check based on the discussion from the other PR.

@edoakes
Copy link
Collaborator

edoakes commented Apr 15, 2025

@ryanaoleary there are some merge conflicts due to the revert, pls fix one the other PR is re-merged

@edoakes I've fixed the merge conflicts now that the other PR is merged, I also updated the validation logic to retain the previous check based on the discussion from the other PR.

There's another merge conflict 😓

Signed-off-by: ryanaoleary <113500783+ryanaoleary@users.noreply.github.com>
@ryanaoleary
Copy link
Contributor Author

@ryanaoleary there are some merge conflicts due to the revert, pls fix one the other PR is re-merged

@edoakes I've fixed the merge conflicts now that the other PR is merged, I also updated the validation logic to retain the previous check based on the discussion from the other PR.

There's another merge conflict 😓

Ah lol should be fixed now

Copy link
Collaborator

@edoakes edoakes left a comment

Choose a reason for hiding this comment

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

Looks good, minor nit

ryanaoleary and others added 3 commits April 21, 2025 08:37
Signed-off-by: Ryan O'Leary <ryanaoleary@google.com>
Signed-off-by: Ryan O'Leary <ryanaoleary@google.com>
Comment on lines +158 to +160
finally:
subprocess.check_call(["ray", "stop", "--force"])
os.remove(test_file_path)
Copy link
Collaborator

Choose a reason for hiding this comment

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

will merge the PR as-is, but please follow up to move all such cleanup logic in this file into fixtures as best practice

@edoakes edoakes merged commit 3441318 into ray-project:master Apr 21, 2025
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
community-backlog community-contribution Contributed by the community core Issues that should be addressed in Ray Core go add ONLY when ready to merge, run all tests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants