Skip to content

Commit 598ff5e

Browse files
authored
Merge pull request #205 from arangodb/documentation/fixes
Documentation fixes
2 parents ddec04c + 4d7e392 commit 598ff5e

File tree

5 files changed

+8
-8
lines changed

5 files changed

+8
-8
lines changed

docs/Manual/Deployment/Kubernetes/Authentication.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@ as well as access from the ArangoDB Operator to the deployment.
1010
To disable authentication, set `spec.auth.jwtSecretName` to `None`.
1111

1212
Initially the deployment is accessible through the web user-interface and
13-
API's, using the user `root` with an empty password.
13+
APIs, using the user `root` with an empty password.
1414
Make sure to change this password immediately after starting the deployment!
1515

1616
## See also

docs/Manual/Deployment/Kubernetes/DeploymentReplicationResource.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -51,7 +51,7 @@ spec:
5151
This definition results in:
5252

5353
- the arangosync `SyncMaster` in deployment `cluster-b` is called to configure a synchronization
54-
from the syncmasters located at the given list of endpoint URL's to the syncmasters `cluster-b`,
54+
from the syncmasters located at the given list of endpoint URLs to the syncmasters `cluster-b`,
5555
using the client authentication certificate stored in `Secret` `cluster-a-sync-auth`.
5656
To access `cluster-a`, the keyfile (containing a client authentication certificate) is used.
5757
To access `cluster-b`, the JWT secret found in the deployment of `cluster-b` is used.
@@ -69,7 +69,7 @@ This cluster configured as the replication source.
6969

7070
### `spec.source.masterEndpoint: []string`
7171

72-
This setting specifies zero or more master endpoint URL's of the source cluster.
72+
This setting specifies zero or more master endpoint URLs of the source cluster.
7373

7474
Use this setting if the source cluster is not running inside a Kubernetes cluster
7575
that is reachable from the Kubernetes cluster the `ArangoDeploymentReplication` resource is deployed in.
@@ -110,7 +110,7 @@ This cluster configured as the replication destination.
110110

111111
### `spec.destination.masterEndpoint: []string`
112112

113-
This setting specifies zero or more master endpoint URL's of the destination cluster.
113+
This setting specifies zero or more master endpoint URLs of the destination cluster.
114114

115115
Use this setting if the destination cluster is not running inside a Kubernetes cluster
116116
that is reachable from the Kubernetes cluster the `ArangoDeploymentReplication` resource is deployed in.

docs/Manual/Deployment/Kubernetes/DeploymentResource.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -126,7 +126,7 @@ cluster is down, or in a bad state, irrespective of the value of this setting.
126126

127127
### `spec.rocksdb.encryption.keySecretName`
128128

129-
This setting specifies the name of a kubernetes `Secret` that contains
129+
This setting specifies the name of a Kubernetes `Secret` that contains
130130
an encryption key used for encrypting all data stored by ArangoDB servers.
131131
When an encryption key is used, encryption of the data in the cluster is enabled,
132132
without it encryption is disabled.

docs/Manual/Deployment/Kubernetes/DriverConfiguration.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -124,5 +124,5 @@ The easiest way to work around it, is by making sure that the query results are
124124
enough.
125125
When that is not feasible, it is also possible to resolve this
126126
when the internal DNS names of your Kubernetes cluster are exposed to your client application
127-
and the resuling IP addresses are routeable from your client application.
127+
and the resulting IP addresses are routable from your client application.
128128
To expose internal DNS names of your Kubernetes cluster, your can use [CoreDNS](https://coredns.io).

docs/Manual/Deployment/Kubernetes/Troubleshooting.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -68,7 +68,7 @@ those replicas.
6868
There are two common causes for this.
6969

7070
1) The `Pods` cannot be scheduled because there are not enough nodes available.
71-
This is usally only the case with a `spec.environment` setting that has a value of `Production`.
71+
This is usually only the case with a `spec.environment` setting that has a value of `Production`.
7272

7373
Solution:
7474
Add more nodes.
@@ -106,7 +106,7 @@ those `PersistentVolumes`, it depends on the type of server that was using the v
106106
- If a `DBServer` was using the volume, and the replication factor of all database
107107
collections is 2 or higher, and the remaining dbservers are still healthy,
108108
the cluster will duplicate the remaining replicas to
109-
bring the number of replicases back to the original number.
109+
bring the number of replicas back to the original number.
110110
- If a `DBServer` was using the volume, and the replication factor of a database
111111
collection is 1 and happens to be stored on that dbserver, the data is lost.
112112
- If a single server of an `ActiveFailover` deployment was using the volume, and the

0 commit comments

Comments
 (0)