- fix steps description formatting

- replace links to github code
- resolve comments

Signed-off-by: arpechenin <[email protected]>

Author: arpechenin

proposals/separate-standalone-driver/README.md

@@ -25,29 +25,35 @@ Resource availability problems: There's no guarantee the Kubernetes cluster has
 
 Let's take a look at the copy of [hello_world.yaml](hello_world.yaml)  generated by the argo compiler tests.
 
-Execution Order:
-1. entrypoint
-   Type: DAG
-The root DAG represents the entire pipeline run.
-2. root-driver (template: system-dag-driver)
-   Type: Container
-   Purpose: Initializes the root DAG. Creates an MLMD execution for the DAG.
-Outputs:
-execution-id – ID of the DAG execution (created during root-driver execution)
-
-Tasks inside:
-- hello-world-driver (template: system-container-driver)
-  Purpose: Check for the existence of an execution in the cache, if no prepare the MLMD execution of the hello-world container task, and generate the appropriate pod-spec-patch.
-Outputs:
-pod-spec-patch – patch for the system-container-executor pod; inserts the correct image and command for the main container. 
-cached-decision – if true, the next step will be skipped
-- hello-world (template: system-container-executor)
-   Depends on: hello-world-driver.Succeeded
-   Purpose: Executes the hello-world component
-Inputs:
-pod-spec-patch — patch for the pod generated in the previous step
-cached-decision — used as a skip condition
-The system-container-executor template defines the main container that runs the user-defined code.
+**Execution Order:**
+
+1. **entrypoint**  
+   *Type:* DAG  
+   The root DAG represents the entire pipeline run.
+
+2. **root-driver** *(template: system-dag-driver)*  
+   *Type:* Container  
+   *Purpose:* Initializes the root DAG. Creates an MLMD execution for the DAG.  
+   **Outputs:**
+    - `execution-id` – ID of the DAG execution (created during root-driver execution)
+
+   **Tasks inside:**
+
+    - **hello-world-driver** *(template: system-container-driver)*  
+      *Purpose:* Check for the existence of an execution in the cache. If it does not exist, prepare the MLMD execution of the hello-world container task, and generate the appropriate pod-spec-patch.  
+      **Outputs:**
+        - `pod-spec-patch` – patch for the system-container-executor pod; inserts the correct image and command for the main container
+        - `cached-decision` – if true, the next step will be skipped
+
+    - **hello-world** *(template: system-container-executor)*  
+      *Depends on:* `hello-world-driver.Succeeded`  
+      *Purpose:* Executes the hello-world component  
+      **Inputs:**
+        - `pod-spec-patch` — patch for the pod generated in the previous step
+        - `cached-decision` — used as a skip condition
+
+      The `system-container-executor` template defines the main container that runs the user-defined code.
+
 
 Overview of the Argo workflow node structure for the container-driver
 ```yaml
@@ -70,10 +76,10 @@ Overview of the Argo workflow node structure for the container-driver
 ```
 It creates a pod that launches the driver container using the kfp-driver image.
 
-## Alternative
+## Proposal
 
 Instead of launching a new driver's pod using a container template, configure the system to send requests to an already running server.
-Something like this (showing both types of containers):
+Something like this (showing both types of drivers):
 ```yaml
   templates:
   - name: system-container-driver
@@ -131,7 +137,7 @@ Comparison:
 The HTTP template [is not able](https://github.com/argoproj/argo-workflows/issues/13955) to extract parameters from the response and can only use the full response as-is. As a result, it cannot be used in podSpecPatch: '{{inputs.parameters.pod-spec-patch}}' or when: '{{inputs.parameters.cached-decision}} != true'
 
 There’s a trade-off between running a standalone driver service pod globally or single per workflow. This is a balance between better performance and avoiding a single point of failure.
-Currently, Argo [supports](https://github.com/argoproj/argo-workflows/issues/7891) only one driver pod per workflow option. Both options are based on the Agent pod, which is currently started per workflow — this is a limitation of the current implementation.
+Currently, Argo [supports](https://github.com/argoproj/argo-workflows/issues/7891) only one driver pod per workflow option. Both options are based on the Agent pod, which is currently started per workflow — this is a limitation of the current [implementation](https://github.com/argoproj/argo-workflows/issues/7891).
 
 ### Implementation Based on the Executor Plugin
 
@@ -145,9 +151,9 @@ Below is a scheme where, instead of creating a pod for the driver's task, we reu
 
 
 To move from the container template to the Executor Plugin template:
-- patch the [Argo compiler](https://github.com/kubeflow/pipelines/tree/master/backend/src/v2/compiler/argocompiler) to generate a plugin template instead of a container template. Sample: hello-world [adapted](kfp-plugin-flow.png) (see name: system-container-driver)
-- Namely, replace the templates used in the [container-driver](https://github.com/kubeflow/pipelines/blob/master/backend/src/v2/compiler/argocompiler/container.go#L148) and [dag-driver](https://github.com/kubeflow/pipelines/blob/master/backend/src/v2/compiler/argocompiler/dag.go#L156) section of the compiler
-- Extract the [driver](https://github.com/kubeflow/pipelines/tree/master/backend/src/v2/driver) component into a standalone server.
+- patch the [Argo compiler](https://github.com/kubeflow/pipelines/tree/a870b1a325dae0c82c8b6f57941468ee1aea960b/backend/src/v2/compiler/argocompiler) to generate a plugin template instead of a container template. Sample: hello-world [adapted](kfp-plugin-flow.png) (see name: system-container-driver)
+- Namely, replace the templates used in the [container-driver](https://github.com/kubeflow/pipelines/blob/a870b1a325dae0c82c8b6f57941468ee1aea960b/backend/src/v2/compiler/argocompiler/container.go#L148) and [dag-driver](https://github.com/kubeflow/pipelines/blob/a870b1a325dae0c82c8b6f57941468ee1aea960b/backend/src/v2/compiler/argocompiler/dag.go#L156) section of the compiler
+- Extract the [driver](https://github.com/kubeflow/pipelines/tree/a870b1a325dae0c82c8b6f57941468ee1aea960b/backend/src/v2/driver) component into a standalone server.
 - Implement the [plugin](plugin.md)
 
 The sample of the Argo Workflow system-container-driver template based on plugin.
@@ -164,6 +170,7 @@ The sample of the Argo Workflow system-container-driver template based on plugin
           - default: ""
             name: kubernetes-config
       metadata: {}
+      # this is the key change that specifies use of the executor plugin
       plugin:
         driver-plugin:
           args: