add links, formatting

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

cookbook/docs/conf.py

@@ -64,6 +64,13 @@ class CustomSorter(FileNameSortKey):
         "use_secrets.py",
         "spot_instances.py",
         "workflow_labels_annotations.py",
+        # Remote Access
+        "register_project.py",
+        "run_task.py",
+        "run_workflow.py",
+        "run_launchplan.py",
+        "inspecting_executions.py",
+        "debugging_workflows_tasks.py",
         # Deployment
         ## Workflow
         "deploying_workflows.py",

cookbook/remote_access/debugging_workflows_tasks.py

@@ -4,7 +4,7 @@
 
 The inspection of task and workflow execution would provide you log links to debug things further
 
-#. Using --details flag would shows you node executions view with log links. ::
+Using ``--details`` flag would shows you node executions view with log links. ::
 
 
         └── n1 - FAILED - 2021-06-30 08:51:07.3111846 +0000 UTC - 2021-06-30 08:51:17.192852 +0000 UTC
@@ -14,11 +14,11 @@
         │           └── Name :Kubernetes Logs (User)
         │           └── URI :http://localhost:30082/#/log/flytectldemo-development/f3a5a4034960f4aa1a09-n1-0/pod?namespace=flytectldemo-development
 
-#. Additionally you can check the pods launched by flyte in <project>-<domain> namespace ::
+Additionally you can check the pods launched by flyte in <project>-<domain> namespace ::
 
     kubectl get pods -n <project>-<domain>
 
-#. The launched pods will have a prefix of execution name along with suffix of nodeId ::
+The launched pods will have a prefix of execution name along with suffix of nodeId ::
 
         NAME                        READY   STATUS             RESTARTS   AGE
         f65009af77f284e50959-n0-0   0/1     ErrImagePull       0          18h

cookbook/remote_access/inspecting_executions.py

@@ -2,23 +2,23 @@
 Inspecting Workflow and Task Executions
 ---------------------------------------
 
-Inspecting workflow and task executions are done in the same manner as below. More details `here <https://docs.flyte.org/projects/flytectl/en/stable/gen/flytectl_get_execution.html>`__
+Inspecting workflow and task executions are done in the same manner as below. For more details see the
+`flytectl API reference <https://docs.flyte.org/projects/flytectl/en/stable/gen/flytectl_get_execution.html>`__.
 
-#. Monitor the execution by providing the execution id from create command which can be task or workflow execution. ::
+Monitor the execution by providing the execution id from create command which can be task or workflow execution. ::
 
     flytectl get execution -p flytesnacks -d development <execid>
 
-#. For more details use --details flag which shows node executions along with task executions on them. ::
+For more details use ``--details`` flag which shows node executions along with task executions on them. ::
 
     flytectl get execution -p flytesnacks -d development <execid> --details
 
-#. If you prefer to see yaml/json view for the details then change the output format using the -o flag. ::
+If you prefer to see yaml/json view for the details then change the output format using the -o flag. ::
 
     flytectl get execution -p flytesnacks -d development <execid> --details -o yaml
 
-#. To see the results of the execution you can inspect the node closure outputUri in detailed yaml output. ::
+To see the results of the execution you can inspect the node closure outputUri in detailed yaml output. ::
 
     "outputUri": "s3://my-s3-bucket/metadata/propeller/flytesnacks-development-<execid>/n0/data/0/outputs.pb"
 
-
 """

cookbook/remote_access/register_project.py

@@ -3,10 +3,11 @@
 -------------------------
 
 Creates project to be used as a home for the flyte resources of tasks and workflows.
-Refer to the `following <https://docs.flyte.org/projects/flytectl/en/stable/gen/flytectl_create_project.html>`__ docs for more details.
+Refer to the `flytectl API reference <https://docs.flyte.org/projects/flytectl/en/stable/gen/flytectl_create_project.html>`__
+for more details.
 
 .. prompt:: bash
 
   flytectl create project --id "my-flyte-project-name" --labels "my-label=my-project-label"  --description "my-flyte-project-name" --name "my-flyte-project-name"
 
-"""
+"""

cookbook/remote_access/run_launchplan.py

@@ -3,26 +3,26 @@
 --------------------
 
 This is multi-steps process where we create an execution spec file, update the spec file and then create the execution.
-More details can be found `here <https://docs.flyte.org/projects/flytectl/en/stable/gen/flytectl_create_execution.html>`__
+More details can be found `here <https://docs.flyte.org/projects/flytectl/en/stable/gen/flytectl_create_execution.html>`__.
 
-#. Generate execution spec file. ::
+**Generate an execution spec file** ::
 
     flytectl get launchplan -p flytesnacks -d development myapp.workflows.example.my_wf  --execFile exec_spec.yaml
 
-#. Update the input spec file for arguments to the workflow. ::
+**Update the input spec file for arguments to the workflow** ::
 
-            ....
-            inputs:
-              name: "adam"
-            ....
+    ....
+    inputs:
+        name: "adam"
+    ....
 
-#. Create execution using the exec spec file. ::
+**Create execution using the exec spec file** ::
 
     flytectl create execution -p flytesnacks -d development --execFile exec_spec.yaml
 
 
-#. Monitor the execution by providing the execution id from create command. ::
+**Monitor the execution by providing the execution id from create command** ::
 
     flytectl get execution -p flytesnacks -d development <execid>
 
-"""
+"""

cookbook/remote_access/run_task.py

@@ -5,11 +5,11 @@
 This is multi-steps process as well where we create an execution spec file, update the spec file and then create the execution.
 More details can be found `here <https://docs.flyte.org/projects/flytectl/en/stable/gen/flytectl_create_execution.html>`__
 
-#. Generate execution spec file. ::
+**Generate execution spec file** ::
 
-    flytectl get tasks -d development -p flytectldemo core.advanced.run_merge_sort.merge  --latest --execFile execution_spec.yaml
+    flytectl get tasks -d development -p flytectldemo core.advanced.run_merge_sort.merge  --latest --execFile exec_spec.yaml
 
-#. Update the input spec file for arguments to the workflow. ::
+**Update the input spec file for arguments to the workflow** ::
 
             iamRoleARN: 'arn:aws:iam::12345678:role/defaultrole'
             inputs:
@@ -27,13 +27,13 @@
             task: core.advanced.run_merge_sort.merge
             version: "v1"
 
-#. Create execution using the exec spec file. ::
+**Create execution using the exec spec file** ::
 
     flytectl create execution -p flytesnacks -d development --execFile exec_spec.yaml
 
 
-#. Monitor the execution by providing the execution id from create command. ::
+**Monitor the execution by providing the execution id from create command** ::
 
     flytectl get execution -p flytesnacks -d development <execid>
 
-"""
+"""

cookbook/remote_access/run_workflow.py

@@ -2,7 +2,16 @@
 Running a Workflow
 ------------------
 
-Workflows on their own are not runnable directly. A launchplan is always bound to a workflow and you can use launchplans to **launch** a workflow. For cases in which you want the launchplan to have the same arguments as a workflow, if you are using one of the SDK's to author your workflows - like flytekit, flytekit-java etc, then they should automatically create a ``default launchplan`` for the workflow. A ``default launchplan`` has identical name as the workflow and all argument defaults are similar. Thus you can use the default launchplan to trigger the workflow.
-Tasks can be run using the launch command. One difference is that, launchplans cannot be associated with a task, this is to avoid triggers and scheduling.
+Workflows on their own are not runnable directly. However, a launchplan is always bound to a workflow and you can use
+launchplans to **launch** a workflow. For cases in which you want the launchplan to have the same arguments as a workflow,
+if you are using one of the SDK's to author your workflows - like flytekit, flytekit-java etc, then they should
+automatically create a ``default launchplan`` for the workflow.
+
+A ``default launchplan`` has the same name as the workflow and all argument defaults are similar. See
+:ref:`sphx_glr_auto_remote_access_run_launchplan.py` to run a workflow via the default launchplan.
+
+:ref:`Tasks also can be executed <sphx_glr_auto_remote_access_run_task.py>` using the launch command.
+One difference between running a task and a workflow via launchplans is that launchplans cannot be associated with a
+task. This is to avoid triggers and scheduling.
 
 """