diff --git a/cookbook/docs/conf.py b/cookbook/docs/conf.py index 19ca6241ec..09e0fda7db 100644 --- a/cookbook/docs/conf.py +++ b/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", diff --git a/cookbook/remote_access/debugging_workflows_tasks.py b/cookbook/remote_access/debugging_workflows_tasks.py index 9e33253d91..b792021ba5 100644 --- a/cookbook/remote_access/debugging_workflows_tasks.py +++ b/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 - namespace :: +Additionally you can check the pods launched by flyte in - namespace :: kubectl get pods -n - -#. 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 diff --git a/cookbook/remote_access/inspecting_executions.py b/cookbook/remote_access/inspecting_executions.py index 496f18f1f7..638099c13d 100644 --- a/cookbook/remote_access/inspecting_executions.py +++ b/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 `__ +Inspecting workflow and task executions are done in the same manner as below. For more details see the +`flytectl API reference `__. -#. 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 -#. 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 --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 --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-/n0/data/0/outputs.pb" - """ diff --git a/cookbook/remote_access/register_project.py b/cookbook/remote_access/register_project.py index c794298038..a9864614af 100644 --- a/cookbook/remote_access/register_project.py +++ b/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 `__ docs for more details. +Refer to the `flytectl API reference `__ +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" -""" \ No newline at end of file +""" diff --git a/cookbook/remote_access/run_launchplan.py b/cookbook/remote_access/run_launchplan.py index c6cac73b4e..86780aed7c 100644 --- a/cookbook/remote_access/run_launchplan.py +++ b/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 `__ +More details can be found `here `__. -#. 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 -""" \ No newline at end of file +""" diff --git a/cookbook/remote_access/run_task.py b/cookbook/remote_access/run_task.py index 7b7a6c113f..10c3deb511 100644 --- a/cookbook/remote_access/run_task.py +++ b/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 `__ -#. 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 -""" \ No newline at end of file +""" diff --git a/cookbook/remote_access/run_workflow.py b/cookbook/remote_access/run_workflow.py index 680004339c..d3f982278e 100644 --- a/cookbook/remote_access/run_workflow.py +++ b/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 ` 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. """