You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -84,7 +81,7 @@ This is a slimmed-down version of the base implementation which aims to highligh
84
81
85
82
If you want to create your own custom flavor for an orchestrator, you can follow the following steps:
86
83
87
-
1. Create a class that inherits from the `BaseOrchestrator` class and implement the abstract `prepare_or_run_pipeline(...)` and `get_orchestrator_run_id()` methods.
84
+
1. Create a class that inherits from the `BaseOrchestrator` class and implement the abstract `submit_pipeline(...)` and `get_orchestrator_run_id()` methods.
88
85
2. If you need to provide any configuration, create a class that inherits from the `BaseOrchestratorConfig` class and add your configuration parameters.
89
86
3. Bring both the implementation and the configuration together by inheriting from the `BaseOrchestratorFlavor` class. Make sure that you give a `name` to the flavor through its abstract property.
90
87
@@ -125,12 +122,15 @@ The design behind this interaction lets us separate the configuration of the fla
125
122
## Implementation guide
126
123
127
124
1.**Create your orchestrator class:** This class should either inherit from `BaseOrchestrator`, or more commonly from `ContainerizedOrchestrator`. If your orchestrator uses container images to run code, you should inherit from `ContainerizedOrchestrator` which handles building all Docker images for the pipeline to be executed. If your orchestator does not use container images, you'll be responsible that the execution environment contains all the necessary requirements and code files to run the pipeline.
128
-
2.**Implement the `prepare_or_run_pipeline(...)` method:** This method is responsible for running or scheduling the pipeline. In most cases, this means converting the pipeline into a format that your orchestration tool understands and running it. To do so, you should:
125
+
2.**Implement the `submit_pipeline(...)` method:** This method is responsible for submitting the pipeline run or schedule. In most cases, this means converting the pipeline into a format that your orchestration backend understands and submitting it. To do so, you should:
129
126
130
127
* Loop over all steps of the pipeline and configure your orchestration tool to run the correct command and arguments in the correct Docker image
131
128
* Make sure the passed environment variables are set when the container is run
132
129
* Make sure the containers are running in the correct order
133
130
131
+
* If you want to store any metadata for the run or schedule, return it as part of the `SubmissionResult`.
132
+
* If your orchestrator is configured to run synchronous, make sure to return a `wait_for_completion` closure in the `SubmissionResult`.
133
+
134
134
Check out the [code sample](custom.md#code-sample) below for more details on how to fetch the Docker image, command, arguments and step order.
135
135
3.**Implement the `get_orchestrator_run_id()` method:** This must return a ID that is different for each pipeline run, but identical if called from within Docker containers running different steps of the same pipeline run. If your orchestrator is based on an external tool like Kubeflow or Airflow, it is usually best to use an unique ID provided by this tool.
136
136
@@ -152,7 +152,7 @@ from typing import Dict
152
152
153
153
from zenml.entrypoints import StepEntrypointConfiguration
154
154
from zenml.models import PipelineDeploymentResponseModel, PipelineRunResponse
155
-
from zenml.orchestrators import ContainerizedOrchestrator
155
+
from zenml.orchestrators import ContainerizedOrchestrator, SubmissionResult
156
156
from zenml.stack import Stack
157
157
158
158
@@ -165,13 +165,13 @@ class MyOrchestrator(ContainerizedOrchestrator):
0 commit comments