From c85be7a9aaaae23addeffe1489fee480d2e884d4 Mon Sep 17 00:00:00 2001 From: Kristian Aune Date: Fri, 6 Oct 2023 11:19:33 +0200 Subject: [PATCH] fix broken links --- examples/operations/multinode-HA/README.md | 8 ++++---- examples/operations/multinode-HA/gke/README.md | 4 ++-- examples/operations/multinode/README.md | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/examples/operations/multinode-HA/README.md b/examples/operations/multinode-HA/README.md index bd76b9df8..db8edb597 100644 --- a/examples/operations/multinode-HA/README.md +++ b/examples/operations/multinode-HA/README.md @@ -165,7 +165,7 @@ Notes: For this reason, it is normally a good idea to run this on a separate node, like here - a full disk will not impact other nodes. -Check that the [config sentinel](https://docs.vespa.ai/en/operations/config-sentinel.html) is started: +Check that the [config sentinel](https://docs.vespa.ai/en/operations-selfhosted/config-sentinel.html) is started: 
 $ curl -s http://localhost:19098/state/v1/health
@@ -186,7 +186,7 @@ Checking logs: WARNING : config-sentinel sentinel.sentinel.connectivity Only 4 of 10 nodes are up and OK, 40.0% (min is 50%) **Important note:** -This is the [startup sequence](https://docs.vespa.ai/en/operations/config-sentinel.html#cluster-startup) kicking in - +This is the [startup sequence](https://docs.vespa.ai/en/operations-selfhosted/config-sentinel.html#cluster-startup) kicking in - container and content nodes are not started before 50% (configurable) of nodes have started. Meaning, here we have started only 4/10, so `logserver`, `slobrok`, `metrics-proxy` and `cluster-controller` are not started yet. @@ -446,7 +446,7 @@ Notes: is useful to understand processes running, and also the [startup sequence](https://docs.vespa.ai/en/operations/config-sentinel.html#cluster-startup). Note that in the startup sequence, order not strictly needed as in this sample app. -* [Config servers](https://docs.vespa.ai/en/operations/configuration-server.html) are normally started first, +* [Config servers](https://docs.vespa.ai/en/operations-selfhosted/configuration-server.html) are normally started first, then application deployment - make sure to get this right before troubleshooting other services. * See [slobrok](https://docs.vespa.ai/en/slobrok.html) for the Vespa naming service * The [cluster controller](https://docs.vespa.ai/en/content/content-nodes.html#cluster-controller) cluster @@ -897,7 +897,7 @@ When the config servers are started, but not yet full initialized, the status lo ![Config Servers initializing](img/config-servers-init.png) If the status stays like this, troubleshoot the config server -[startup sequence](https://docs.vespa.ai/en/operations/configuration-server.html#start-sequence). +[startup sequence](https://docs.vespa.ai/en/operations-selfhosted/configuration-server.html#start-sequence). When all nodes are up, it looks like: diff --git a/examples/operations/multinode-HA/gke/README.md b/examples/operations/multinode-HA/gke/README.md index a00cc1f6e..a71e35de6 100644 --- a/examples/operations/multinode-HA/gke/README.md +++ b/examples/operations/multinode-HA/gke/README.md @@ -63,7 +63,7 @@ kubectl apply \ Note that the [StatefulSet](config/configserver.yml) definition for config servers does not have a `readinessProbe`. This is important to start all three config servers for zookeeper quorum and subsequent OK status - -[details](https://docs.vespa.ai/en/operations/configuration-server.html#start-sequence). +[details](https://docs.vespa.ai/en/operations-selfhosted/configuration-server.html#start-sequence). Pay attention to the config server names, referred in [config/configmap.yml](config/configmap.yml) - `VESPA_CONFIGSERVERS` is used on all nodes to get configuration. @@ -101,7 +101,7 @@ Observe status up: ``` If you are not able to see this status page, -do [troubleshooting](https://docs.vespa.ai/en/operations/configuration-server.html#start-sequence). +do [troubleshooting](https://docs.vespa.ai/en/operations-selfhosted/configuration-server.html#start-sequence). Note both "configserver,services" are started in [config/configserver.yml](config/configserver.yml). diff --git a/examples/operations/multinode/README.md b/examples/operations/multinode/README.md index 8c6ecdc16..712f87173 100644 --- a/examples/operations/multinode/README.md +++ b/examples/operations/multinode/README.md @@ -91,7 +91,7 @@ $ docker run --detach --name node2 --hostname node2.vespanet \ Notes: * Use fully qualified hostnames. -* [VESPA_CONFIGSERVERS](https://docs.vespa.ai/en/reference/files-processes-and-ports.html#environment-variables) +* [VESPA_CONFIGSERVERS](https://docs.vespa.ai/en/operations-selfhosted/files-processes-and-ports.html#environment-variables) lists all nodes using exactly the same names as in [hosts.xml](hosts.xml) Wait for last config server to start: