Fix log format for serve

[vitrioil]

Why are these changes needed?

There is an error while logging Connecting to existing Serve app... leading to an exception being printed in the logs.

--- Logging error ---
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/logging/__init__.py", line 1079, in emit
    msg = self.format(record)
  File "/usr/local/lib/python3.9/logging/__init__.py", line 923, in format
    return fmt.format(record)
  File "/usr/local/lib/python3.9/logging/__init__.py", line 659, in format
    record.message = record.getMessage()
  File "/usr/local/lib/python3.9/logging/__init__.py", line 363, in getMessage
    msg = msg % self.args
TypeError: not all arguments converted during string formatting
Call stack:
  File "/home/user/app/main.py", line 12, in <module>
    serve.start(detached=True)
  File "/home/user/.cache/pypoetry/virtualenvs/delta-Ost0U_JB-py3.9/lib/python3.9/site-packages/ray/serve/api.py", line 99, in start
    client = _private_api.serve_start(detached, http_options, dedicated_cpu, **kwargs)
  File "/home/user/.cache/pypoetry/virtualenvs/delta-Ost0U_JB-py3.9/lib/python3.9/site-packages/ray/serve/_private/api.py", line 173, in serve_start
    logger.info(
Message: 'Connecting to existing Serve app in namespace "serve".'
Arguments: (' New http options will not be applied.',)

Sample code to generate the error:

from ray import serve
import logging
logging.basicConfig(level=logging.INFO)
serve.start(detached=True)

After the changes it logs:
Connecting to existing Serve app in namespace "serve". New http options will not be applied.

Related issue number

Closes #28567

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

[architkulkarni]

@vitrioil Thanks for the contribution! Do you mind adding a quick test for this, perhaps in serve/tests/test_logging.py or serve/tests/test_logs.py? You can use the capsys pytest fixture to verify that the entire string appears in the output.

[simon-mo]

Hi @vitrioil would you be able to update this PR? Alternatively, @architkulkarni can you help if you have free cycle?

[vitrioil]

Apologies!

I was working on this, but I think for running tests locally I have to do a full bazel build, if I'm not completely wrong?

When I tried to do that it went out of memory and I couldn't run tests locally.

[architkulkarni]

Hi @vitrioil, good question, and sorry for the poor experience here -- we want to make things as smooth as possible for new contributors so your feedback is appreciated.

Can you try one of these?

• Since it's a Python-only change, you should be able to just install a nightly wheel and make the Python files "editable" via https://docs.ray.io/en/latest/ray-contribute/development.html#building-ray-python-only
• If that doesn't work or it ends up triggering Bazel anyway, can you try the OOM "tip" near the bottom of this section? https://docs.ray.io/en/latest/ray-contribute/development.html#building-ray-on-linux-macos-full

If your machine is running out of memory during the build or the build is causing other programs to crash, try adding the following line to ~/.bazelrc:

build --local_ram_resources=HOST_RAM*.5 --local_cpu_resources=4

The build --disk_cache=~/bazel-cache option can be useful to speed up repeated builds too.

[vitrioil]

@architkulkarni thanks for the suggestion, I can run bazel command with that.

bazel build --verbose_failures -- //:ray_pkg 

However the final pip install still takes a lot of memory and crashes.

 pip install -e .

I am doing this because running test requires _ray import.

I guess the latter one is needed to locally install?

Anyway, I've to push the test and see if it works in build.

[architkulkarni]

Ideally we would use wait_for_condition instead of a fixed sleep here, but no need to block the PR on this

[architkulkarni]

Ah interesting, sorry about that -- I'm not sure why the bazel build succeeds while the pip install doesn't.

Any success with the approach in https://docs.ray.io/en/latest/ray-contribute/development.html#building-ray-python-only with python python/ray/setup-dev.py?

(On an unrelated note, it looks like the CI didn't run on the latest commit for some reason, can you try merging master and pushing again, or pushing a new commit?)