docs: replace redis occurrences with valkey

Signed-off-by: Florian Amsallem <florian.amsallem@gmail.com>

content/docs/guides/contribute/code-review.en.md

@@ -32,7 +32,7 @@ The app will be launched on the 4001 port. You can access it at: http://localhos
 * `./scripts/pr-tests-compose.sh 8914 up`: Downloads the CI-generated images for PR #8914 and launches the application.
 * `./scripts/pr-tests-compose.sh 8914 up-and-load-backup ./path_to_backup`: Downloads the images for PR #8914, restores data from the provided backup, and starts the application.
 * `./scripts/pr-tests-compose.sh down`: Shuts down the test application instance for PR #8914.
-* `./scripts/pr-tests-compose.sh down-and-clean`: Shuts down the test instance and cleans all the instance's docker volumes (PG data, Redis cache, RabbitMQ) to prevent any side-effects.
+* `./scripts/pr-tests-compose.sh down-and-clean`: Shuts down the test instance and cleans all the instance's docker volumes (PG data, Valkey cache, RabbitMQ) to prevent any side-effects.
 
 ### Accessing Services:
 

content/docs/guides/contribute/code-review.fr.md

@@ -32,7 +32,7 @@ L'application sera lancée sur le port 4001. Vous pouvez y accéder en suivant :
 * `./scripts/pr-tests-compose.sh 8914 up` : Télécharge les images CI générées pour la PR #8914 et lance l'application.
 * `./scripts/pr-tests-compose.sh 8914 up-and-load-backup ./path_to_backup` : Télécharge les images pour la PR #8914, restaure les données à partir de la sauvegarde spécifiée, et démarre l'application.
 * `./scripts/pr-tests-compose.sh down` : Arrête l'instance de test de l'application pour la PR #8914.
-* `./scripts/pr-tests-compose.sh down-and-clean` : Arrête l'instance de test et nettoie l'ensemble des volumes docker de l'instance (base de donnée PG, cache Redis, RabbitMQ) pour éviter tout effet de bord.
+* `./scripts/pr-tests-compose.sh down-and-clean` : Arrête l'instance de test et nettoie l'ensemble des volumes docker de l'instance (base de donnée PG, cache Valkey, RabbitMQ) pour éviter tout effet de bord.
 
 
 ### Accès aux Services :

content/docs/guides/deploy/docker-compose/_index.en.md

@@ -5,11 +5,11 @@ weight: 10
 description: Using docker compose for single node deployment
 ---
 
-The OSRD project includes a `docker-compose.yml` file designed to facilitate the deployment of a fully functional OSRD environment. 
+The OSRD project includes a `docker-compose.yml` file designed to facilitate the deployment of a fully functional OSRD environment.
 Only intended for development purposes, this Docker Compose configuration could be adapted for quick, single-node deployments.
 
 {{% alert title="Disclaimer" color="warning"%}}
-This setup is designed for development only. 
+This setup is designed for development only.
 For example no authentication is supported and the front-end is served in development mode (rebuilt on the fly).
 If you mean to deploy a production ready version of OSRD, please follow the [Kubernetes-based deployment](../kubernetes/)
 {{% /alert %}}
@@ -24,8 +24,8 @@ Before proceeding with the deployment, ensure that you have the following instal
 
 The `docker-compose.yml` file defines the following services:
 
-1. **PostgreSQL**: A PostgreSQL database with PostGIS extension. 
-2. **Redis**: A Redis server for caching.
+1. **PostgreSQL**: A PostgreSQL database with PostGIS extension.
+2. **Valkey**: A Valkey server for caching.
 3. **Core**: The core OSRD service.
 4. **Front**: The front-end service for OSRD.
 5. **Editoast**: A OSRD service responsible for various editorial functions.
@@ -38,7 +38,7 @@ Each service is configured with health checks, volume mounts and necessary envir
 
 1. **Clone the Repository**: First, clone the OSRD repository to your local machine.
 2. **Configuration**: The default configuration requires setting an environment variable for the Editoast service: `ROOT_URL`.
-    It should be set to the URL pointing to the Editoast service through the gateway. For example, "http://your-domain.com/api".  
+    It should be set to the URL pointing to the Editoast service through the gateway. For example, "http://your-domain.com/api".
     You can also adjust other environment variables if needed.
 3. **Build and Run**: Navigate to the directory containing `docker-compose.yml` and run:
 
@@ -53,7 +53,7 @@ This command builds the images and starts the services defined in the Docker Com
 While all HTTP service are used through the gateway (`http://localhost:4000`), you can access directly each service using their exposed ports:
 
 - **PostgreSQL**: Accessible on `localhost:5432`.
-- **Redis**: Accessible on `localhost:6379`.
+- **Valkey**: Accessible on `localhost:6379`.
 - **Core Service**: Accessible on `localhost:8080`.
 - **Front-End**: Accessible on `localhost:3000`.
 - **Editoast**: Accessible on `localhost:8090`.

content/docs/guides/deploy/docker-compose/_index.fr.md

@@ -5,7 +5,7 @@ weight: 10
 description: Utiliser docker compose pour un déploiement sur un seul nœud
 ---
 
-Le projet OSRD inclut un fichier docker-compose.yml conçu pour faciliter le déploiement d'un environnement OSRD pleinement fonctionnel. 
+Le projet OSRD inclut un fichier docker-compose.yml conçu pour faciliter le déploiement d'un environnement OSRD pleinement fonctionnel.
 Exclusivement destiné à des fins de développement, cette configuration Docker Compose pourrait être adaptée pour des déploiements rapides sur un seul nœud.
 
 {{% alert title="Avertissement" color="warning"%}}
@@ -26,7 +26,7 @@ Avant de procéder au déploiement, assurez-vous que vous avez installé :
 Le fichier `docker-compose.yml` définit les services suivants :
 
 1. **PostgreSQL** : Une base de données PostgreSQL avec l'extension PostGIS.
-2. **Redis** : Un serveur Redis pour le cache.
+2. **Valkey** : Un serveur Valkey pour le cache.
 3. **Core** : Le service central OSRD.
 4. **Front** : Le service front-end pour OSRD.
 5. **Editoast** : Un service OSRD responsable de diverses fonctions d'édition.
@@ -38,7 +38,7 @@ Chaque service est configuré avec des contrôles de santé, des montages de vol
 ## Étapes du déploiement
 
 1. **Cloner le dépôt** : Tout d'abord, clonez le dépôt OSRD sur votre machine locale.
-2. **Configuration** : La configuration par défaut nécessite le renseignement d'une variable d'environnement pour le service Editoast: ROOT_URL. 
+2. **Configuration** : La configuration par défaut nécessite le renseignement d'une variable d'environnement pour le service Editoast: ROOT_URL.
     Il faut lui donner la valeur de l'URL qui pointe vers le service Editoast par la gateway. Par exemple "http://your-domain.com/api".
     Vous pouvez également ajuster d'autres variables d'environnement si nécessaire.
 3. **Construire et exécuter** : Naviguez vers le répertoire contenant `docker-compose.yml` et exécutez :
@@ -54,7 +54,7 @@ Cette commande construit les images et démarre les services définis dans le fi
 Bien que tous les services HTTP soient utilisés via la passerelle (`http://localhost:4000`), vous pouvez accéder directement à chaque service en utilisant leurs ports exposés :
 
 - **PostgreSQL** : Accessible sur `localhost:5432`.
-- **Redis** : Accessible sur `localhost:6379`.
+- **Valkey** : Accessible sur `localhost:6379`.
 - **Service Core** : Accessible sur `localhost:8080`.
 - **Front-End** : Accessible sur `localhost:3000`.
 - **Editoast** : Accessible sur `localhost:8090`.

content/docs/guides/deploy/kubernetes/_index.en.md

@@ -12,7 +12,7 @@ The OSRD project's Helm Chart provides a flexible and efficient way to deploy OS
 Before proceeding with the deployment, ensure that you have the following installed:
 - A Kubernetes cluster up and running
 - A PostgreSQL database with PostGIS
-- A Redis server (used for caching)
+- A Valkey server (used for caching)
 
 ## The tileserver
 
@@ -25,7 +25,7 @@ flowchart TD
     gw["gateway"]
     front["front-end static files"]
     gw -- local file --> front
-    
+
     browser --> gw
     gw -- HTTP --> editoast
     gw -- HTTP --> tileserver-1
@@ -73,7 +73,7 @@ The Helm Chart is configurable through the following values:
 
 ## Deployment
 
-The chart is available at ghcr OCI repository. You can find 2 Helm charts: 
+The chart is available at ghcr OCI repository. You can find 2 Helm charts:
  - [Stable charts](https://github.com/OpenRailAssociation/osrd-chart/pkgs/container/charts%2Fosrd): `oci://ghcr.io/OpenRailAssociation/charts/osrd`
  - [Dev charts](https://github.com/OpenRailAssociation/osrd-chart/pkgs/container/charts%2Fosrd-dev): `oci://ghcr.io/OpenRailAssociation/charts/osrd-dev`
 

content/docs/guides/deploy/kubernetes/_index.fr.md

@@ -13,7 +13,7 @@ Avant de procéder au déploiement, assurez-vous que vous avez installé :
 
 - Un cluster Kubernetes opérationnel
 - Une base de données PostgreSQL avec PostGIS
-- Un serveur Redis (utilisé pour le cache)
+- Un serveur Valkey (utilisé pour le cache)
 
 ## Le serveur de tuiles
 
@@ -26,7 +26,7 @@ flowchart TD
     gw["gateway"]
     front["fichier statiques front-end"]
     gw -- fichier local --> front
-    
+
     navigateur --> gw
     gw -- HTTP --> editoast
     gw -- HTTP --> tileserver-1

content/docs/reference/design-docs/scalable-async-rpc/index.en.md

@@ -626,14 +626,14 @@ We decided to rely on a [`delivery-limit` policy](https://www.rabbitmq.com/docs/
 ### Report worker activity using AMQP
 
 osrdyne needs to maintain queue usage statistics in order to know when worker groups can be stopped.
-At first, we considered having workers use redis to store the timestamp of the last processed message for the queue.
+At first, we considered having workers use valkey to store the timestamp of the last processed message for the queue.
 We decided against it as:
 
 - it would mean the workers store a timestamp directly in database, read by a supervisor process. it's a pretty bad design
 - it adds an additional database to the RPC architecture, for little to no benefit compared to just using rabbitmq
 - if one of the workers has its clock drift by more than the worker group expiration time compared to osrdyne, the worker group will get stopped
 - any worker can get the pool deleted by forcing the timestamp to an old value
-- it adds a failure mode: if osrdyne / workers are unable to reach redis, weird bugs may ensue
+- it adds a failure mode: if osrdyne / workers are unable to reach valkey, weird bugs may ensue
 
 Instead, we decided to require worker to publish activity updates to a dedicated queue.
 This queue can be watched by osrdyne, which can use these events to know when to stop a worker group.