From 8f370355c6ddc2e449d8bd36e2b01b367bf21b21 Mon Sep 17 00:00:00 2001 From: Rob Scott Date: Thu, 9 Sep 2021 13:43:40 -0700 Subject: [PATCH] Adding missing references pages to docs navigation --- mkdocs.yml | 4 +++- .../references/cross-namespace-references.md | 2 +- site-src/v1alpha2/references/policy-attachment.md | 12 ++++++------ 3 files changed, 10 insertions(+), 8 deletions(-) diff --git a/mkdocs.yml b/mkdocs.yml index 9a8e4b254a..3379e3bda6 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -62,7 +62,9 @@ nav: GatewayClass: v1alpha2/api-types/gatewayclass.md Gateway: v1alpha2/api-types/gateway.md HTTPRoute: v1alpha2/api-types/httproute.md - - API specification: v1alpha2/references/spec.md + - API specification: v1alpha2/references/spec.md + - Cross Namespace References: v1alpha2/references/cross-namespace-references.md + - Policy Attachment: v1alpha2/references/policy-attachment.md - Release policy: references/releases.md - Contributing: - Developer guide: contributing/devguide.md diff --git a/site-src/v1alpha2/references/cross-namespace-references.md b/site-src/v1alpha2/references/cross-namespace-references.md index 7fd3246efa..b5520497a7 100644 --- a/site-src/v1alpha2/references/cross-namespace-references.md +++ b/site-src/v1alpha2/references/cross-namespace-references.md @@ -34,7 +34,7 @@ we need to enforce a handshake mechanism that requires resources in both namespaces to agree to this reference. To accomplish that, a ReferencePolicy resource has been introduced. -![Reference Policy](images/referencepolicy.png) +![Reference Policy](/v1alpha2/references/images/referencepolicy.png) With this model, Routes are able to directly reference Services in other namespaces. These references are only considered valid if a ReferencePolicy in the target diff --git a/site-src/v1alpha2/references/policy-attachment.md b/site-src/v1alpha2/references/policy-attachment.md index 8eeb9aa158..fa56934ee4 100644 --- a/site-src/v1alpha2/references/policy-attachment.md +++ b/site-src/v1alpha2/references/policy-attachment.md @@ -28,7 +28,7 @@ Access is granted with RBAC - for example, anyone that has access to create a RetryPolicy in a given namespace can attach it to any resource within that namespace. -![Simple Ingress Example](/images/policy/ingress-simple.png) +![Simple Ingress Example](/v1alpha2/references/images/policy/ingress-simple.png) To build on that example, it’s possible to attach policies to more resources. Each policy applies to the referenced resource and everything below it in terms @@ -36,7 +36,7 @@ of hierarchy. Although this example is likely more complex than many real world use cases, it helps demonstrate how policy attachment can work across namespaces. -![Complex Ingress Example](/images/policy/ingress-complex.png) +![Complex Ingress Example](/v1alpha2/references/images/policy/ingress-complex.png) ## Policy Attachment for Mesh Although there is a great deal of overlap between ingress and mesh use cases, @@ -44,7 +44,7 @@ mesh enables more complex policy attachment scenarios. For example, users may want to apply policy to requests from a specific namespace to a backend in another namespace. -![Simple Mesh Example](/images/policy/mesh-simple.png) +![Simple Mesh Example](/v1alpha2/references/images/policy/mesh-simple.png) Policy attachment can be quite simple with mesh. Policy can be applied to any resource in any namespace but it can only apply to requests from the same @@ -55,7 +55,7 @@ workload to a backend in another namespace. A route can be used to intercept these requests and split them between different backends (foo-a and foo-b in this case). -![Complex Mesh Example](/images/policy/mesh-complex.png) +![Complex Mesh Example](/v1alpha2/references/images/policy/mesh-complex.png) ## Target Reference API @@ -124,7 +124,7 @@ Each policy MAY include default or override values. Overrides enable admins to enforce policy from the top down. Defaults enable app owners to provide default values from the bottom up for each individual application. -![Policy Hierarchy](/images/policy/hierarchy.png) +![Policy Hierarchy](/v1alpha2/references/images/policy/hierarchy.png) To illustrate this, consider 3 resources with the following hierarchy: A (highest) > B > C. When attaching the concept of defaults and overrides to that, @@ -179,7 +179,7 @@ precedence over the default drainTimeout value attached to the Route. At the same time, we can see that the default connectionTimeout attached to the Route has precedence over the default attached to the Gateway. -![Hierarchical Policy Example](/images/policy/policy-hierarchy.png) +![Hierarchical Policy Example](/v1alpha2/references/images/policy/policy-hierarchy.png) #### Attaching Policy to GatewayClass GatewayClass may be the trickiest resource to attach policy to. Policy