@@ -26,7 +26,7 @@ Echo looks familiar and simple. Lets understand how to run ``utils.echo``.
2626
2727.. code-block :: shell-session
2828
29- $ torchx run --scheduler local utils.echo --help
29+ $ torchx run --scheduler local_cwd utils.echo --help
3030 usage: torchx run echo [-h] [--msg MSG]
3131
3232 Echos a message
@@ -39,7 +39,7 @@ We can see that it takes a ``--msg`` argument. Lets try running it locally
3939
4040.. code-block :: shell-session
4141
42- $ torchx run --scheduler local utils.echo --msg "hello world"
42+ $ torchx run --scheduler local_cwd utils.echo --msg "hello world"
4343
4444 .. note :: ``echo`` in this context is just an app spec. It is not the application
4545 logic itself but rather just the "job definition" for running `/bin/echo `.
@@ -83,7 +83,7 @@ Now copy paste the following into ``test.py``
8383 specs.Role(
8484 name="echo",
8585 entrypoint="/bin/echo",
86- image="/tmp ",
86+ image="ubuntu:latest ",
8787 args=[f"replica #{specs.macros.replica_id}: {msg}"],
8888 num_replicas=num_replicas,
8989 )
@@ -94,17 +94,15 @@ Notice that
9494
95951. Unlike ``--msg ``, ``--num_replicas `` does not have a default value
9696 indicating that it is a required argument.
97- 2. We use a local dir (``/tmp ``) as the ``image ``. In practice this will be
98- the identifier of the package (e.g. Docker image) that the scheduler supports.
99- 3. ``test.py `` does **not ** contain the logic of the app and is
97+ 2. ``test.py `` does **not ** contain the logic of the app and is
10098 simply a job definition.
10199
102100
103101Now lets try running our custom ``echo ``
104102
105103.. code-block :: shell-session
106104
107- $ torchx run --scheduler local ~/test.py:echo --num_replicas 4 --msg "foobar"
105+ $ torchx run --scheduler local_cwd ~/test.py:echo --num_replicas 4 --msg "foobar"
108106
109107 replica #0: foobar
110108 replica #1: foobar
@@ -113,13 +111,14 @@ Now lets try running our custom ``echo``
113111
114112 Running on Other Images
115113-----------------------------
116- So far we've run ``utils.echo `` with ``image=/tmp ``. This means that the
117- ``entrypoint `` we specified is relative to ``/tmp ``. That did not matter for us
114+ So far we've run ``utils.echo `` with the ``local_cwd `` scheduler. This means that the
115+ ``entrypoint `` we specified is relative to the current working directory and
116+ ignores the specified image. That did not matter for us
118117since we specified an absolute path as the entrypoint (``entrypoint=/bin/echo ``).
119- Had we specified ``entrypoint=echo `` the local scheduler would have tried to invoke
120- ``/tmp/ echo ``.
118+ Had we specified ``entrypoint=echo `` the local_cwd scheduler would have tried to invoke
119+ ``echo `` relative to the current directory and the specified PATH .
121120
122- If you have a pre-built application binary, setting the image to a local directory is a
121+ If you have a pre-built application binary, using local_cwd is a
123122quick way to validate the application and the ``specs.AppDef ``. But its not all
124123that useful if you want to run the application on a remote scheduler
125124(see :ref: `quickstart:Running On Other Schedulers `).
@@ -128,18 +127,8 @@ that useful if you want to run the application on a remote scheduler
128127 supported by the scheduler. Refer to the scheduler documentation to find out
129128 what container image is supported by the scheduler you want to use.
130129
131- For ``local `` scheduler we can see that it supports both a local directory
132- and docker as the image:
133-
134- .. code-block :: shell-session
135-
136- $ torchx runopts local
137-
138- { 'image_type': { 'default': 'dir',
139- 'help': 'image type. One of [dir, docker]',
140- 'type': 'str'},
141- ... <omitted for brevity> ...
142-
130+ To match remote image behavior we can use the ``local_docker `` scheduler which
131+ will launch the image via docker and run the same application.
143132
144133.. note :: Before proceeding, you will need docker installed. If you have not done so already
145134 follow the install instructions on: https://docs.docker.com/get-docker/
@@ -178,8 +167,7 @@ Try running the echo app
178167
179168.. code-block :: shell-session
180169
181- $ torchx run --scheduler local \
182- --scheduler_args image_type=docker \
170+ $ torchx run --scheduler local_docker \
183171 ~/test.py:echo \
184172 --num_replicas 4 \
185173 --msg "foobar from docker!"
@@ -209,15 +197,15 @@ required by the scheduler you are planning to use
209197.. code-block :: shell-session
210198
211199 $ torchx runopts <sched_name>
212- $ torchx runopts local
200+ $ torchx runopts local_docker
213201
214202 Now that you've figured out what scheduler args are required, launch your app
215203
216204.. code-block :: shell-session
217205
218206 $ torchx run --scheduler <sched_name> --scheduler_args <k1=v1,k2=v2,...> \
219207 utils.sh ~/my_app.py <app_args...>
220- $ torchx run --scheduler local --scheduler_args image_type=dir, log_dir=/tmp \
208+ $ torchx run --scheduler local_cwd --scheduler_args log_dir=/tmp \
221209 utils.sh ~/my_app.py --foo=bar
222210
223211 .. note :: If your app args overlap with the ``run`` subcommand's args, you
@@ -227,7 +215,7 @@ Now that you've figured out what scheduler args are required, launch your app
227215
228216.. code-block :: shell-session
229217
230- $ torchx run --scheduler local ~/my_app.py -- --scheduler foobar
218+ $ torchx run --scheduler local_docker ~/my_app.py -- --scheduler foobar
231219
232220
233221 Next Steps
0 commit comments