diff --git a/cookbook/common/leaf.mk b/cookbook/common/leaf.mk index 8de3ff59b3..da6cea8ea7 100644 --- a/cookbook/common/leaf.mk +++ b/cookbook/common/leaf.mk @@ -24,7 +24,7 @@ export FLYTE_AWS_ACCESS_KEY_ID ?= minio # Used to authenticate to s3. For a production AWS S3, it's discouraged to use keys and key ids. export FLYTE_AWS_SECRET_ACCESS_KEY ?= miniostorage -# Instructs flyte-cli commands to use insecure channel when communicating with Flyte's control plane. +# Instructs flytectl commands to use insecure channel when communicating with Flyte's control plane. # If you're port-forwarding your service or running the sandbox Flyte deployment, specify INSECURE=1 before your make command. # If your Flyte Admin is behind SSL, don't specify anything. ifndef INSECURE diff --git a/cookbook/core/scheduled_workflows/lp_schedules.py b/cookbook/core/scheduled_workflows/lp_schedules.py index 4445306b0c..06eee70645 100644 --- a/cookbook/core/scheduled_workflows/lp_schedules.py +++ b/cookbook/core/scheduled_workflows/lp_schedules.py @@ -111,49 +111,20 @@ def positive_wf(name: str): # pyflyte lp -p {{ your project }} -d {{ your domain }} activate-all # %% -# (or) +# or with Flytectl: # -# With flyte-cli: -# -# - View and activate launch plans: flyte-cli -i -h localhost:30081 -p flyteexamples -d development list-launch-plan-versions +# - Activate launch plan: # # .. code-block:: bash # -# flyte-cli -i -h localhost:30081 -p flyteexamples -d development list-launch-plan-versions +# flytectl update launchplan -p flyteexamples -d development {{ name_of_lp }} --activate # %% -# - Extract the URN returned for the launch plan you're interested in and make the call to activate it: +# - Verify if your launch plan got activated: # # .. code-block:: bash # -# flyte-cli update-launch-plan -i -h localhost:30081 --state active -u {{ urn }} -# -# .. tip:: -# The equivalent command in `flytectl `__ is: -# -# .. code-block:: bash -# -# flytectl update launchplan -p flyteexamples -d development {{ name_of_lp }} --activate`` -# -# Example: -# -# .. code-block:: bash -# -# flytectl update launchplan -p flyteexamples -d development core.basic.lp.go_greet --activate - -# %% -# - Verify your active launch plans: -# -# .. code-block:: bash -# -# flyte-cli -i -h localhost:30081 -p flyteexamples -d development list-active-launch-plans -# -# .. tip:: -# The equivalent command in `flytectl `__ is: -# -# .. code-block:: bash -# -# flytectl get launchplan -p flytesnacks -d development`` +# flytectl get launchplan -p flytesnacks -d development # %% # Platform Configuration Changes For AWS Scheduler diff --git a/cookbook/core/type_system/flyte_python_types.py b/cookbook/core/type_system/flyte_python_types.py index bc91178ed5..05aaa90060 100644 --- a/cookbook/core/type_system/flyte_python_types.py +++ b/cookbook/core/type_system/flyte_python_types.py @@ -90,34 +90,4 @@ - Custom Transformers - Use python 3 type hints. We use `FlytePickle transformer `_ by default, but users still can provide custom transformers. Refer to :ref:`advanced_custom_types`. - -.. prompt:: bash - - flyte-cli -h localhost:30081 -i list-launch-plan-versions -p flytesnacks -d development | grep PrimitiveDemoWorkflow - flyte-cli -h localhost:30081 -i execute-launch-plan -p flytesnacks -d development -u -r user -- x=10 y=10.0 s="Hello" b=True - -To retrieve the right LaunchPlan Urn: - -.. prompt:: bash - - flyte-cli -h localhost:30081 -i list-launch-plan-versions -p flytesnacks -d development | grep TimeDemoWorkflow - -Then take the URN and plug here - -.. prompt:: bash - - flyte-cli -h localhost:30081 -i execute-launch-plan -p flytesnacks -d development -u -r kumare -- dt=20200707T00:00Z duration=10H - -The CLI accepts *datetime* and *duration* fields in [RFC3339](https://tools.ietf.org/html/rfc3339 ) formats, which is -usually of the form **YYYYMMDDTHH:MM:SSZ** ``(z -> timezone)``. Duration is of the format **10H** (for 10 hours) or **10S** -or **2D** (days etc) - -.. prompt:: bash - - flyte-cli -p flytesnacks \ - -d development execute-launch-plan \ - -u lp:flytesnacks:development:types.generic.GenericDemoWorkflow:version \ - -r demo \ - -- a='{"a": "hello", "b": "how are you", "c": ["array"], "d": {"nested": "value"}}' - """ diff --git a/cookbook/deployment/deploying_workflows.py b/cookbook/deployment/deploying_workflows.py index 523bbbbde4..6abd569928 100644 --- a/cookbook/deployment/deploying_workflows.py +++ b/cookbook/deployment/deploying_workflows.py @@ -126,19 +126,19 @@ .. code-block:: - flyte-cli register-files -p flytetester -d development -v ${VERSION} --kubernetes-service-account demo \ - --output-location-prefix s3://my-s3-bucket/raw_data -h flyte.example.com _pb_output/* + flytectl register files _pb_output/* -p flytetester -d development --version ${VERSION} \ + --k8sServiceAccount demo --outputLocationPrefix s3://my-s3-bucket/raw_data Of interest are the following args: - :code:`-p` specifies the project to register your entities. This project itself must already be registered on your Flyte deployment. - :code:`-d` specifies the domain to register your entities. This domain must already be configured in your Flyte deployment -- :code:`-v` is a unique string used to identify this version of entities registered under a project and domain. -- If required, you can specify a :code:`kubernetes-service-account` or :code:`assumable_iam_role` which your tasks will run with. +- :code:`--version` is a unique string used to identify the version of your entities to be registered under a project and domain. +- If required, you can specify a :code:`--k8sServiceAccount` and :code:`--assumableIamRole` which your tasks will run with. -Fast(er) iteration +Fast Registration ^^^^^^^^^^^^^^^^^^ Re-building a new Docker container image for every code change you make can become cumbersome and slow. If you're making purely code changes that **do not** require updating your container definition, you can make use of @@ -149,7 +149,7 @@ .. code-block:: - make fast_serialize + pyflyte --pkgs core package --image core:v1 --fast --force And then the fast register target: @@ -161,8 +161,8 @@ As fast registration serializes code from your local workstation and uploads it to the hosted flyte deployment, make sure to specify the following arguments correctly to ensure that the changes are picked up when the workflow is run. -- :code:`pyflyte serialize` has a :code:`--local-source-root` option which specifies which code is uploaded during the fast registration step. This ensures that the files you want to modify are serialized. This is optional and should be used when your code lies outside of your current working directory. -- :code:`flyte-cli fast-register-files` has a :code:`--dest-dir` option which specifies which folder (in the container) the fast serialization will dump the code in at execution time. This ensures that the running workflow loads the code changes that were uploaded via :code:`fast registration`. +- :code:`pyflyte` has a flag :code:`--pkgs` that specifies the code to be packaged. The `fast` flag picks up the code from the local machine and provides it for execution without building and pushing a container. +- :code:`pyflyte` also has a flag :code:`--image` to specify the Docker image that has already been built. Building Images diff --git a/cookbook/deployment/fast_registration.py b/cookbook/deployment/fast_registration.py deleted file mode 100644 index b144b51aca..0000000000 --- a/cookbook/deployment/fast_registration.py +++ /dev/null @@ -1,89 +0,0 @@ -""" -.. _deployment-fast-registration: - -################# -Fast Registration -################# - -.. NOTE:: - Experimental feature (beta) - -To avoid having to wait for an image build to test out simple code changes to your Flyte workflows and reduce iteration cycles to mere seconds, read on below. - -Caveats -======= -Fast registration only works when you're testing out code changes. If you need to update your container by installing a dependency or modifying a Dockerfile, you **must** use the conventional method of committing your changes and rebuilding a container image. - -.. note:: - - Flytekit releases before the introduction of native typing have a slightly modified workflow for fast-registering. Please check the below-highlighted sections if your Flytkit version is < ``0.16.0``. - -Pre-requisites -============== -Upgrade your Flytekit dependency to ``>= 0.16.0`` and re-run pip-tools if necessary. - -.. admonition:: Flytkit < 0.16.0 - - You'll need to update your development flyte config and add a new required parameter to the SDK block specifying an intermittent directory for code distributions. Whichever role you use in the [auth] block must have read access to this directory. For example: - - .. code-block:: bash - - [sdk] - fast_registration_dir=s3://my-s3-bucket/distributions/ - -You'll need to build a base image with these changes incorporated before you can use fast registration. - -Steps to Follow -=============== - -1. After the above pre-requisite changes are merged, pull the latest master and create a development branch on your local machine. -2. Make some code changes. -3. Save your files. -4. Clear and create (or, clear or create) the directory used to store your serialized code archive: - -.. code-block:: bash - - mkdir _pb_output || true - rm -f _pb_output/*.tar.gz - -.. admonition:: Flytkit < 0.16.0 - - Step 4 is not required. - -5. Assume a role that has the write access to the intermittent directory you'll use to store fast registration code distributions. -6. Using a Python environment with Flytekit installed, fast-register your changes: - -.. code-block:: bash - - pyflyte -c sandbox.config --pkgs recipes serialize --in-container-config-path /root/sandbox.config \ - --local-source-root --image fast workflows -f _pb_output/ - -Or, from within your container: - -.. code-block:: bash - - pyflyte --config /root/sandbox.config serialize fast workflows -f _pb_output/ - -.. admonition:: Flytkit < 0.16.0 - - The command to fast-register the changes is: - - .. code-block:: bash - - flytekit_venv pyflyte -p myproject -d development -v -c /code/myproject/development.config fast-register workflows --source-dir /code/myproject/ - -7. Next, fast-register your serialized files. You'll note the overlap with the existing register command (auth role and output location) but with a new flag pointing to an additional distribution dir. This must be writable from the role you assume and readable from the role your Flytepropeller assumes. - -.. code-block:: bash - - flyte-cli fast-register-files -p flytetester -d development --kubernetes-service-account ${FLYTE_AUTH_KUBERNETES_SERVICE_ACCOUNT} \ - --output-location-prefix ${FLYTE_AUTH_RAW_OUTPUT_DATA_PREFIX} -h ${FLYTE_PLATFORM_URL} \ - --additional-distribution-dir ${FLYTE_SDK_FAST_REGISTRATION_DIR} _pb_output/* - -.. admonition:: Flytekit < 0.16.0 - - Step 7 is not required. - -8. Open the Flyte UI and launch the latest version of your workflow (under the domain you fast-registered above). It should run with your new code! - -""" diff --git a/cookbook/docs/README.md b/cookbook/docs/README.md index 6dec55f4d2..17383f4efa 100644 --- a/cookbook/docs/README.md +++ b/cookbook/docs/README.md @@ -26,6 +26,6 @@ To make this work, it is essential that the examples are written with comments f ```rst .. prompt::bash - flyte-cli test + flytectl --version ``` diff --git a/cookbook/docs/conf.py b/cookbook/docs/conf.py index 515948938f..68b8697187 100644 --- a/cookbook/docs/conf.py +++ b/cookbook/docs/conf.py @@ -85,7 +85,6 @@ class CustomSorter(FileNameSortKey): "deploying_workflows.py", "customizing_resources.py", "lp_notifications.py", - "fast_registration.py", "multiple_k8s.py", ## Cluster "config_flyte_deploy.py",