@@ -14,8 +14,7 @@ The top level modules in TorchX are:
14
14
4. :mod: `torchx.cli `: CLI tool
15
15
5. :mod: `torchx.runner `: given an app spec, submits the app as a job on a scheduler
16
16
6. :mod: `torchx.schedulers `: backend job schedulers that the runner supports
17
- 7. :mod: `torchx.pipelines `: adapters that convert the given app spec to a "stage" in an ML pipeline platform
18
- 8. :mod: `torchx.runtime `: util and abstraction libraries you can use in authoring apps (not app spec)
17
+ 7. :mod: `torchx.runtime `: util and abstraction libraries you can use in authoring apps (not app spec)
19
18
20
19
Below is a UML diagram
21
20
@@ -32,8 +31,7 @@ the actual application. In scheduler lingo, this is a ``JobDefinition`` and a
32
31
similar concept in Kubernetes is the ``spec.yaml ``. To disambiguate between the
33
32
application binary (logic) and the spec, we typically refer to a TorchX
34
33
``AppDef `` as an "app spec" or ``specs.AppDef ``. It
35
- is the common interface understood by ``torchx.runner ``
36
- and ``torchx.pipelines `` allowing you to run your app as a standalone job
34
+ is the common interface understood by ``torchx.runner `` allowing you to run your app as a standalone job
37
35
or as a stage in an ML pipeline.
38
36
39
37
Below is a simple example of an ``specs.AppDef `` that echos "hello world"
@@ -119,10 +117,6 @@ can be achieved through python function composition rather than object compositi
119
117
However **we do not recommend component composition ** for maintainability
120
118
purposes.
121
119
122
- **PROTIP 2: ** To define dependencies between components, use a pipelining DSL.
123
- See :ref: `basics:Pipeline Adapters ` section below to understand how TorchX components
124
- are used in the context of pipelines.
125
-
126
120
Before authoring your own component, browse through the library of
127
121
:ref: `Components ` that are included with TorchX
128
122
to see if one fits your needs.
@@ -141,34 +135,11 @@ There are two ways to access runners in TorchX:
141
135
See :ref: `Schedulers ` for a list of schedulers that the runner can
142
136
launch apps to.
143
137
144
- Pipeline Adapters
145
- ~~~~~~~~~~~~~~~~~~~~~~
146
- While runners launch components as standalone jobs, ``torchx.pipelines ``
147
- makes it possible to plug components into an ML pipeline/workflow. For a
148
- specific target pipeline platform (e.g. kubeflow pipelines), TorchX
149
- defines an adapter that converts a TorchX app spec to whatever the
150
- "stage" representation is in the target platform. For instance,
151
- ``torchx.pipelines.kfp `` adapter for kubeflow pipelines converts an
152
- app spec to a ``kfp.ContainerOp `` (or more accurately, a kfp "component spec" yaml).
153
-
154
-
155
- In most cases an app spec would map to a "stage" (or node) in a pipeline.
156
- However advanced components, especially those that have a mini control flow
157
- of its own (e.g. HPO), may map to a "sub-pipeline" or an "inline-pipeline".
158
- The exact semantics of how these advanced components map to the pipeline
159
- is dependent on the target pipeline platform. For example, if the
160
- pipeline DSL allows dynamically adding stages to a pipeline from an upstream
161
- stage, then TorchX may take advantage of such feature to "inline" the
162
- sub-pipeline to the main pipeline. TorchX generally tries its best to adapt
163
- app specs to the **most canonical ** representation in the target pipeline platform.
164
-
165
- See :ref: `Pipelines ` for a list of supported pipeline platforms.
166
-
167
138
Runtime
168
139
~~~~~~~~
169
140
.. important :: ``torchx.runtime`` is by no means is a requirement to use TorchX.
170
141
If your infrastructure is fixed and you don't need your application
171
- to be portable across different types of schedulers and pipelines ,
142
+ to be portable across different types of schedulers,
172
143
you can skip this section.
173
144
174
145
Your application (not the app spec, but the actual app binary) has **ZERO ** dependencies
0 commit comments