Skip to content
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

[client][docs] update docs for new client support in init #17333

Merged
merged 47 commits into from
Aug 4, 2021

Conversation

ckw017
Copy link
Member

@ckw017 ckw017 commented Jul 26, 2021

Why are these changes needed?

Add docs for starting a client connection with ray.init, and details for using the ClientBuilder API for ray versions < 1.5.

Related issue number

Checks

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

@@ -710,9 +720,9 @@ def init(
and the API is subject to change.

Returns:
If the provided address included a protocol (e.g. "ray://1.2.3.4")
Copy link
Member Author

Choose a reason for hiding this comment

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

Parentheses were throwing off sphinx doc generation (mixed up part inside the parens with return type)

Copy link
Contributor

Choose a reason for hiding this comment

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

nice catch here!

Copy link
Contributor

@AmeerHajAli AmeerHajAli left a comment

Choose a reason for hiding this comment

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

I like the new docs, thanks Chris! cc @richardliaw
I am not sure if we want to keep the API of pre 1.5, what @pcmoritz / @ijrsvt think?

python/ray/worker.py Outdated Show resolved Hide resolved
python/ray/worker.py Outdated Show resolved Hide resolved
Copy link
Contributor

@ijrsvt ijrsvt left a comment

Choose a reason for hiding this comment

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

This looks good to me! Just a few comments!

@ckw017
Copy link
Member Author

ckw017 commented Jul 28, 2021

@richardliaw Drops the old docs and fixes the .connect call discussed in #16946


You can also connect using the ClientBuilder API, but this will eventually be deprecated.
**Local mode** is used when the address is prefixed with ``local://``. If no address is provided, i.e. ``ray.init("local://")``), a local cluster is created and connected to directly by attaching a driver. If an address is provided, i.e. ``ray.init("local://localhost:6379")``, Ray will attempt to attach a driver to an existing cluster at the specified address. Local mode accepts all of the same keywords as ``ray.init`` and uses them to configure the local cluster.
Copy link
Contributor

Choose a reason for hiding this comment

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

what is the difference between ray.init("local://localhost: 6379") over ray.init("localhost: 6379")
Also, in general "Local mode" is not clear (mainly it is not clear what local means).

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, are you sure it connects directly and not over the ray client code path?

Copy link
Member Author

@ckw017 ckw017 Jul 30, 2021

Choose a reason for hiding this comment

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

After syncing with Ian, it looks like this probably isn't even worth mentioning in the client docs (it doesn't even use the ray client, and there's not really a reason to use it over just ray.init()). Looks like it was more of a convenience thing for ray.client() so that you could just change the argument to ray.client().connect() instead of changing the entire thing to ray.init().

Copy link
Contributor

Choose a reason for hiding this comment

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

Should we then remove the special handling of ‘local://‘?
Also, cc @pcmoritz to double verify.

Copy link
Member Author

@ckw017 ckw017 Jul 30, 2021

Choose a reason for hiding this comment

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

It'll be useful to keep the code for now, I think(?) the long term plan is to require any address passed into ray.init to start with something://, and ray.init("local://address") will just be used if to replicate current behavior of ray.init("address")

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks @ckw017 for following up on this. I think it is better to remove code and then later add it if we need it (we have the git diff/commits in case we want to retrieve it).

Copy link
Contributor

@pcmoritz pcmoritz Aug 2, 2021

Choose a reason for hiding this comment

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

+1 to not support this for now, now that we have unified the ray.init API and the ClientBuilder API I don't think this functionality is that critical.

The idea here was to only support ray.init("local://") (without an address), which starts a local Ray cluster and connects to it via the Ray client. I don't think we should support ray.init("local://address:port") because that's already covered by ray.init("ray://address:port"). If we later want to add the functionality to start a local cluster and connect with the client, we may even want to do it with ray.init("ray://").

@ckw017
Copy link
Member Author

ckw017 commented Aug 2, 2021

Very close to LGTM. A few final comments (mainly removing local:// from docs and the code and a NIT in the ray start output). Please make sure to file an issue (serverless milestone, P1) for the remaining pieces from these (if they are not address already):

  1. Can we remove all the references of ray.util.connect() in the ray docs?
  2. Can we please be very explicit that there are two ways of connecting? one from the cluster and one from outside the cluster?
  3. can we remove the ray.client().connect() documentation?
  4. Can we add warnings for ray.client().connect()?

1, 2 and 3 will be covered by this PR, opened #17508 for 4

@ckw017 ckw017 removed the @author-action-required The PR author is responsible for the next step. Remove tag to send back to the reviewer. label Aug 2, 2021
Copy link
Contributor

@AmeerHajAli AmeerHajAli left a comment

Choose a reason for hiding this comment

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

LGTM. Left a few comments. Let me know when ready.

@AmeerHajAli AmeerHajAli added this to the Serverless Autoscaling milestone Aug 2, 2021
@AmeerHajAli AmeerHajAli added the @author-action-required The PR author is responsible for the next step. Remove tag to send back to the reviewer. label Aug 2, 2021
ckw017 and others added 2 commits August 2, 2021 15:17
Co-authored-by: Ameer Haj Ali <ameerh@berkeley.edu>
@ckw017
Copy link
Member Author

ckw017 commented Aug 2, 2021

Should be good, will drop author-action once tests are passing

@ckw017
Copy link
Member Author

ckw017 commented Aug 4, 2021

Looks like there are some ongoing issues with java-streaming (14% flaky) and apple tests (out of disk during build) atm : (

@AmeerHajAli
Copy link
Contributor

Looks like there are some ongoing issues with java-streaming (14% flaky) and apple tests (out of disk during build) atm : (

Based on the test failure, is this ready to merge?

@ckw017
Copy link
Member Author

ckw017 commented Aug 4, 2021

Should be fine to merge IMO, 6bfc8f1 was passing everything except a known flaky windows test (which is passing on the most recent run), and the only changes since that commit have been to documentation files.

@ckw017 ckw017 removed the @author-action-required The PR author is responsible for the next step. Remove tag to send back to the reviewer. label Aug 4, 2021
@AmeerHajAli
Copy link
Contributor

Sounds good.

@AmeerHajAli AmeerHajAli merged commit a33cbec into ray-project:master Aug 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants