[pull] master from ray-project:master#1074
Merged
Merged
Conversation
Continuing the effort to unify our time usage on the `ClockInterface` to enable deterministic and fast unit testing. --------- Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
…3795) ## Why are these changes needed? This PR partially resolves #49342 (specifically addressing the first bullet point regarding Cluster view navigation). **The Problem:** Currently, when viewing the Nodes table in the Cluster view, the worker process name is plain text. There is no quick way to jump to the details of a specific Actor running on that node without manually copy-pasting IDs into the search bar. **The Solution:** This PR updates the `WorkerRow` component inside `NodeRow.tsx` so that the worker's process name (the `cmdline` string) now acts as a direct `<Link>` to the Actor Detail page (if the worker is hosting an Actor). ### Architectural Code Choices During implementation, I had to account for several backend data structures exported by Ray: 1. **Array Extraction:** `worker.coreWorkerStats` is passed as an array to the frontend. The logic extracts `coreWorkerStats[0]` to safely access the ID. 2. **"Nil" ID Handling:** If a worker is *not* an actor, Ray does not set `actorId` to null/undefined. Instead, it passes a "Nil" ID (a string of 32 or 40 `f`s). I added an explicit check against this `ffff...` string to prevent linking users to non-existent actor pages. 3. **Task IDs are 1:N:** We cannot natively link generic task workers to a specific `/tasks/{taskId}` page from this view. A worker process is long-lived and executes many tasks sequentially, so the backend does not expose a single `taskId` in the top-level worker stats. 4. **The Fallback:** If the worker is not an Actor, it safely falls back to linking to `/cluster/nodes/{nodeId}` (the Node Detail page) to preserve navigation utility. ## Related issue number Resolves #49342 ## Testing Instructions 1. Start a local Ray cluster. 2. Run a script that spawns a long-running Actor: ```python import ray import time ray.init() @ray.remote class DummyActor: def do_work(self): time.sleep(3600) a = DummyActor.remote() a.do_work.remote() while True: time.sleep(1) --------- Signed-off-by: Ayush KAshyap <kashyap11ayush02@gmail.com>
Updates consumers of `PeriodicalRunner` to take the dependency-injected interface. This sets us up to implement a `FakePeriodicalRunner` that integrates with the `FakeClock` for deterministic testing: #64065 --------- Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Cleans up a few remaining callsites that did not use the clock interface. Also addressing this comment: #63956 (comment) and fixing a few other places where we should be using monotonic time but are using wall-clock time. --------- Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Previously, the metrics exported by the `IOContextMonitor` were: - A gauge indicating the most recent probe latency. - A gauge indicating if the io_context was currently deemed healthy or unhealthy. These were chosen for simplicity. However, in my manual testing of the PR that integrates the monitor into the GCS (#63930), I found some issues with this, primarily due to load spikes on the io_context that cause transient problems to get missed. To address this, I'm making the following two changes: - Modifying the gauge of the probe latency to be based on a sliding window. The default sliding window duration is set to 20s, which exceeds the default prometheus scraping interval of 15s. This way, we should be able to see the _max_ io_context latency within each interval. - Changing the health gauge to an unhealthy count. This way, if we have transient spikes that cause a probe to miss the deadline but then recover, we will see it reflected in the metrics as the count increasing over time. This again means we won't miss unhealthy io contexts due to the scraping interval. I've opted for the windowed latency instead of a histogram because I think it's the minimal thing that will give us the signal that we want here, without needing to deal with the complexities of prometheus histograms which have been confusing in the past due to the discrete bucketing. The downside is it does not indicate the median io_context latency. That could be added in the future. --------- Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )