docs: remove mentions to distributed orchestrator mode

CHANGELOG.md

@@ -12,6 +12,10 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Support on Python 3.11 ([#367](https://github.com/Substra/substra-documentation/pull/367))
 - Add doc about task output permissions ([#369](https://github.com/Substra/substra-documentation/pull/369))
 
+### Removed 
+
+- Mentions to Orchestrator distributed mode ([#379](https://github.com/Substra/substra-documentation/pull/379))
+
 ## [0.33.1]
 
 ### Fixed

docs/source/documentation/orchestrator/index.rst

@@ -7,26 +7,22 @@ Performing a Federated Learning experiment implies a lot of different compute ta
 The orchestrator registers the status of tasks; when a task is done (status ``Done``), it evaluates if some remaining tasks (status ``Waiting``) are now unblocked, and if it's the case, the status of those tasks is changed to ``To do``. The new status is sent to all the backends, who store the new tasks ``To do`` in the task queue (Celery). Then, the task queue will assign the task to one of the workers (if multiple) and handle retries if needed.
 
 In case of failure, it will store failure reports and  change the status of the faulty task to ``Failed``.
-In case of manual cancellation, it will change the status of the  the tasks to `Cancelled` on different backends.
+In case of manual cancellation, it will change the status of the tasks to ``Cancelled`` on different backends.
 
+Orchestration
+=============
 
-Centralized vs. decentralized orchestration
-===========================================
-
-Substra offers two types of orchestration: **distributed** and **centralized**.
-
-.. image:: /static/schemes/distributed-vs-centralized-orc.svg
-
+Orchestration is hosted by a central Postgres database:
 
-The distributed orchestration is based on a private blockchain using Hyperledger Fabric, while the centralized orchestration is hosted by a central Postgres database.
+.. image:: /static/schemes/centralized-orc.svg
 
-In both cases, the orchestration stores only non-sensitive metadata of the Substra assets, making it possible to verify the integrity of the assets and ensures that the permissions on the assets are respected.
+Orchestration stores only non-sensitive metadata of the Substra assets, making it possible to verify the integrity of the assets and ensures that the permissions on the assets are respected.
 
-Distributed orchestration enables trustless verification of the integrity of assets (functions, model, data), but it requires connections between organizations, and introduces a network overhead. It's not possible to upgrade a Substra network when using distributed orchestration.
+It therefore requires trusting whomever is operating the orchestrator DB not to tamper with it.
 
-On the other hand, centralized orchestration requires trust in the central server, but it is faster and easier to deploy and maintain.
+.. note::
 
-As long as you trust whomever is operating the orchestrator DB not to tamper with it, both modes offer the same level of guarantees. The decentralized mode has nice theoretical guarantees, but the network overhead is very significant, and has a lot of operational drawbacks. That is why, the vast majority (if not all) of the current Substra deployments are using the centralized orchestration system as it is easier to operate and faster. However, the distributed orchestration is still maintained.
+    Orchestration was available in a **distributed** mode until `v0.34.0 <https://docs.substra.org/en/0.34.0/documentation/orchestrator/index.html#centralized-vs-decentralized-orchestration>`__
 
 .. _orc_kubernetes_pods:
 
@@ -47,8 +43,6 @@ migrations
 Communication
 =============
 
-.. for now let's ignore distributed mode
-
 The orchestrator is a central component.
 All backends from each :term:`Organization` must have access to the orchestrator over gRPC for command/queries and event subsription.