From af9fef3d61bb1d2e1635545d2f6fdf9ea9bab7d5 Mon Sep 17 00:00:00 2001 From: SmritiSatyanV Date: Thu, 4 Aug 2022 23:33:48 +0530 Subject: [PATCH 1/5] update clis.rst [Issue](https://github.com/flyteorg/flyte/issues/2640) Signed-off-by: SmritiSatyanV smriti@union.ai --- docs/source/design/clis.rst | 52 ++++++++++++++++++++++++++++++++----- 1 file changed, 46 insertions(+), 6 deletions(-) diff --git a/docs/source/design/clis.rst b/docs/source/design/clis.rst index 60723e1602..38e3eb903c 100644 --- a/docs/source/design/clis.rst +++ b/docs/source/design/clis.rst @@ -22,14 +22,54 @@ The client code is located in ``flytekit/clients`` and there are two. Command Line Interfaces *********************** -Flyte CLI +Flytectl =========== -``flyte-cli`` is the general CLI that can be used to talk to the Flyte control plane (Flyte Admin). It ships with Flytekit as part of the Pypi package. Think of this as the ``kubectl`` for Flyte. In fact, we're working on ``flytectl`` which is under active development the completion of which will deprecate this CLI. - -Think of this CLI as a network-aware (i.e. can talk to Admin) but not code-aware (doesn't need to have user code checked out) CLI. In the registration flow, this CLI is responsible for shipping the compiled Protobuf files off to Flyte Admin. +``flytectl`` is the general CLI that can be used to communicate with the Flyte control plane (FlyteAdmin). It ships with flytekit as part of the Pypi package. Think of this as the ``kubectl`` for Flyte. +Think of this CLI as a network-aware (can talk to Admin) but not code-aware (doesn't need to have user code checked out) CLI. In the registration flow, this CLI is responsible for shipping the compiled Protobuf files off to Flyte Admin. Pyflyte ========= -Unlike Flyte CLI, think of this CLI as code-aware, but not network-aware (the latter is not entirely true, but it's helpful to think of it that way). +Unlike flytectl, think of this CLI as code-aware, but not network-aware (the latter is not entirely true, but it's helpful to think of it that way). + +This CLI is responsible for the serialization (compilation) step in the registration flow. It will parse through the user code, looking for tasks, workflows and launch plans, and compile them to protobuf files. + +What is ``pyflyte register``? +============================= +``pyflyte register`` is a command that registers all the workflows present in the repository/directory using fast-registration. It is equivalent to using two commands (``pyflyte package`` and ``flytectl register``) to perform the same operation (registration). +The ``pyflyte package`` command parses and compiles the user’s Python code into Flyte protobuf objects. +The ``flytectl register`` command ships the protobuf objects over the network to Flyte control plane, wherein ``flytectl`` also allows adding attributes such as IAM role, K8s service account, and so on. + +Why should you use ``pyflyte register``? +======================================== +The ``pyflyte register`` command bridges the gap between ``pyflyte package`` + ``flytectl register``and ``pyflyte run`` commands. It offers the functionality of the ``pyflyte package`` (with smarter naming semantics and combines the network call into one step), by registering all the workflows in the repository, and the convenience of the ``pyflyte run``, by launching the execution of a single workflow. + +.. note :: + + You can’t use ``pyflyte register`` if you are unaware of the run-time options yet(IAM role, service account, and so on). + +What is ``pyflyte run``? +======================== +The ``pyflyte run`` command is a light-weight, convenience command that combines packaging, registering and launching a workflow in a single command. +It is not a fully featured production scale mode of operation, because it +is designed to be a quick and easy iteration tool to get started with Flyte or test small self-contained scripts. The caveat here is it operates on a single file, and this file will have to contain all the required Flyte entities. Let’s take an example so that you can understand it better. +Suppose you execute a script that defines 10 tasks and a workflow that calls only 2 out of the 10 tasks, the remaining 8 tasks don’t get registered at that point. +It is considered fast registration because when a script is executed using ``pyflyte run``, the script is zipped up and sent to FlyteAdmin. When the task is executed in the backend, this zipped file is extracted and used. + +Usage +===== + +.. prompt:: bash $ + + pyflyte --config ~/.flyte/dev-uniondemo.yaml register --image ghcr.io/flyteorg/flytecookbook:core-latest --image trainer=ghcr.io/flyteorg/flytecookbook:core-latest --image predictor=ghcr.io/flyteorg/flytecookbook:core-latest --raw-data-prefix s3://development-service-flyte/reltsts flyte_basics + +.. note :: + + Neither ``pyflyte register`` nor ``pyflyte run`` commands work on Python namespace packages since both the tools traverse the filesystem to find the first folder that doesn't have an __init__.py file, which is interpreted as the root of the project. Both the commands use this root as the basis to name the Flyte entities. + +In a broad way, ``pyflyte register`` is equivalent to ``pyflyte run`` minus launching workflow with the exception that ``pyflyte run`` can only register a single workflow whereas ``pyflyte register`` can register all workflows in a repository. + +Should I use ``pyflyte run`` or ``pyflyte package`` + ``flytectl register``? +============================================================================ +``pyflyte run`` is convenient when you are starting out with Flyte, and testing small scripts. +``pyflyte package`` + ``flytectl register`` is convenient when you want to zip your files (that constitutes all your tasks and workflows) into a single portable file and pass it on to another developer to register it. -This CLI is what is responsible for the serialization (compilation) step in the registration flow. It will parse through user code, looking for tasks, workflows and launch plans, and compile them down to Protobuf files. From 0f4fd449260252d75f437d78d03271f5aba4e6ae Mon Sep 17 00:00:00 2001 From: SmritiSatyanV Date: Wed, 10 Aug 2022 12:30:18 +0530 Subject: [PATCH 2/5] update clis.rst Changes based on comments Signed-off-by: SmritiSatyanV smriti@union.ai --- docs/source/design/clis.rst | 59 ++++++++++++++++++++++--------------- 1 file changed, 36 insertions(+), 23 deletions(-) diff --git a/docs/source/design/clis.rst b/docs/source/design/clis.rst index 38e3eb903c..44e5990057 100644 --- a/docs/source/design/clis.rst +++ b/docs/source/design/clis.rst @@ -23,37 +23,38 @@ Command Line Interfaces *********************** Flytectl -=========== -``flytectl`` is the general CLI that can be used to communicate with the Flyte control plane (FlyteAdmin). It ships with flytekit as part of the Pypi package. Think of this as the ``kubectl`` for Flyte. -Think of this CLI as a network-aware (can talk to Admin) but not code-aware (doesn't need to have user code checked out) CLI. In the registration flow, this CLI is responsible for shipping the compiled Protobuf files off to Flyte Admin. +========= + +``flytectl`` is the general CLI to communicate with the Flyte control plane (FlyteAdmin). It ships with flytekit as part of the Pypi package. Think of this as the ``kubectl`` for Flyte. + +Think of this as a network-aware (can talk to admin) but not code-aware (no need to have user code checked out) CLI. In the registration flow, this CLI is responsible for shipping the compiled Protobuf files off to Flyte Admin. Pyflyte -========= -Unlike flytectl, think of this CLI as code-aware, but not network-aware (the latter is not entirely true, but it's helpful to think of it that way). +======== -This CLI is responsible for the serialization (compilation) step in the registration flow. It will parse through the user code, looking for tasks, workflows and launch plans, and compile them to protobuf files. +Unlike flytectl, think of this CLI as code-aware, which is responsible for the serialization (compilation) step in the registration flow. It will parse through the user code, looking for tasks, workflows, and launch plans, and compile them to protobuf files. What is ``pyflyte register``? ============================= -``pyflyte register`` is a command that registers all the workflows present in the repository/directory using fast-registration. It is equivalent to using two commands (``pyflyte package`` and ``flytectl register``) to perform the same operation (registration). -The ``pyflyte package`` command parses and compiles the user’s Python code into Flyte protobuf objects. -The ``flytectl register`` command ships the protobuf objects over the network to Flyte control plane, wherein ``flytectl`` also allows adding attributes such as IAM role, K8s service account, and so on. -Why should you use ``pyflyte register``? -======================================== -The ``pyflyte register`` command bridges the gap between ``pyflyte package`` + ``flytectl register``and ``pyflyte run`` commands. It offers the functionality of the ``pyflyte package`` (with smarter naming semantics and combines the network call into one step), by registering all the workflows in the repository, and the convenience of the ``pyflyte run``, by launching the execution of a single workflow. +``pyflyte register`` is a command that registers all the workflows present in the repository/directory using fast-registration. It is equivalent to using two commands (``pyflyte package`` and ``flytectl register``) to perform the same operation (registration). -.. note :: +The ``pyflyte package`` command parses and compiles the user’s Python code into Flyte protobuf objects. These compiled objects are not stored, which makes it difficult to introspect the objects. - You can’t use ``pyflyte register`` if you are unaware of the run-time options yet(IAM role, service account, and so on). +The ``flytectl register`` command ships the protobuf objects over the network to the Flyte control plane, wherein ``flytectl`` also allows adding attributes such as IAM role, K8s service account, and so on. -What is ``pyflyte run``? +What is ``pyflyte run``? ======================== -The ``pyflyte run`` command is a light-weight, convenience command that combines packaging, registering and launching a workflow in a single command. -It is not a fully featured production scale mode of operation, because it -is designed to be a quick and easy iteration tool to get started with Flyte or test small self-contained scripts. The caveat here is it operates on a single file, and this file will have to contain all the required Flyte entities. Let’s take an example so that you can understand it better. -Suppose you execute a script that defines 10 tasks and a workflow that calls only 2 out of the 10 tasks, the remaining 8 tasks don’t get registered at that point. -It is considered fast registration because when a script is executed using ``pyflyte run``, the script is zipped up and sent to FlyteAdmin. When the task is executed in the backend, this zipped file is extracted and used. + +The ``pyflyte run`` command is a light-weight, convenience command that incorporates packaging, registering, and launching a workflow into a single command. + +It is not a fully featured production scale mode of operation, because it is designed to be a quick and easy iteration tool to get started with Flyte or test small self-contained scripts. The caveat here is it operates on a single file, and this file will have to contain all the required Flyte entities. Let’s take an example so that you can understand it better. + +Suppose you execute a script that defines 10 tasks and a workflow that calls only 2 out of the 10 tasks. The remaining 8 tasks don’t get registered at that point. + +It is considered fast registration because when a script is executed using ``pyflyte run``, the script is bundled up and uploaded to FlyteAdmin. When the task is executed in the backend, this zipped file is extracted and used. + +``pyflyte run`` produces a **portable** package (a .tgz file) of Flyte entities, which helps introspect them at a later time too. You can register this package with multiple Flyte backends. You can save this package, use it for audit, register with a different admin, and so on. Usage ===== @@ -66,10 +67,22 @@ Usage Neither ``pyflyte register`` nor ``pyflyte run`` commands work on Python namespace packages since both the tools traverse the filesystem to find the first folder that doesn't have an __init__.py file, which is interpreted as the root of the project. Both the commands use this root as the basis to name the Flyte entities. -In a broad way, ``pyflyte register`` is equivalent to ``pyflyte run`` minus launching workflow with the exception that ``pyflyte run`` can only register a single workflow whereas ``pyflyte register`` can register all workflows in a repository. +In a broad way, ``pyflyte register`` is equivalent to ``pyflyte run`` minus launching workflows, with the exception that ``pyflyte run`` can only register a single workflow, whereas ``pyflyte register`` can register all workflows in a repository. + +Why should you use ``pyflyte register``? +======================================== + +The ``pyflyte register`` command bridges the gap between ``pyflyte package`` + ``flytectl register``and ``pyflyte run`` commands. It offers the functionality of the ``pyflyte package`` (with smarter naming semantics and combines the network call into one step), by only registering all the workflows in the repository. + +.. note :: + + You can’t use ``pyflyte register`` if you are unaware of the run-time options yet(IAM role, service account, and so on). Should I use ``pyflyte run`` or ``pyflyte package`` + ``flytectl register``? ============================================================================ -``pyflyte run`` is convenient when you are starting out with Flyte, and testing small scripts. -``pyflyte package`` + ``flytectl register`` is convenient when you want to zip your files (that constitutes all your tasks and workflows) into a single portable file and pass it on to another developer to register it. +Both the commands have their own place in a production Flyte setting. + +``pyflyte run`` is convenient when you are starting out with Flyte, testing small scripts, or iterating over local scripts. + +``pyflyte package`` + ``flytectl register`` is useful for single admin use-cases where you want to zip your files (that constitute all your tasks and workflows) into a single portable file and pass it on to another developer/location to register it or run something in CI. \ No newline at end of file From c30d47965899a8b23ab4cb813af8aa60ae39a5d8 Mon Sep 17 00:00:00 2001 From: SmritiSatyanV Date: Wed, 10 Aug 2022 12:59:48 +0530 Subject: [PATCH 3/5] update clis.rst Fixed end-of-file error Signed-off-by: SmritiSatyanV smriti@union.ai --- docs/source/design/clis.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/source/design/clis.rst b/docs/source/design/clis.rst index 44e5990057..aae25b7e07 100644 --- a/docs/source/design/clis.rst +++ b/docs/source/design/clis.rst @@ -85,4 +85,4 @@ Both the commands have their own place in a production Flyte setting. ``pyflyte run`` is convenient when you are starting out with Flyte, testing small scripts, or iterating over local scripts. -``pyflyte package`` + ``flytectl register`` is useful for single admin use-cases where you want to zip your files (that constitute all your tasks and workflows) into a single portable file and pass it on to another developer/location to register it or run something in CI. \ No newline at end of file +``pyflyte package`` + ``flytectl register`` is useful for single admin use-cases where you want to zip your files (that constitute all your tasks and workflows) into a single portable file and pass it on to another developer/location to register it or run something in CI. From e16b330b72dd4dc6808a6085563088ffeb6b32bb Mon Sep 17 00:00:00 2001 From: SmritiSatyanV Date: Thu, 11 Aug 2022 23:25:00 +0530 Subject: [PATCH 4/5] updated clis.rst Fixed wrong statements Signed-off-by: SmritiSatyanV smriti@union.ai --- docs/source/design/clis.rst | 63 ++++++++++++++++++++----------------- 1 file changed, 35 insertions(+), 28 deletions(-) diff --git a/docs/source/design/clis.rst b/docs/source/design/clis.rst index aae25b7e07..ca1f4fc422 100644 --- a/docs/source/design/clis.rst +++ b/docs/source/design/clis.rst @@ -11,7 +11,7 @@ Clients ******* The client code is located in ``flytekit/clients`` and there are two. -* Similar to the :ref:`design-models` files, but a bit more complex, the ``raw`` one is basically a wrapper around the Protobuf generated code, with some handling for authentication in place, and acts as a mechanism for autocompletion and comments. +* Similar to the :ref:`design-models` files, but a bit more complex, the ``raw`` one is basically a wrapper around the protobuf generated code, with some handling for authentication in place, and acts as a mechanism for autocompletion and comments. * The ``friendly`` client uses the ``raw`` client, adds handling of things like pagination, and is structurally more aligned with the functionality and call pattern of the CLI itself. .. autoclass:: flytekit.clients.friendly.SynchronousFlyteClient @@ -25,23 +25,14 @@ Command Line Interfaces Flytectl ========= -``flytectl`` is the general CLI to communicate with the Flyte control plane (FlyteAdmin). It ships with flytekit as part of the Pypi package. Think of this as the ``kubectl`` for Flyte. +`Flytectl `__ is the general CLI to communicate with the Flyte control plane (FlyteAdmin). Think of this as the ``kubectl`` for Flyte. Think of this as a network-aware (can talk to admin) but not code-aware (no need to have user code checked out) CLI. In the registration flow, this CLI is responsible for shipping the compiled Protobuf files off to Flyte Admin. Pyflyte ======== -Unlike flytectl, think of this CLI as code-aware, which is responsible for the serialization (compilation) step in the registration flow. It will parse through the user code, looking for tasks, workflows, and launch plans, and compile them to protobuf files. - -What is ``pyflyte register``? -============================= - -``pyflyte register`` is a command that registers all the workflows present in the repository/directory using fast-registration. It is equivalent to using two commands (``pyflyte package`` and ``flytectl register``) to perform the same operation (registration). - -The ``pyflyte package`` command parses and compiles the user’s Python code into Flyte protobuf objects. These compiled objects are not stored, which makes it difficult to introspect the objects. - -The ``flytectl register`` command ships the protobuf objects over the network to the Flyte control plane, wherein ``flytectl`` also allows adding attributes such as IAM role, K8s service account, and so on. +Unlike ``flytectl``, think of this CLI as code-aware, which is responsible for the serialization (compilation) step in the registration flow. It will parse through the user code, looking for tasks, workflows, and launch plans, and compile them to protobuf files. What is ``pyflyte run``? ======================== @@ -54,35 +45,51 @@ Suppose you execute a script that defines 10 tasks and a workflow that calls onl It is considered fast registration because when a script is executed using ``pyflyte run``, the script is bundled up and uploaded to FlyteAdmin. When the task is executed in the backend, this zipped file is extracted and used. -``pyflyte run`` produces a **portable** package (a .tgz file) of Flyte entities, which helps introspect them at a later time too. You can register this package with multiple Flyte backends. You can save this package, use it for audit, register with a different admin, and so on. - -Usage -===== - -.. prompt:: bash $ +What is ``pyflyte register``? +============================= - pyflyte --config ~/.flyte/dev-uniondemo.yaml register --image ghcr.io/flyteorg/flytecookbook:core-latest --image trainer=ghcr.io/flyteorg/flytecookbook:core-latest --image predictor=ghcr.io/flyteorg/flytecookbook:core-latest --raw-data-prefix s3://development-service-flyte/reltsts flyte_basics +``pyflyte register`` is a command that registers all the workflows present in the repository/directory using fast-registration. It is equivalent to using two commands (``pyflyte package`` and ``flytectl register``) to perform the same operation (registration). It compiles the Python code into protobuf objects and uploads the files directly to FlyteAdmin. In the process, the protobuf objects are not written to the local disk, making it difficult to introspect these objects since they are lost. -.. note :: +The ``pyflyte package`` command parses and compiles the user’s Python code into Flyte protobuf objects. These compiled objects are stored as protobuf files and are available locally after you run the ``pyflyte package``. - Neither ``pyflyte register`` nor ``pyflyte run`` commands work on Python namespace packages since both the tools traverse the filesystem to find the first folder that doesn't have an __init__.py file, which is interpreted as the root of the project. Both the commands use this root as the basis to name the Flyte entities. +The ``flytectl register`` command then ships the protobuf objects over the network to the Flyte control plane. In the process, ``flytectl`` also allows you to set run-time attributes such as IAM roles, K8s service accounts, etc. -In a broad way, ``pyflyte register`` is equivalent to ``pyflyte run`` minus launching workflows, with the exception that ``pyflyte run`` can only register a single workflow, whereas ``pyflyte register`` can register all workflows in a repository. +``pyflyte package + flytectl register`` produces a **portable** package (a .tgz file) of Flyte entities (compiled protobuf files that are stored on the local disk), which makes it easy to introspect the objects at a later time if required. You can use register this package with multiple Flyte backends. You can save this package, use it for an audit, register with different admins, etc. Why should you use ``pyflyte register``? ======================================== -The ``pyflyte register`` command bridges the gap between ``pyflyte package`` + ``flytectl register``and ``pyflyte run`` commands. It offers the functionality of the ``pyflyte package`` (with smarter naming semantics and combines the network call into one step), by only registering all the workflows in the repository. +The ``pyflyte register`` command bridges the gap between ``pyflyte package`` + ``flytectl register`` and ``pyflyte run`` commands. It offers the functionality of the ``pyflyte package`` (with smarter naming semantics and combining the network call into one step). .. note :: - You can’t use ``pyflyte register`` if you are unaware of the run-time options yet(IAM role, service account, and so on). + You can’t use ``pyflyte register`` if you are unaware of the run-time options yet (IAM role, service account, and so on). -Should I use ``pyflyte run`` or ``pyflyte package`` + ``flytectl register``? -============================================================================ +Usage +===== + +.. prompt:: bash $ + + pyflyte register --image ghcr.io/flyteorg/flytecookbook:core-latest --image trainer=ghcr.io/flyteorg/flytecookbook:core-latest --image predictor=ghcr.io/flyteorg/flytecookbook:core-latest --raw-data-prefix s3://development-service-flyte/reltsts flyte_basics + +In a broad way, ``pyflyte register`` is equivalent to ``pyflyte run`` minus launching workflows, with the exception that ``pyflyte run`` can only register a single workflow, whereas ``pyflyte register`` can register all workflows in a repository. + +What is the difference between ``pyflyte package + flytectl register`` and ``pyflyte register``? +============================================================================================== + +``pyflyte package + flytectl register`` works well with multiple admins since it produces a portable package. You can also use it to run scripts in CI. + +``pyflyte register`` works well in single admin use-cases and cases where you are iterating locally. + +Should you use ``pyflyte run`` or ``pyflyte package + flytectl register``? +========================================================================== Both the commands have their own place in a production Flyte setting. -``pyflyte run`` is convenient when you are starting out with Flyte, testing small scripts, or iterating over local scripts. +``pyflyte run`` is useful when you are getting started with Flyte, testing small scripts, or iterating over local scripts. + +``pyflyte package + flytectl register`` is useful when you wish to work with multiple admins, wherein you can package the script, compile it into protobuf objects, write it to local disk, and upload this zipped package to different FlyteAdmins. -``pyflyte package`` + ``flytectl register`` is useful for single admin use-cases where you want to zip your files (that constitute all your tasks and workflows) into a single portable file and pass it on to another developer/location to register it or run something in CI. +.. note :: + + Neither ``pyflyte register`` nor ``pyflyte run`` commands work on Python namespace packages since both the tools traverse the filesystem to find the first folder that doesn't have an __init__.py file, which is interpreted as the root of the project. Both the commands use this root as the basis to name the Flyte entities. From a273ba61da63647ff1c091f4f95ed15a01e615c0 Mon Sep 17 00:00:00 2001 From: SmritiSatyanV Date: Fri, 12 Aug 2022 14:46:57 +0530 Subject: [PATCH 5/5] Changes based on review comments Signed-off-by: SmritiSatyanV smriti@union.ai --- docs/source/design/clis.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/source/design/clis.rst b/docs/source/design/clis.rst index ca1f4fc422..cd6632b8b9 100644 --- a/docs/source/design/clis.rst +++ b/docs/source/design/clis.rst @@ -27,12 +27,12 @@ Flytectl `Flytectl `__ is the general CLI to communicate with the Flyte control plane (FlyteAdmin). Think of this as the ``kubectl`` for Flyte. -Think of this as a network-aware (can talk to admin) but not code-aware (no need to have user code checked out) CLI. In the registration flow, this CLI is responsible for shipping the compiled Protobuf files off to Flyte Admin. +Think of this as a network-aware (can talk to FlyteAdmin) but not code-aware (no need to have user code checked out) CLI. In the registration flow, this CLI is responsible for shipping the compiled Protobuf files off to FlyteAdmin. Pyflyte ======== -Unlike ``flytectl``, think of this CLI as code-aware, which is responsible for the serialization (compilation) step in the registration flow. It will parse through the user code, looking for tasks, workflows, and launch plans, and compile them to protobuf files. +Unlike ``flytectl``, think of this CLI as code-aware, which is responsible for the serialization (compilation) step in the registration flow. It will parse through the user code, looking for tasks, workflows, and launch plans, and compile them to `protobuf files `__. What is ``pyflyte run``? ======================== @@ -54,7 +54,7 @@ The ``pyflyte package`` command parses and compiles the user’s Python code int The ``flytectl register`` command then ships the protobuf objects over the network to the Flyte control plane. In the process, ``flytectl`` also allows you to set run-time attributes such as IAM roles, K8s service accounts, etc. -``pyflyte package + flytectl register`` produces a **portable** package (a .tgz file) of Flyte entities (compiled protobuf files that are stored on the local disk), which makes it easy to introspect the objects at a later time if required. You can use register this package with multiple Flyte backends. You can save this package, use it for an audit, register with different admins, etc. +``pyflyte package + flytectl register`` produces a **portable** package (a .tgz file) of Flyte entities (compiled protobuf files that are stored on the local disk), which makes it easy to introspect the objects at a later time if required. You can use register this package with multiple Flyte backends. You can save this package, use it for an audit, register with different FlyteAdmins, etc. Why should you use ``pyflyte register``? ======================================== @@ -77,9 +77,9 @@ In a broad way, ``pyflyte register`` is equivalent to ``pyflyte run`` minus laun What is the difference between ``pyflyte package + flytectl register`` and ``pyflyte register``? ============================================================================================== -``pyflyte package + flytectl register`` works well with multiple admins since it produces a portable package. You can also use it to run scripts in CI. +``pyflyte package + flytectl register`` works well with multiple FlyteAdmins since it produces a portable package. You can also use it to run scripts in CI. -``pyflyte register`` works well in single admin use-cases and cases where you are iterating locally. +``pyflyte register`` works well in single FlyteAdmin use-cases and cases where you are iterating locally. Should you use ``pyflyte run`` or ``pyflyte package + flytectl register``? ========================================================================== @@ -88,7 +88,7 @@ Both the commands have their own place in a production Flyte setting. ``pyflyte run`` is useful when you are getting started with Flyte, testing small scripts, or iterating over local scripts. -``pyflyte package + flytectl register`` is useful when you wish to work with multiple admins, wherein you can package the script, compile it into protobuf objects, write it to local disk, and upload this zipped package to different FlyteAdmins. +``pyflyte package + flytectl register`` is useful when you wish to work with multiple FlyteAdmins, wherein you can package the script, compile it into protobuf objects, write it to local disk, and upload this zipped package to different FlyteAdmins. .. note ::