Updates to Getting Started docs (#485)

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
+
+

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<https://github.com/lyft/flyte/blob/2905b8d48263bc194dc3a61d49015c5abda81f5e/kustomize/overlays/sandbox/console/config.yaml#L12>`
+  - If you have difficulty please slack us in the channel
+

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``.