spell check

Author: gxben

content/en/docs/admin-guide/create-kaktus.md

@@ -31,7 +31,7 @@ If you only have limited disks on your system (e.g. only 2), Ceph storage will b
 - possibly do the same on another disk so you can use software RAID-1 for sanity.
 - partition the rest of your disk for future Ceph usage.
 
-In that case, **parted** is your friend for the job. It also means you need to ensure, at OS installation stage, that you don't let distro partitionner use your full device.
+In that case, **parted** is your friend for the job. It also means you need to ensure, at OS installation stage, that you don't let distro partitioner use your full device.
 
 {{< alert color="success" title="Recommendation" >}}
 As much as can be, we however recommend you to have dedicated disks for Ceph cluster. An enterprise-grade setup would use some small SATA SSDs in RAID-1 for OS and as many dedicated NVMe SSDs as Ceph-reserved data disks.
@@ -131,7 +131,7 @@ kowabunga_netplan_apply_enabled: true
 ```
 
 {{< alert color="success" title="Information" >}}
-Note that setting **kowabunga_netplan_disable_cloud_init** is an optional step. If you'd like to keep whatever configuration cloud-init has previously set, it's all fine (but it's always recommended not to have dual sourc eof truth).
+Note that setting **kowabunga_netplan_disable_cloud_init** is an optional step. If you'd like to keep whatever configuration cloud-init has previously set, it's all fine (but it's always recommended not to have dual source of truth).
 {{< /alert >}}
 
 {{< alert color="success" title="Information" >}}
@@ -168,7 +168,7 @@ Having more than 3 monitors in your cluster is not necessarily useful. If you ha
 Also be sure that those nodes (and those nodes only !) are defined in **Kiwi**'s DNS regional configuration under **ceph** record.
 {{< /alert >}}
 
-Ceph cluster also comes with **managers**. As in real-life, they don't do much ;-) Or at least, they're not as vital as **monitors**. They however expose various metrics. Having one is nice, more than that will only help with failover. As for **monitors**, one can enale it for a **Kaktus** in **ansible/inventories/host_vars/kaktus-eu-west-a-{1,2,3}.yml** instance-specific file:
+Ceph cluster also comes with **managers**. As in real-life, they don't do much ;-) Or at least, they're not as vital as **monitors**. They however expose various metrics. Having one is nice, more than that will only help with failover. As for **monitors**, one can enable it for a **Kaktus** in **ansible/inventories/host_vars/kaktus-eu-west-a-{1,2,3}.yml** instance-specific file:
 
 ```yaml
 kowabunga_ceph_manager_enabled: true
@@ -192,14 +192,14 @@ So let's define where to store these files in **ansible/inventories/group_vars/k
 kowabunga_ceph_local_keyrings_dir: "{{ playbook_dir }}/../../../../../files/ceph"
 ```
 
-Once provisionned, you'll end up with a regional sub-directory (e.g. **eu-west**), containing 3 files:
+Once provisioned, you'll end up with a regional sub-directory (e.g. **eu-west**), containing 3 files:
 
 - ceph.client.admin.keyring
 - ceph.keyring
 - ceph.mon.keyring
 
 {{< alert color="warning" title="Important" >}}
-These files are keyring and extermely sensitive. Anyone with access to these files and your private network gets a full administrative control over the Ceph cluster.
+These files are keyring and extremely sensitive. Anyone with access to these files and your private network gets a full administrative control over the Ceph cluster.
 
 So keep track of them, but do it smartly. As they are plain-text, let's ensure you don't store them on Git that way.
 
@@ -213,9 +213,9 @@ $ mv ceph.client.admin.keyring ceph.client.admin.keyring.sops
 before being pushed. Ansible will automatically decrypt them on the fly, should they end up with *.sops* extension.
 {{< /alert >}}
 
-### Disks provisionning
+### Disks provisioning
 
-Next step is about disks provisionning. Your cluster will contain several disks from several instances (the ones you've either partitionned or left untouched at pre-requisite stage). Each instance may have different toplogy, different disks, different sizes etc ... Disks (or partitions, whatever) are each managed by a Ceph **OSD** daemon.
+Next step is about disks provisioning. Your cluster will contain several disks from several instances (the ones you've either partitioned or left untouched at pre-requisite stage). Each instance may have different topology, different disks, different sizes etc ... Disks (or partitions, whatever) are each managed by a Ceph **OSD** daemon.
 
 So we need to reflect this topology into each instance-specific **ansible/inventories/host_vars/kaktus-eu-west-a-{1,2,3}.yml** file:
 
@@ -229,11 +229,11 @@ kowabunga_ceph_osds:
     weight: 1.0
 ```
 
-For each instance, you'll need to declare disks that are going to be part of the cluster. The **dev** parameter simply maps to the device file itself (it is **more than recommended** to use **/dev/disk/by-id** mapping instead of boggus **/dev/nvme0nX** naming, which can change across reboots). The **weight** parameter will be used for Ceph scheduler for object placement and corresponds to each disk size in TB unit (e.g. 1.92 TB SSD would have a 1.92 weight). And finally the **id** identifier might be the most important of all. This is the **UNIQUE** identifier across your Ceph cluster. Whichever the disk ID you use, you need to ensure than no other disk in no other instance uses the same identifier.
+For each instance, you'll need to declare disks that are going to be part of the cluster. The **dev** parameter simply maps to the device file itself (it is **more than recommended** to use **/dev/disk/by-id** mapping instead of bogus **/dev/nvme0nX** naming, which can change across reboots). The **weight** parameter will be used for Ceph scheduler for object placement and corresponds to each disk size in TB unit (e.g. 1.92 TB SSD would have a 1.92 weight). And finally the **id** identifier might be the most important of all. This is the **UNIQUE** identifier across your Ceph cluster. Whichever the disk ID you use, you need to ensure than no other disk in no other instance uses the same identifier.
 
 ### Data Pools
 
-Once we have disks agregated, we must create data pools on top. Data pools are a logical way to segment your global Ceph cluster usgage. Definition can be made in **ansible/inventories/group_vars/kaktus_eu_west/main.yml** file, as:
+Once we have disks aggregated, we must create data pools on top. Data pools are a logical way to segment your global Ceph cluster usage. Definition can be made in **ansible/inventories/group_vars/kaktus_eu_west/main.yml** file, as:
 
 ```yaml
 kowabunga_ceph_osd_pools:
@@ -268,9 +268,9 @@ In that example, we'll create 4 data pools:
 - 2 of type **rbd** (RADOS block device), for further be used by KVM or a future Kubernetes cluster to provision virtual block device disks.
 - 2 of type **fs** (filesystem), for further be used as underlying NFS storage backend.
 
-Each pool relies on [Ceph Placement Groups](https://docs.ceph.com/en/latest/rados/operations/placement-groups/) for objects fragments distribution across disks in the cluster. There's no rule of thumb on how much one need. Itdepends on your cluster size, its number of disks, its replication factor and many more parameters. You can get some help thanks to [Ceph PG Calculator](https://linuxkidd.com/ceph/pgcalc.html) to set an appropriate value.
+Each pool relies on [Ceph Placement Groups](https://docs.ceph.com/en/latest/rados/operations/placement-groups/) for objects fragments distribution across disks in the cluster. There's no rule of thumb on how much one need. It depends on your cluster size, its number of disks, its replication factor and many more parameters. You can get some help thanks to [Ceph PG Calculator](https://linuxkidd.com/ceph/pgcalc.html) to set an appropriate value.
 
-The **replication** parameter controls the cluster's data redundancy. The bigger the value, the more replicated data will be (and the less prone to disaster you will be), but the fewer usuable space you'll get.
+The **replication** parameter controls the cluster's data redundancy. The bigger the value, the more replicated data will be (and the less prone to disaster you will be), but the fewer usable space you'll get.
 
 ### File Systems
 
@@ -335,4 +335,4 @@ $ kobra ansible deploy -p kowabunga.cloud.kaktus
 
 We’re all set with infrastructure setup.
 
-One last step of [services provisionning](/docs/admin-guide/provision-services/) and we're done !
+One last step of [services provisioning](/docs/admin-guide/provision-services/) and we're done !

content/en/docs/admin-guide/create-kiwi.md

@@ -108,7 +108,7 @@ kowabunga_network_failover_settings:
         {{- res -}}
 ```
 
-Once again, we interate over **kowabunga_region_vlan_id_ranges** variable to create our global configuration for **eu-west** region. After all, both **Kiwi** instances from there will have the very same configuration.
+Once again, we iterate over **kowabunga_region_vlan_id_ranges** variable to create our global configuration for **eu-west** region. After all, both **Kiwi** instances from there will have the very same configuration.
 
 This will ensure that VRRP packets flows between the 2 peers so one always ends up being the active router for each virtual network interface.
 
@@ -183,8 +183,8 @@ Finally, edit the SOPS-encrypted **ansible/inventories/group_vars/kiwi.sops.yml*
 ```yaml
 secret_kowabunga_powerdns_webserver_password: ONE_STRONG_PASSWORD
 secret_kowabunga_powerdns_api_key: ONE_MORE
-secret_kowabunaga_powerdns_db_admin_password: YET_ANOTHER
-secret_kowabunaga_powerdns_db_user_password: HERE_WE_GO
+secret_kowabunga_powerdns_db_admin_password: YET_ANOTHER
+secret_kowabunga_powerdns_db_user_password: HERE_WE_GO
 ```
 
 As names stand, first 2 variables will be used to expose **PowerDNS** API (which will be consumed by **Kiwi** agent) and last twos are MariaDB credentials, used by **PowerDNS** to connect to. None of these passwords really matter, they're server-to-server internal use only, no use is ever going to make use of them. But let's use something robust nonetheless.
@@ -210,4 +210,4 @@ We're finally done with **Kiwi**'s configuration. All we need to do now is final
 $ kobra ansible deploy -p kowabunga.cloud.kiwi
 ```
 
-We’re now ready for [provisionning Kaktus HCI nodes](/docs/admin-guide/create-kaktus/) !
+We’re now ready for [provisioning Kaktus HCI nodes](/docs/admin-guide/create-kaktus/) !

content/en/docs/admin-guide/create-region.md

@@ -4,7 +4,7 @@ description: Let's setup a new region and its Kiwi and Kaktus instances
 weight: 4
 ---
 
-Orchestrator being ready, we can now boostrap our first region.
+Orchestrator being ready, we can now bootstrap our first region.
 
 Let's take the following assumptions for the rest of this tutorial:
 
@@ -111,8 +111,8 @@ Despite that, each instance will have its own agent, to establish a WebSocket co
 Let's continue with the 3 **Kaktus** instances declaration and their associated agents. Note that, this time, instances are associated to the zone itself, not the region.
 
 {{< alert color="success" title="Information" >}}
-Note that **Kaktus** instance creaion/update takes 4 specific parameters into account:
-- **cpu_price** and **memory_price** are purely arbitrary values that express how much actual money is worth your metal infrastructure. These are used to compute virtual cost calculation later, when you'll be spwaning **Kompute** instances with vCPUs and vGB of RAM. Each server being different, it's fully okay to have different values here for your fleet.
+Note that **Kaktus** instance creation/update takes 4 specific parameters into account:
+- **cpu_price** and **memory_price** are purely arbitrary values that express how much actual money is worth your metal infrastructure. These are used to compute virtual cost calculation later, when you'll be spawning **Kompute** instances with vCPUs and vGB of RAM. Each server being different, it's fully okay to have different values here for your fleet.
 - **cpu_overcommit** and **memory_overcommit** define the [overcommit](https://en.wikipedia.org/wiki/Memory_overcommitment) ratio you accept your physical hosts to address. As for price, not every server is born equal. Some have hyper-threading, other don't. You may consider that a value of 3 or 4 is fine, other tend to be stricter and use 2 instead. The more you set the bar, the more virtual resources you'll be able to create but the less actual physical resources they'll be able to get.
 {{< /alert >}}
 
@@ -219,7 +219,7 @@ By default, if you only intend to use plain old **Kompute** instances, virtual d
 
 If you however expect to further use **KFS** or running your own Kubernetes flavor, with an attempt to directly use Ceph backend to instantiate PVCs, exposing the VLAN 102 is mandatory.
 
-To be on the safe side, and furure-proof, keep it exposed.
+To be on the safe side, and future-proof, keep it exposed.
 {{< /alert >}}
 
 
@@ -281,7 +281,7 @@ $ kobra tf apply
 What have we done here ? Simply iterating over VNETs to associate those with VLAN IDs and the name of Linux bridge interfaces which will be created on each **Kaktus** instance from the zone (see [further](/docs/admin-guide/create-kaktus/)).
 
 {{< alert color="success" title="Note" >}}
-Note that while services instances will have dedicated reserved networks, we'll (conventionnally) add the VLAN 0 here (which is not really a VLAN at all).
+Note that while services instances will have dedicated reserved networks, we'll (conventionally) add the VLAN 0 here (which is not really a VLAN at all).
 
 **Kaktus** instances will be created with a **br0** bridge interface, mapped on host private network controller interface(s), where public IP addresses will be bound. This will allow further create virtual machines to be able to bind public IPs through the bridged interface.
 {{< /alert >}}
@@ -307,7 +307,7 @@ resource "kowabunga_subnet" "eu-west" {
 }
 ```
 
-Subnet objects are associated with a given virtual network and usual network settings (such as CIDR, route/rgateway, DNS server) are associated.
+Subnet objects are associated with a given virtual network and usual network settings (such as CIDR, route/gateway, DNS server) are associated.
 
 Note the use of 2 interesting parameters:
 
@@ -380,8 +380,8 @@ Note that we arbitrary took multiple decisions here:
 - Reserve the first 69 IP addresses of the **10.50.102.0/24** subnet for our region growth. Each project's **Kawaii** instance (one per zone) will bind an IP from the range. That's plain enough room for the 10 projects we intend to host. But this saves us some space, shall we need to extend our infrastructure, by adding new **Kaktus** instances.
 - Use of /24 subnets. This is really up to each network administrator. You could pick whichever range you need which wouldn't collapse with what's currently in place.
 - Limit virtual network to one single subnet. We could have added as much as needed.
-- Reserve the first 5 IPs of each subnet. Remember, our 2 **Kiwi** instances are already configured to bind **.2** and **.3** (and **.1** is the VIP). We'll save a few exra room for future use (one never knows ...).
-- Reserve the subnet's last 3 IP addresses for **Kawaii** gateways virtual IPs. We only have one zone for now, so 1 would have been anough, but again, we never know what the future holds ...
+- Reserve the first 5 IPs of each subnet. Remember, our 2 **Kiwi** instances are already configured to bind **.2** and **.3** (and **.1** is the VIP). We'll save a few extra room for future use (one never knows ...).
+- Reserve the subnet's last 3 IP addresses for **Kawaii** gateways virtual IPs. We only have one zone for now, so 1 would have been enough, but again, we never know what the future holds ...
 {{< /alert >}}
 
 {{< alert color="warning" title="Warning" >}}

content/en/docs/admin-guide/kahuna-setup.md

@@ -102,7 +102,7 @@ collections:
     version: 0.1.0
 ```
 
-By default, your platform is configured to pull a tagged official release from Ansible Galaxy. You may however prefer to pull it directly from Git, using latest commit for instance. This can be accomodated through:
+By default, your platform is configured to pull a tagged official release from Ansible Galaxy. You may however prefer to pull it directly from Git, using latest commit for instance. This can be accommodated through:
 
 ```yaml
 ---
@@ -161,7 +161,7 @@ $ kobra secrets edit ansible/inventories/group_vars/all.sops.yml
 and set the requested password:
 
 ```yaml
-secret_kowabunga_os_user_root_password: MY_SUPER_SETRONG_PASSWORD
+secret_kowabunga_os_user_root_password: MY_SUPER_STRONG_PASSWORD
 ```
 
 ### Firewall
@@ -248,7 +248,7 @@ kowabunga_kahuna_smtp_password: "{{ secret_kowabunga_kahuna_smtp_password }}"
 and add the respective secrets into **ansible/inventories/group_vars/kahuna.sops.yml**:
 
 ```yaml
-secret_kowabunga_kahuna_jwt_signature: A_STRONG_JWT_SGINATURE
+secret_kowabunga_kahuna_jwt_signature: A_STRONG_JWT_SIGNATURE
 secret_kowabunga_kahuna_api_key: A_STRONG_API_KEY
 secret_kowabunga_kahuna_smtp_password: A_STRONG_PASSWORD
 ```
@@ -269,4 +269,4 @@ After a few minutes, if everything's went okay, you should have a working **Kahu
 - The [Kahuna](/docs/concepts/kahuna/) backend server itself, our core orchestrator.
 - Optionally, [MongoDB](https://www.mongodb.com/) database.
 
-We're now ready for [provisionning users and teams](/docs/admin-guide/provision-users/) !
+We're now ready for [provisioning users and teams](/docs/admin-guide/provision-users/) !

content/en/docs/admin-guide/provision-users.md

@@ -4,7 +4,7 @@ description: Let's populate admin users and teams
 weight: 3
 ---
 
-Your **Kahuna** instance is now up and running, let's get things and create a few admin users accounts. At first, we only have the super-admin API key that was previously set through Ansible deployment. We'll make use of it to provision further users and associated teams. After all, we want a nominative user acount for each contributor, right ?
+Your **Kahuna** instance is now up and running, let's get things and create a few admin users accounts. At first, we only have the super-admin API key that was previously set through Ansible deployment. We'll make use of it to provision further users and associated teams. After all, we want a nominative user account for each contributor, right ?
 
 Back to TF config, let's edit the **terraform/providers.tf** file: