Deployed 6c75482 to 0.8.0 with MkDocs 1.5.3 and mike 2.1.0

0.8.0/kuadrant-operator/doc/auth/index.html

@@ -4610,9 +4610,9 @@ <h3 id="route-selectors">Route selectors<a class="headerlink" href="#route-selec
 <h4 id="when-conditions"><code>when</code> conditions<a class="headerlink" href="#when-conditions" title="Permanent link">&para;</a></h4>
 <p><code>when</code> conditions can be used to scope an AuthPolicy or auth rule within an AuthPolicy (i.e. to filter the traffic to which a policy or policy rule applies) without any coupling to the underlying network topology, i.e. without making direct references to HTTPRouteRules via <a href="../reference/route-selectors/#the-routeselectors-field"><code>routeSelectors</code></a>.</p>
 <p>Use <code>when</code> conditions to conditionally activate policies and policy rules based on attributes that cannot be expressed in the HTTPRoutes' <code>spec.hostnames</code> and <code>spec.rules.matches</code> fields, or in general in AuthPolicies that target a Gateway.</p>
-<p><code>when</code> conditions in an AuthPolicy are compatible with Authorino <a href="https://docs.kuadrant.io/authorino/docs/features/#common-feature-conditions-when">conditions</a>, thus supporting complex boolean expressions with AND and OR operators, as well as grouping.</p>
+<p><code>when</code> conditions in an AuthPolicy are compatible with Authorino <a href="https://docs.kuadrant.io/latest/authorino/docs/features/#common-feature-conditions-when">conditions</a>, thus supporting complex boolean expressions with AND and OR operators, as well as grouping.</p>
 <p>The selectors within the <code>when</code> conditions of an AuthPolicy are a subset of Kuadrant's Well-known Attributes (<a href="https://github.com/Kuadrant/architecture/blob/main/rfcs/0002-well-known-attributes.md">RFC 0002</a>). Check out the reference for the full list of supported selectors.</p>
-<p>Authorino <a href="https://docs.kuadrant.io/authorino/docs/features/#string-modifiers">JSON path string modifiers</a> can also be applied to the selectors within the <code>when</code> conditions of an AuthPolicy.</p>
+<p>Authorino <a href="https://docs.kuadrant.io/latest/authorino/docs/features/#string-modifiers">JSON path string modifiers</a> can also be applied to the selectors within the <code>when</code> conditions of an AuthPolicy.</p>
 <h3 id="examples">Examples<a class="headerlink" href="#examples" title="Permanent link">&para;</a></h3>
 <p>Check out the following user guides for examples of protecting services with Kuadrant:</p>
 <ul>
@@ -4694,7 +4694,7 @@ <h4 id="limitation-multiple-network-resources-with-identical-hostnames">Limitati
 <p>Once again, requests to <code>app.io/foo</code> will be protected under AuthPolicy <code>policy-1</code>, while requests to <code>app.io/bar</code> will <strong>not</strong> be protected under any policy at all, unlike expected gateway policy <code>policy-2</code> enforced as default. Both policies will report status condition as <code>Enforced</code> nonetheless.</p>
 <p>To avoid these problems, use different hostnames in each route.</p>
 <h2 id="implementation-details">Implementation details<a class="headerlink" href="#implementation-details" title="Permanent link">&para;</a></h2>
-<p>Under the hood, for each AuthPolicy, Kuadrant creates an Istio <a href="https://istio.io/latest/docs/reference/config/security/authorization-policy"><code>AuthorizationPolicy</code></a> and an Authorino <a href="https://docs.kuadrant.io/authorino/docs/architecture/#the-authorino-authconfig-custom-resource-definition-crd"><code>AuthConfig</code></a> custom resources.</p>
+<p>Under the hood, for each AuthPolicy, Kuadrant creates an Istio <a href="https://istio.io/latest/docs/reference/config/security/authorization-policy"><code>AuthorizationPolicy</code></a> and an Authorino <a href="https://docs.kuadrant.io/latest/authorino/docs/architecture/#the-authorino-authconfig-custom-resource-definition-crd"><code>AuthConfig</code></a> custom resources.</p>
 <p>Only requests that matches the rules in the Istio <code>AuthorizationPolicy</code> cause an authorization request to be sent to the external authorization service ("Authorino"), i.e., only requests directed to the HTTPRouteRules targeted by the AuthPolicy (directly or indirectly), according to the declared top-level route selectors (if present), or all requests for which a matching HTTPRouteRule exists (otherwise).</p>
 <p>Authorino looks up for the auth scheme (<code>AuthConfig</code> custom resource) to enforce using the provided hostname of the original request as key. It then checks again if the request matches at least one of the selected HTTPRouteRules, in which case it enforces the auth scheme.</p>
 <details>

0.8.0/kuadrant-operator/doc/install/install-openshift/index.html

@@ -4291,15 +4291,15 @@ <h3 id="step-4-optional-configure-observability-and-metrics">Step 4 - Optional:
 <li><a href="https://docs.openshift.com/container-platform/latest/observability/monitoring/configuring-the-monitoring-stack.html#configuring_remote_write_storage_configuring-the-monitoring-stack">OpenShift remote write configuration</a></li>
 <li><a href="https://github.com/thanos-io/kube-thanos">Kube Thanos</a></li>
 </ul>
-<p>The <a href="https://docs.kuadrant.io/kuadrant-operator/doc/observability/examples/">example dashboards and alerts</a> for observing Kuadrant functionality use low-level CPU metrics and network metrics available from the user monitoring stack in OpenShift. They also use resource state metrics from Gateway API and Kuadrant resources. </p>
+<p>The <a href="https://docs.kuadrant.io/latest/kuadrant-operator/doc/observability/examples/">example dashboards and alerts</a> for observing Kuadrant functionality use low-level CPU metrics and network metrics available from the user monitoring stack in OpenShift. They also use resource state metrics from Gateway API and Kuadrant resources. </p>
 <p>To scrape these additional metrics, you can install a <code>kube-state-metrics instance</code>, with a custom resource configuration as follows:</p>
 <div class="language-bash highlight"><pre><span></span><code><span id="__span-7-1"><a id="__codelineno-7-1" name="__codelineno-7-1" href="#__codelineno-7-1"></a>kubectl<span class="w"> </span>apply<span class="w"> </span>-f<span class="w"> </span>https://raw.githubusercontent.com/Kuadrant/kuadrant-operator/main/config/observability/openshift/kube-state-metrics.yaml
 </span><span id="__span-7-2"><a id="__codelineno-7-2" name="__codelineno-7-2" href="#__codelineno-7-2"></a>kubectl<span class="w"> </span>apply<span class="w"> </span>-k<span class="w"> </span>https://github.com/Kuadrant/gateway-api-state-metrics?ref<span class="o">=</span>main
 </span></code></pre></div>
 <p>To enable request metrics in Istio, you must create a <code>telemetry</code> resource as follows:</p>
 <div class="language-bash highlight"><pre><span></span><code><span id="__span-8-1"><a id="__codelineno-8-1" name="__codelineno-8-1" href="#__codelineno-8-1"></a>kubectl<span class="w"> </span>apply<span class="w"> </span>-f<span class="w"> </span>https://raw.githubusercontent.com/Kuadrant/kuadrant-operator/main/config/observability/openshift/telemetry.yaml
 </span></code></pre></div>
-<p>If you have Grafana installed in your cluster, you can import the <a href="https://docs.kuadrant.io/kuadrant-operator/doc/observability/examples">example dashboards and alerts</a>.</p>
+<p>If you have Grafana installed in your cluster, you can import the <a href="https://docs.kuadrant.io/latest/kuadrant-operator/doc/observability/examples">example dashboards and alerts</a>.</p>
 <p>For example installation details, see <a href="https://cloud.redhat.com/experts/o11y/ocp-grafana/">installing Grafana on OpenShift</a>. When installed, you must add your Thanos instance as a data source to Grafana. Alternatively, if you are using only the user workload monitoring stack in your OpenShift cluster, and not writing metrics to an external Thanos instance, you can <a href="https://docs.openshift.com/container-platform/4.15/observability/monitoring/accessing-third-party-monitoring-apis.html#accessing-metrics-from-outside-cluster_accessing-monitoring-apis-by-using-the-cli">set up a data source to the thanos-querier route in the OpenShift cluster</a>.</p>
 <h3 id="step-5-create-secrets-for-your-credentials">Step 5 - Create secrets for your credentials<a class="headerlink" href="#step-5-create-secrets-for-your-credentials" title="Permanent link">&para;</a></h3>
 <p>Before installing the Kuadrant Operator, you must enter the following commands to set up secrets that you will use later:</p>

0.8.0/kuadrant-operator/doc/observability/examples/index.html

@@ -4042,11 +4042,11 @@ <h3 id="importing-dashboards-into-grafana">Importing Dashboards into Grafana<a c
 </li>
 <li><strong>ConfigMap Method:</strong> Automate dashboard provisioning by adding files to a ConfigMap, which should be mounted at <code>/etc/grafana/provisioning/dashboards</code>.</li>
 </ul>
-<p>Datasources are configured as template variables, automatically integrating with your existing data sources. Metrics for these dashboards are sourced from <a href="https://github.com/prometheus/prometheus">Prometheus</a>. For more details on the metrics used, visit the <a href="https://docs.kuadrant.io/kuadrant-operator/doc/observability/metrics/">metrics</a> documentation page.</p>
+<p>Datasources are configured as template variables, automatically integrating with your existing data sources. Metrics for these dashboards are sourced from <a href="https://github.com/prometheus/prometheus">Prometheus</a>. For more details on the metrics used, visit the <a href="https://docs.kuadrant.io/latest/kuadrant-operator/doc/observability/metrics/">metrics</a> documentation page.</p>
 <h2 id="alerts">Alerts<a class="headerlink" href="#alerts" title="Permanent link">&para;</a></h2>
 <h3 id="setting-up-alerts-in-prometheus">Setting Up Alerts in Prometheus<a class="headerlink" href="#setting-up-alerts-in-prometheus" title="Permanent link">&para;</a></h3>
 <p>Integrate alerts into Prometheus using a <code>PrometheusRule</code> resource. Adjust alert thresholds to meet your specific operational needs.</p>
-<p>Further information on the metrics used for these alerts can be found on the <a href="https://docs.kuadrant.io/kuadrant-operator/doc/observability/metrics/">metrics</a> page.</p>
+<p>Further information on the metrics used for these alerts can be found on the <a href="https://docs.kuadrant.io/latest/kuadrant-operator/doc/observability/metrics/">metrics</a> page.</p>
 
 
 

0.8.0/kuadrant-operator/doc/observability/tracing/index.html

@@ -4123,7 +4123,7 @@ <h2 id="troubleshooting-flow-using-traces-and-logs">Troubleshooting Flow Using T
 <p>If you centrally aggregate logs using something like promtail and loki, you can jump between trace information and the relevant logs for that service:</p>
 <p><img alt="Trace and logs in Grafana UI" src="../grafana_tracing_loki.png" /></p>
 <p>Using a combination of tracing and logs, you can visualise and troubleshoot reuqest timing issues and drill down to specific services.
-This method becomes even more powerful when combined with <a href="https://docs.kuadrant.io/kuadrant-operator/doc/observability/metrics/">metrics</a> and <a href="https://docs.kuadrant.io/kuadrant-operator/doc/observability/dashboards/">dashboards</a> to get a more complete picture of your users traffic.</p>
+This method becomes even more powerful when combined with <a href="https://docs.kuadrant.io/latest/kuadrant-operator/doc/observability/metrics/">metrics</a> and <a href="https://docs.kuadrant.io/latest/kuadrant-operator/doc/observability/examples/">dashboards</a> to get a more complete picture of your users traffic.</p>