@@ -14,8 +14,7 @@ The top level modules in TorchX are:
14144. :mod: `torchx.cli `: CLI tool
15155. :mod: `torchx.runner `: given an app spec, submits the app as a job on a scheduler
16166. :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)
1918
2019Below is a UML diagram
2120
@@ -32,8 +31,7 @@ the actual application. In scheduler lingo, this is a ``JobDefinition`` and a
3231similar concept in Kubernetes is the ``spec.yaml ``. To disambiguate between the
3332application binary (logic) and the spec, we typically refer to a TorchX
3433``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
3735or as a stage in an ML pipeline.
3836
3937Below 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
119117However **we do not recommend component composition ** for maintainability
120118purposes.
121119
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-
126120Before authoring your own component, browse through the library of
127121:ref: `Components ` that are included with TorchX
128122to see if one fits your needs.
@@ -141,34 +135,11 @@ There are two ways to access runners in TorchX:
141135See :ref: `Schedulers ` for a list of schedulers that the runner can
142136launch apps to.
143137
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-
167138Runtime
168139~~~~~~~~
169140.. important :: ``torchx.runtime`` is by no means is a requirement to use TorchX.
170141 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,
172143 you can skip this section.
173144
174145Your application (not the app spec, but the actual app binary) has **ZERO ** dependencies
0 commit comments