diff --git a/rsts/administrator/faq/gcp.rst b/rsts/administrator/faq/gcp.rst new file mode 100644 index 0000000000..6e00f78d6f --- /dev/null +++ b/rsts/administrator/faq/gcp.rst @@ -0,0 +1,23 @@ + +Installed Single Cluster mode on GCP, what examples do I use? +-------------------------------------------------------------- + + +I tried to run examples, but task fails with 401 error? +------------------------------------------------------- + Steps: + - Are you using Workload Identity, then you have to pass in the ServiceAccount when you create the launchplan. Docs here https://lyft.github.io/flyte/user/features/roles.html?highlight=serviceaccount#kubernetes-serviceaccount-examples + More information about WorkloadIdentity at https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity + + - If you are just using a simple Nodepool wide permissions then check the cluster's ServiceACcount for STorage permissions. Do they look fine? + + - If not, then start a dummy pod in the intended namespace and check for + .. + + gcloud auth list + + + NOTE: + FlytePropeller uses Google Application credentials, but gsutil does not use these credentials + + diff --git a/rsts/administrator/faq/index.rst b/rsts/administrator/faq/index.rst new file mode 100644 index 0000000000..e69de29bb2 diff --git a/rsts/administrator/install/getting_started.rst b/rsts/administrator/install/getting_started.rst index e7c3d17fce..679112a8ff 100644 --- a/rsts/administrator/install/getting_started.rst +++ b/rsts/administrator/install/getting_started.rst @@ -57,3 +57,13 @@ SPECIAL NOTE FOR MINIKUBE: - Another alternative is to change the docker host, to build the docker image on the Minikube hosted docker daemon. https://minikube.sigs.k8s.io/docs/handbook/pushing/ provides more detailed information about this process. As a TL;DR, Flyte can only run images that are accessible to Kubernetes. To make an image accessible, you could either push it to a remote registry or to a regisry that is available to Kuberentes. In case on minikube this registry is the one thats running on the VM. + +SPECIAL NOTE IF YOU WANT TO PORT FORWARD Flyteconsole: + - FlyteConsole defaults to using its own ``window.location.origin`` as the host for FlyteAdmin service. This is because the default Flyte Sandbox setup uses an ingress configuration, where + ``/console`` maps to FlyteConsole and ``/api/v1`` and some other ``paths`` map to FlyteAdmin. Refer to `components-console` to dive deeper. + - If you are port-forwarding then forwarding both FlyteConsole and FlyteAdmin on the same port may not be possible (I am not aware of a way, unless you do some IPTable tricks), thus you need to let + FlyteConsole know where to find FlyteAdmin. + - This can be easily configured using ``flyte-console-configuration``. The way to do this is to set ``ADMIN_API_URL`` variable for FlyteConsole and then "restarting" flyteconsole pod. `The variable + is commented out in the default configuration` + - If you have difficulty please slack us in the channel + diff --git a/rsts/user/getting_started/examples.rst b/rsts/user/getting_started/examples.rst index 7f24584314..426fec98e8 100644 --- a/rsts/user/getting_started/examples.rst +++ b/rsts/user/getting_started/examples.rst @@ -17,7 +17,7 @@ Registration If you're using the ``sandbox`` flyte installation, you can use the following command to register our example workflow with Flyte :: - docker run --network host -e FLYTE_PLATFORM_URL='127.0.0.1:30081' lyft/flytesnacks:v0.1.0 pyflyte -p flytesnacks -d development -c sandbox.config register workflows + docker run --network host -e FLYTE_PLATFORM_URL='127.0.0.1:30081' lyft/flytesnacks:v0.2.0 pyflyte -p flytesnacks -d development -c sandbox.config register workflows This command will register the workflow with your Flyte app under the ``development`` domain of the project ``flytesnacks``.