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

[Serve] log deployment success message in serve.run before blocking #43718

Merged
merged 3 commits into from
Mar 6, 2024

Conversation

GeneDer
Copy link
Contributor

@GeneDer GeneDer commented Mar 5, 2024

Why are these changes needed?

In the previous PR, I accidentally blocked the cli logger from logging the deployment success message. log deployment success message in serve.run before blocking.

Related issue number

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

@GeneDer
Copy link
Contributor Author

GeneDer commented Mar 5, 2024

Also tested manually and seeing "Deployed app successfully." is logged again
image

@GeneDer GeneDer requested a review from edoakes March 5, 2024 19:09
@GeneDer GeneDer self-assigned this Mar 5, 2024
@edoakes
Copy link
Contributor

edoakes commented Mar 5, 2024

@GeneDer I don't really want to add a callback to the public API (to reduce the API surface to maintain). It's probably useful to log this when folks call serve.run too, how about we just add a logging statement there by default?

@GeneDer
Copy link
Contributor Author

GeneDer commented Mar 5, 2024

@GeneDer I don't really want to add a callback to the public API (to reduce the API surface to maintain). It's probably useful to log this when folks call serve.run too, how about we just add a logging statement there by default?

Partial bc there are 2 separate messages that we log "Deployed app successfully." and "Redeployed app successfully." and also the cli logger works different than our serve logger with some custom formatting and stuff. But yea let me simply by just always log a "Deployed app successfully." and drop the callback

@edoakes
Copy link
Contributor

edoakes commented Mar 5, 2024

@GeneDer I don't really want to add a callback to the public API (to reduce the API surface to maintain). It's probably useful to log this when folks call serve.run too, how about we just add a logging statement there by default?

Partial bc there are 2 separate messages that we log "Deployed app successfully." and "Redeployed app successfully." and also the cli logger works different than our serve logger with some custom formatting and stuff. But yea let me simply by just always log a "Deployed app successfully." and drop the callback

Got it, the original motivation makes sense. Let's just simplify and go w/ the single message.

@GeneDer
Copy link
Contributor Author

GeneDer commented Mar 5, 2024

@edoakes this is how it looks now. It's no longer green and doesn't have the file name and line number. Also, noticed this is not using ray.serve logger. Do you think it makes sense to reuse serve logger for this entire file?
image


if blocking:
try:
while True:
# Block, letting Ray print logs to the terminal.
time.sleep(10)
except KeyboardInterrupt:
logger.info("Got KeyboardInterrupt, release blocking...")
logger.warning("Got KeyboardInterrupt, release blocking...")
Copy link
Contributor

Choose a reason for hiding this comment

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

What does "release blocking" mean here?

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe better to say "Got KeyboardInterrupt, exiting"

@@ -573,14 +573,15 @@ def run(
route_prefix=route_prefix,
logging_config=logging_config,
)
logger.warning("Deployed app successfully.")
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
logger.warning("Deployed app successfully.")
logger.warning(f"Deployed app '{name}' successfully.")

Copy link
Contributor

Choose a reason for hiding this comment

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

this should be INFO-level

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Due to this not using serve logger, info level won't log it to stdout 😅

@edoakes
Copy link
Contributor

edoakes commented Mar 5, 2024

@edoakes this is how it looks now. It's no longer green and doesn't have the file name and line number. Also, noticed this is not using ray.serve logger. Do you think it makes sense to reuse serve logger for this entire file? image

Do you know why it doesn't have any log line formatting like INFO api.py ... even though you're using the logger? That part looks out of place.

@GeneDer
Copy link
Contributor Author

GeneDer commented Mar 5, 2024

@edoakes this is how it looks now. It's no longer green and doesn't have the file name and line number. Also, noticed this is not using ray.serve logger. Do you think it makes sense to reuse serve logger for this entire file? image

Do you know why it doesn't have any log line formatting like INFO api.py ... even though you're using the logger? That part looks out of place.

Yes, bc it's not using serve's logger, it's doing logger = logging.getLogger(__file__)😅

@edoakes
Copy link
Contributor

edoakes commented Mar 5, 2024

Oh I see @GeneDer. What does it look like if we use the serve logger? I think a lot of the fields we usually set there aren't applicable on the driver...

Maybe we should have an API logger (could maybe just pull in the cli_logger that's used in the CLI code).

@GeneDer
Copy link
Contributor Author

GeneDer commented Mar 5, 2024

This is how it looks if we just use serve logger (I didn't change back to info, but can easily do that)
image

@GeneDer
Copy link
Contributor Author

GeneDer commented Mar 5, 2024

@edoakes This is how it looks with the existing change
image

@GeneDer GeneDer changed the title [Serve] add deployment success callback to serve.run and log cli deployment success message [Serve] log deployment success message in serve.run before blocking Mar 5, 2024
@edoakes edoakes merged commit 3ce22f9 into ray-project:master Mar 6, 2024
9 checks passed
@GeneDer GeneDer deleted the fix-serve-run-blocking-logs branch March 6, 2024 17:24
ryanaoleary pushed a commit to ryanaoleary/ray that referenced this pull request Jun 7, 2024
…ay-project#43718)

In the previous PR, I accidentally blocked the cli logger from logging the deployment success message. log deployment success message in serve.run before blocking.

---------

Signed-off-by: Gene Su <[email protected]>
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.

None yet

2 participants