From 576cb0171e54a3721c8dc707588c4fc29cfc1626 Mon Sep 17 00:00:00 2001 From: danielgafni Date: Fri, 10 Oct 2025 15:00:26 +0300 Subject: [PATCH] :book: fix typos in docs --- CHANDELOG.md => CHANGELOG.md | 22 +++++++++++----------- docs/changelog.md | 2 +- docs/tutorial/kuberay.md | 2 +- examples/local/run_launcher/README.md | 2 +- 4 files changed, 14 insertions(+), 14 deletions(-) rename CHANDELOG.md => CHANGELOG.md (84%) diff --git a/CHANDELOG.md b/CHANGELOG.md similarity index 84% rename from CHANDELOG.md rename to CHANGELOG.md index fd3a0d0d..c3255cb8 100644 --- a/CHANDELOG.md +++ b/CHANGELOG.md @@ -13,11 +13,11 @@ Learn more in [Cluster Sharing docs](tutorial/kuberay.md/#cluster-sharing). ### Added - `KubeRayCluster.cluster_sharing` parameter that controls cluster sharing behavior. -- `dagster_ray.kuberay.sensors.cleanup_expired_kuberay_clusters` sensor that cleans up expired clusters (both shared and non-shared). Learn mode in [docs](api/kuberay.md#dagster_ray.kuberay.sensors.cleanup_expired_kuberay_clusters) -- `dagster-ray` entry now appears in the Dagster libraries list in the web UI +- `dagster_ray.kuberay.sensors.cleanup_expired_kuberay_clusters` sensor that cleans up expired clusters (both shared and non-shared). Learn more in [docs](api/kuberay.md#dagster_ray.kuberay.sensors.cleanup_expired_kuberay_clusters). +- `dagster-ray` entry now appears in the Dagster libraries list in the web UI. ### Changed -- [:bomb: breaking] - removed `cleanup_kuberay_clusters_op` and other associated definitions in favor of `dagster_ray.kuberay.sensors.cleanup_expired_kuberay_clusters` sensor that is more flexible +- [:bomb: breaking] - removed `cleanup_kuberay_clusters_op` and other associated definitions in favor of `dagster_ray.kuberay.sensors.cleanup_expired_kuberay_clusters` sensor that is more flexible. ## 0.3.1 @@ -25,29 +25,29 @@ Learn more in [Cluster Sharing docs](tutorial/kuberay.md/#cluster-sharing). - `failure_tolerance_timeout` configuration parameter for `KubeRayInteractiveJob` and `KubeRayCluster`. It can be set to a positive value to give the cluster some time to transition out of `failed` state (which can be transient in some scenarios) before raising an error. ### Fixes -- ensure both `.head.serviceIP` and `.head.serviceName` are set on the `RayCluster` while waiting for cluster readiness +- ensure both `.head.serviceIP` and `.head.serviceName` are set on the `RayCluster` while waiting for cluster readiness. ## 0.3.0 -This release includes massive docs improvements and drops support for Python 3.9 +This release includes massive docs improvements and drops support for Python 3.9. ### Changes -- [:bomb: breaking] dropped Python 3.9 support (EOL October 2025) -- [internal] most of the general, backend-agnostic code has been moved to `dagster_ray.core` (top-level imports still work) +- [:bomb: breaking] dropped Python 3.9 support (EOL October 2025). +- [internal] most of the general, backend-agnostic code has been moved to `dagster_ray.core` (top-level imports still work). ## 0.2.1 ### Fixes -- Fixed broken wheel on PyPI +- Fixed broken wheel on PyPI. ## 0.2.0 ### Changed - `KubeRayInteractiveJob.deletion_strategy` now defaults to `DeleteCluster` for both successful and failed executions. This is a reasonable default for the use case. - `KubeRayInteractiveJob.ttl_seconds_after_finished` now defaults to `600` seconds. -- `KubeRayCluster.lifecycle.cleanup` now defaults to `always` +- `KubeRayCluster.lifecycle.cleanup` now defaults to `always`. - [:bomb: breaking] `RayJob` and `RayCluster` clients and resources Kubernetes init parameters have been renamed to `kube_config` and `kube_context`. ### Added @@ -64,8 +64,8 @@ This release includes massive docs improvements and drops support for Python 3.9 - [:bomb: breaking] `RayResource`: top-level `skip_init` and `skip_setup` configuration parameters have been removed. The `lifecycle` field is the new way of configuring steps performed during resource initialization. `KubeRayCluster`'s `skip_cleanup` has been moved to `lifecycle` as well. - [:bomb: breaking] injected `dagster.io/run_id` Kubernetes label has been renamed to `dagster/run-id`. Keys starting with `dagster.io/` have been converted to `dagster/` to match how `dagster-k8s` does it. - [:bomb: breaking] `dagster_ray.kuberay` Configurations have been unified with KubeRay APIs. -- `dagster-ray` now populates Kubernetes labels with more values (including some useful Dagster Cloud values such as `git-sha`) +- `dagster-ray` now populates Kubernetes labels with more values (including some useful Dagster Cloud values such as `git-sha`). ### Added -- `KubeRayInteractiveJob` -- a resource that utililizes the new `InteractiveMode` for `RayJob`. It can be used to connect to Ray in Client mode -- like `KubeRayCluster` -- but gives access to `RayJob` features, such as automatic cleanup (`ttlSecondsAfterFinished`), retries (`backoffLimit`) and timeouts (`activeDeadlineSeconds`). +- `KubeRayInteractiveJob` -- a resource that utilizes the new `InteractiveMode` for `RayJob`. It can be used to connect to Ray in Client mode -- like `KubeRayCluster` -- but gives access to `RayJob` features, such as automatic cleanup (`ttlSecondsAfterFinished`), retries (`backoffLimit`) and timeouts (`activeDeadlineSeconds`). - `RayResource` setup lifecycle has been overhauled: resources now has an `actions` parameter with 3 configuration options: `create`, `wait` and `connect`. The user can disable them and run `.create()`, `.wait()` and `.connect()` manually if needed. diff --git a/docs/changelog.md b/docs/changelog.md index 73861821..04c99a55 120000 --- a/docs/changelog.md +++ b/docs/changelog.md @@ -1 +1 @@ -../CHANDELOG.md \ No newline at end of file +../CHANGELOG.md \ No newline at end of file diff --git a/docs/tutorial/kuberay.md b/docs/tutorial/kuberay.md index 874d6dca..802b7fcf 100644 --- a/docs/tutorial/kuberay.md +++ b/docs/tutorial/kuberay.md @@ -126,7 +126,7 @@ ray_cluster = KubeRayInteractiveJob( ## KubeRayCluster -While [`KubeRayInteractiveJob`](../api/kuberay.md#dagster_ray.kuberay.KubeRayInteractiveJob) is recommended for production environments, [`KubeRayCluster`](../api/kuberay.md#dagster_ray.kuberay.KubeRayCluster) might be better alternative for dev environments. +While [`KubeRayInteractiveJob`](../api/kuberay.md#dagster_ray.kuberay.KubeRayInteractiveJob) is recommended for production environments, [`KubeRayCluster`](../api/kuberay.md#dagster_ray.kuberay.KubeRayCluster) might be a better alternative for dev environments. Unlike `KubeRayInteractiveJob`, which can outsource garbage collection to the KubeRay controller, `KubeRayCluster` is entirely responsible for cluster management. This is bad for production environments (may result in dangling `RayCluster` instances if the Dagster step pod fails unexpectedly), but good for dev environments, because it allows `dagster-ray` to implement **cluster sharing**. diff --git a/examples/local/run_launcher/README.md b/examples/local/run_launcher/README.md index d206f66a..e19ea859 100644 --- a/examples/local/run_launcher/README.md +++ b/examples/local/run_launcher/README.md @@ -17,6 +17,6 @@ dagster dev 3. From the UI, run the example job and observe how the steps are executed in a Ray job. -Note that this example doens't have the `ray_executor` configured, so steps will be executed in the same Ray job using the default `multiprocess_executor`. +Note that this example doesn't have the `ray_executor` configured, so steps will be executed in the same Ray job using the default `multiprocess_executor`. To see an example of how to use both `RayRunLauncher` and `ray_executor`, see the [RunLauncher and Executor example](../run_launcher_and_executor/README.md).