links2 (flyteorg#310)

Signed-off-by: SandraGH5 <sandra@union.ai> Co-authored-by: SandraGH5 <sandra@union.ai>
eapolinario · Jun 28, 2021 · afa9270 · afa9270
1 parent 1d2f279
commit afa9270
Show file tree

Hide file tree

Showing 3 changed files with 3 additions and 3 deletions.
diff --git a/cookbook/deployment/cluster/auth_setup.py b/cookbook/deployment/cluster/auth_setup.py
@@ -159,7 +159,7 @@
 
     .. tab:: Okta
 
-        1. Under security -> API, click `Add Authorization Server`. Set the audience to the public URL of flyte admin (e.g. https://flyte.mycompany.io/).
+        1. Under security -> API, click `Add Authorization Server`. Set the audience to the public URL of flyte admin (e.g. ``<https://flyte.mycompany.io/>``).
         2. Under `Access Policies`, click `Add New Access Policy` and walk through the wizard to allow access to the authorization server.
         3. Under `Scopes`, click `Add Scope`. Set the name to `all` (required) and check `Require user consent for this scope` (recommended).
         4. Create 2 apps (for fltyectl and flytepropeller) to enable these clients to communicate with the service.

diff --git a/cookbook/deployment/workflow/multiple_k8s.py b/cookbook/deployment/workflow/multiple_k8s.py
@@ -133,7 +133,7 @@
 Some deployments of Flyte may choose to run the control-plane separate from the data-plane. FlyteAdmin is designed to create Kubernetes resources in one or more Flyte data-plane clusters. 
 For the admin to access remote clusters, it needs credentials to each cluster. 
 In Kubernetes, scoped service credentials are created by configuring a “Role” resource in a Kubernetes cluster. 
-When you attach that role to a “ServiceAccount”, Kubernetes generates a bearer token that permits access. We create a FlyteAdmin `ServiceAccount <https://github.com/flyteorg/flyte/blob/c0339e7cc4550a9b7eb78d6fb4fc3884d65ea945/artifacts/base/adminserviceaccount/adminserviceaccount.yaml>`_ in each data-plane cluster to generate these tokens.
+When you attach that role to a “ServiceAccount”, Kubernetes generates a bearer token that permits access. We create a FlyteAdmin `ServiceAccount <https://github.com/flyteorg/flyte/blob/master/kustomize/base/adminserviceaccount/adminserviceaccount.yaml>`_ in each data-plane cluster to generate these tokens.
 
 When you first create the FlyteAdmin ServiceAccount in a new cluster, a bearer token is generated and will continue to allow access unless the “ServiceAccount “is deleted. Once we create the Flyte Admin ServiceAccount on a cluster, we should never delete it. To feed the credentials to FlyteAdmin, you must retrieve them from your new data-plane cluster, and upload them to admin somehow (within Lyft, we use Confidant, for example).
 

diff --git a/cookbook/integrations/kubernetes/k8s_spark/pyspark_pi.py b/cookbook/integrations/kubernetes/k8s_spark/pyspark_pi.py
@@ -37,7 +37,7 @@
 The plugin is a backend plugin which has to be enabled in your deployment. To enable a plugin follow the steps in :ref:`howto-enable-backend-plugins`.
 
 You can optionally configure the Plugin as per the - `backend Config Structure <https://pkg.go.dev/github.com/flyteorg/flyteplugins@v0.5.25/go/tasks/plugins/k8s/spark#Config>`_ and an example Config is defined
-`here <https://github.com/flyteorg/flyte/blob/master/kustomize/overlays/sandbox/config/propeller/plugins/spark.yaml>`_, which looks like:
+`here <https://github.com/flyteorg/flyte/blob/master/kustomize/overlays/eks/flyte/config/propeller/plugins/spark.yaml>`_, which looks like:
 
 .. rli:: https://raw.githubusercontent.com/flyteorg/flyte/master/kustomize/overlays/sandbox/config/propeller/plugins/spark.yaml
    :language: yaml