Merge pull request #552 from alphagov/185834263-update-manual

Update manual
alphagov · Feb 22, 2024 · c9238c3 · c9238c3
2 parents 9ceac39 + e8fce9c
commit c9238c3
Show file tree

Hide file tree

Showing 10 changed files with 18 additions and 29 deletions.
diff --git a/source/guides/editing_logstash_filters.html.md b/source/guides/editing_logstash_filters.html.md
@@ -2,10 +2,6 @@
 title: Updating logstash filters
 ---
 
-# Updating logstash filters
-title: Updating logstash filters
----
-
 # Updating logstash filters
 
 Sadly, there is no programmatic access to Logit's logstash filters.

diff --git a/source/guides/fast-startup-and-shutdown.html.md b/source/guides/fast-startup-and-shutdown.html.md
@@ -4,9 +4,9 @@ title: Fast Startup and Shutdown Script and Concourse Pipelines
 
 # Fast Startup and Shutdown Script and Concourse Pipelines
 
-The idea of this set of processes is to save on uneccessary AWS infrastructure expendature in dev environments, and to provide an automated way to impliment a scheduled shutdown of each environment, and to provide a manual mechanism to start dev environments back up, or shut them down before the configured schedule. The [script](https://github.com/alphagov/paas-cf/blob/main/concourse/scripts/fast-startup-and-shutdown-cf-env.sh) that is utimately run, toggles the BOSH ressurector in order to prevent it from interfering with the state changes, and powers up/down the relevant EC2 and RDS instances for the environment. The script does not affect the BOSH or Concourse instances to maintain the ability to quickly startup and shutdown each env. The cost saving is based around the fact that the majority of the cost is incurred by instances being online. Even a powered-down environment does incur some cost due to the block storage being maintained, and the BOSH and Concourse instances that are not affected.
+The idea of this set of processes is to save on unnecessary AWS infrastructure expendature in dev environments, and to provide an automated way to implement a scheduled shutdown of each environment, and to provide a manual mechanism to start dev environments back up, or shut them down before the configured schedule. The [script](https://github.com/alphagov/paas-cf/blob/main/concourse/scripts/fast-startup-and-shutdown-cf-env.sh) that is utimately run, toggles the BOSH resurrector in order to prevent it from interfering with the state changes, and powers up/down the relevant EC2 and RDS instances for the environment. The script does not affect the BOSH or Concourse instances to maintain the ability to quickly startup and shutdown each env. The cost saving is based around the fact that the majority of the cost is incurred by instances being online. Even a powered-down environment does incur some cost due to the block storage being maintained, and the BOSH and Concourse instances that are not affected.
 
-Each dev environment has a fast-startup-cf-env and fast-shutdown-cf-env deployed into it's concourse by default, enabled or disabled by setting the environment variable ENABLE_FAST_STARTUP_AND_SHUTDOWN_CF_ENV to either true or false. These pipelines configure the shutdown process to run each day at 19:00, and allow for both the startup and shutdown processes to be run manually.
+Each dev environment has a fast-startup-cf-env and fast-shutdown-cf-env deployed into concourse by default, enabled or disabled by setting the environment variable ENABLE_FAST_STARTUP_AND_SHUTDOWN_CF_ENV to either true or false. These pipelines configure the shutdown process to run each day at 19:00, and allow for both the startup and shutdown processes to be run manually.
 
 ## fast-startup-and-shutdown-cf-env group
 ![fast-startup-and-shutdown-cf-env group](/screenshots/fast-start-and-shutdown-1.png)

diff --git a/source/guides/managing_azs_on_paas.html.md b/source/guides/managing_azs_on_paas.html.md
@@ -17,14 +17,14 @@ Terraform, or simply running the appropriate Concourse job.
 [The `paas-cf` repository][1] contains a terraform module, which will deny all
 traffic, to subnets in one particular AZ.
 
-It also has a Concourse jobs, in `create-cloudfoundry` pipeline, and the
-`operator` groups, to bot disable and enable particular AZs.
+It also has a Concourse job, in `create-cloudfoundry` pipeline, and the
+`operator` groups, to disable and enable particular AZs.
 
 _Please note_: Disabling the AZ `a`, will likely bring the Concourse down,
 meaning the re-enabling action will need to be done by hand from op's machine.
 
-This will involve, you having to download the Terraform state file, for that
-particular region. See pipeline for more details.
+This will involve you having to download the Terraform state file for that
+particular region. See the pipeline for more details.
 
 ## How to run
 

diff --git a/source/guides/running_paas-cf_tests_locally.html.md b/source/guides/running_paas-cf_tests_locally.html.md
@@ -4,7 +4,10 @@ title: Running tests on `paas-cf` locally
 
 # Running tests on `paas-cf` locally
 
-A number of packages need to be installed in order to run the tests of `paas-cf` locally. To run them, install the packages below then run 
+> **Note**: This requires an intel chip, as the terraform tests download
+providers for x86 chips.
+
+A number of packages need to be installed in order to run the tests of `paas-cf` locally. To run them, install the packages below then run
 
 ```sh
 make test
@@ -37,7 +40,7 @@ make test
   ```
 
 * Shellcheck
-  
+
   ```sh
   curl -L -o /usr/local/bin/shellcheck https://github.com/alphagov/paas-cf/releases/download/shellcheck_binary_0.4.6/shellcheck_darwin_amd64
   chmod +x /usr/local/bin/shellcheck
@@ -70,7 +73,7 @@ make test
   ```
 
 * YAML Lint
-  
+
   ```
   brew install yamllint
   ```

diff --git a/source/guides/upgrade_buildpacks.html.md b/source/guides/upgrade_buildpacks.html.md
@@ -14,7 +14,7 @@ A PR for the upgrade is automatically created on the first of the month at 9:00
 Once the buildpack-upgrading PR has been created in the paas-cf repo, the engineer on support should do the following:
 
 1. Create a Pivotal story to track the progress of this update.
-1. Checkout the PR branch locally and run `scripts/create_buildpack_email.sh`,
+1. Checkout the PR branch locally and run `scripts/create_buildpacks_email.sh`,
    supplying highlights section by section when prompted by the script. Highlights are e.g. breaking changes, version deprecations, new versions etc.
    Please note that the changelog generated by the script is reflecting the most recent buildpack upgrades available, so the script should be run close in
    time to the generation of the PR. If it was delayed, adjusting the email for the changes included in the PR may be necessary.

diff --git a/source/index.html.md b/source/index.html.md
@@ -32,7 +32,6 @@ title: PaaS Team Manual
  - [How to upgrade cf-deployment](guides/upgrade_cf-deployment/)
  - [How to upgrade buildpacks](guides/upgrade_buildpacks/)
  - [How to update Logstash filters in Logit](guides/editing_logstash_filters/)
- - [How to view our data in splunk](support/viewing_our_data_in_splunk/)
  - [How to find route owners](support/finding_route_owners)
  - [How to find apps with noisy logging](support/finding_apps_with_noisy_logging)
  - [How to find activity](support/finding_activity/)
@@ -41,7 +40,6 @@ title: PaaS Team Manual
  - [How to apply tenant ElastiCache (redis) service updates ](support/tenant_elasticache_service_updates/)
  - [How to restore the CF databases](guides/Restoring_the_CF_databases/)
  - [How to restore the bosh director](guides/restoring_bosh_director/)
- - [How to restore the bosh resurrector](guides/restoring_bosh_resurrector/)
  - [How to release bosh blobs](guides/releasing_bosh_blobs/)
  - [How to run `paas-cf` tests locally](guides/running_paas-cf_tests_locally/)
  - [How to rotate credentials](team/rotating_credentials/)

diff --git a/source/support/finding_apps_with_noisy_logging.html.md b/source/support/finding_apps_with_noisy_logging.html.md
@@ -7,6 +7,8 @@ title: Finding apps with noisy logging
 You can use the `cf top` plugin to get a feel for which applications are
 logging more than they should be.
 
+>To install cf plugins on M1 based chips, you need to compile the binary manually and install it
+
 [ECSTeam/cloudfoundry-top-plugin](https://github.com/ECSTeam/cloudfoundry-top-plugin)
 
 Install the plugin with `cf install-plugin -r CF-Community "top"`, then (while

diff --git a/source/support/finding_route_owners.html.md b/source/support/finding_route_owners.html.md
@@ -4,6 +4,8 @@ title: Finding the owner of a route in cf
 
 # Finding the owner of a route in cf
 
+>To install cf plugins on M1 based chips, you need to compile the binary manually and install it
+
 1. Install cf lookup-route plugin  with `cf install-plugin -r CF-Community "route-lookup"`
 1. Log into the cf instance where you suspect the route is
 1. Run `cf lookup-route DOMAINNAME` where DOMAINNAME is the one you are looking for

diff --git a/source/support/restoring_opensearch_backups.html.md b/source/support/restoring_opensearch_backups.html.md
@@ -6,7 +6,7 @@ title: Restoring Opensearch backups
 
 There is no direct way for us to restore Opensearch backups either via the API or console.
 
-In order to have a bakup restored you will need to open a support ticket with Aiven via [[email protected]](mailto:[email protected]) requesting a restoration of a backup they will need to know the instance ID `prod-$(cf service <servicename> --guid)` and the time of the backup you would like restored.
+In order to have a backup restored you will need to open a support ticket with Aiven via [[email protected]](mailto:[email protected]) requesting a restoration of a backup they will need to know the instance ID `prod-$(cf service <servicename> --guid)` and the time of the backup you would like restored.
 
 The Web interface only shows the latest backup, they are taken on a 2 hourly basis and retained as follows;
 

diff --git a/source/support/viewing_our_data_in_splunk.html.md b/source/support/viewing_our_data_in_splunk.html.md