add procedures (timescale#574)

Co-authored-by: Lana Brindley <github@lanabrindley.com>

Author: jacobprall

CONTRIBUTING.md

@@ -7,8 +7,9 @@ review with GitHub.
 You can make contributions to the documentation by creating a fork of the
 repository.
 
+<procedure>
 
-### Procedure: Contributing using a fork
+### Contributing using a fork
 1.  Make sure you have a [github](github.com) account, and that you're signed in.
 1.  Navigate to the [Timescale Documentation
 Repo](https://github.com/timescale/docs) click the `Fork` button in the
@@ -59,7 +60,11 @@ top-right corner, and select the account you want to use.
     git checkout -b update-readme-username
     ```
 
-### Procedure: Committing changes and creating a pull request
+</procedure>
+
+<procedure>
+
+### Committing changes and creating a pull request
 1.  Make your changes.
 1.  Add the updated files to your commit:
     ```bash
@@ -86,17 +91,21 @@ top-right corner, and select the account you want to use.
     about what you are working on, and making sure we all understand current
     progress.
 
-:warning: Choose your reviewers carefully! If you have made changes to the technical
+</procedure>
+
+<highlight type="warning">Choose your reviewers carefully! If you have made changes to the technical
 detail of the documentation, choose an appropriate subject matter expert (SME)
 to review those changes. Additionally, every change requires at least one
-documentation team member to approve.
+documentation team member to approve.</highlight>
 
 ## Second contribution
 Once you have checked out the repo and want to keep working on things, you need
 to ensure that your local copy of the repo stays up to date. If you don't do
 this, you *will* end up with merge conflicts.
 
-### Procedure: Second contribution
+<procedure>
+
+### Second contribution
 1.  Check out your fork's `latest` branch:
     ```bash
     git checkout latest
@@ -122,10 +131,13 @@ this, you *will* end up with merge conflicts.
     conflicts. You should do it at least every day before you begin work, and again
     whenever you switch branches.
 
-:warning: Never leave branches lying around on your local system. Create your PR as soon
+
+</procedure>
+
+<highlight type="warning">Never leave branches lying around on your local system. Create your PR as soon
 as possible, and make good use of the Draft feature. Commit to your feature
 branch early and often! Update your local copy from latest whenever you switch
-branches.
+branches.</highlight>
 
 ## Writing standards
 Timescale is in the process of creating comprehensive writing and style standards. For the current guidelines, see [contributing to documentation][docs-standards].

promscale/install-promscale.md

@@ -19,7 +19,9 @@ You can install the Promscale Connector with a Docker image from
 [Docker Hub][promscale-docker-hub]. To see the latest available images, see
 the [Promscale Releases on GitHub][promscale-releases-github].
 
-### Procedure: Installing Promscale from a Docker image
+<procedure>
+
+### Installing Promscale from a Docker image
 1.  Create a network specific to Promscale-TimescaleDB:
     ```bash
     docker network create --driver bridge promscale-timescaledb
@@ -42,6 +44,7 @@ the [Promscale Releases on GitHub][promscale-releases-github].
     In this example, we use `db-ssl-mode=allow`, which is suitable for testing
     purposes. For production environments, use `db-ssl-mode=require` instead.
 
+</procedure>
 
 ## Configure Prometheus for Promscale
 You need to tell Prometheus to use the remote storage connector. By setting

timescaledb/how-to-guides/backup-and-restore/docker-and-wale.md

@@ -20,7 +20,9 @@ you can share them with the WAL-E sidecar. Both must reside in a Docker volume,
 by default a volume is created for `/var/lib/postgresql/data`. When you have
 started TimescaleDB, you can log in and create tables and data.
 
-### Procedure: Running the TimescaleDB container in Docker
+<procedure>
+
+### Running the TimescaleDB container in Docker
 1.  Create the docker container:
     ```bash
     docker network create timescaledb-net
@@ -46,6 +48,8 @@ started TimescaleDB, you can log in and create tables and data.
     docker exec -it timescaledb psql -U postgres
     ```
 
+</procedure>
+
 ## Perform the backup using the WAL-E sidecar
 The [WAL-E Docker image][wale image] runs a web endpoint that accepts WAL-E
 commands across an HTTP API. This allows PostgreSQL to communicate with the
@@ -62,7 +66,9 @@ information to WAL-E when you start it. In this example, the WAL-E image listens
 for commands on the `timescaledb-net` internal network at port 80, and writes
 backups to `~/backups` on the Docker host.
 
-### Procedure: Performing the backup using the WAL-E sidecar
+<procedure>
+
+### Performing the backup using the WAL-E sidecar
 1.  Start the WAL-E container with the required information about the container.
     In this example, the container is called `timescaledb-wale`:
     ```bash
@@ -91,6 +97,8 @@ backups to `~/backups` on the Docker host.
     curl http://localhost:8080/backup-push
     ```
 
+</procedure>
+
 You should do base backups at regular intervals, we recommend daily, to minimize
 the amount of WAL-E replay, and to make recoveries faster. To make new base
 backups, re-trigger a base backup as shown here, either manually or on a
@@ -102,7 +110,9 @@ HTTP API.
 To recover the database instance from the backup archive, create a new
 TimescaleDB container, and restore the database and configuration files from the base backup. Then you can relaunch the sidecar and the database.
 
-### Procedure: Restoring database files from backup
+<procedure>
+
+### Restoring database files from backup
 1.  Create the docker container:
     ```bash
     docker create \
@@ -151,14 +161,17 @@ TimescaleDB container, and restore the database and configuration files from the
     sh -c 'echo "restore_command='\''/usr/bin/wget wale/wal-fetch/%f -O -'\''" > /var/lib/postgresql/data/pg_data/recovery.conf'
     ```
 
+</procedure>
+
 When you have recovered the data and the configuration files, and have created a
 recovery configuration file, you can relaunch the sidecar. You might need to
 remove the old one first. When you relaunch the sidecar, it replays the last WAL
 segments that might be missing from the base backup. The you can relaunch the
 database, and check that recovery was successful.
 
+<procedure>
 
-### Procedure: Relaunch the recovered database
+### Relaunch the recovered database
 1.  Relaunch the WAL-E sidecar:
     ```bash
     docker run \
@@ -188,6 +201,7 @@ database, and check that recovery was successful.
     no more files can be found in the archive. See the PostgreSQL documentation
     on [continuous archiving][pg archiving] for more information.
 
+</procedure>
 
 [pg archiving]: https://www.postgresql.org/docs/current/continuous-archiving.html#BACKUP-PITR-RECOVERY
 [wale official]: https://github.com/wal-e/wal-e

timescaledb/how-to-guides/backup-and-restore/pg-dump-and-restore.md

@@ -30,7 +30,9 @@ hypertable from backup.
 When you need to restore data from a backup, you can use `psql` to create a new
 database and restore the data.
 
-### Procedure: Restoring an entire database from backup
+<procedure>
+
+### Restoring an entire database from backup
 1.  In `pgsql`, create a new database to restore to, and connect to it:
     ```sql
     CREATE DATABASE exampledb;
@@ -44,6 +46,8 @@ database and restore the data.
     SELECT timescaledb_post_restore();
     ```
 
+</procedure>
+
 ## Back up individual hypertables [](backup-hypertable)
 The `pg_dump` command provides flags that allow you to specify tables or schemas
 to back up. However, using these flags means that the dump lacks necessary
@@ -62,7 +66,9 @@ You can backup individual hypertables by backing up the entire database, and
 then excluding the tables you do not want to backup. You can also use this
 method to backup individual plain tables that are not hypertables.
 
-### Procedure: Backing up individual hypertables
+<procedure>
+
+### Backing up individual hypertables
 1.  At the command prompt, back up the hypertable schema:
     ```bash
     pg_dump -s -d old_db --table conditions -N _timescaledb_internal | \
@@ -74,7 +80,11 @@ method to backup individual plain tables that are not hypertables.
     -c "\COPY (SELECT * FROM conditions) TO data.csv DELIMITER ',' CSV"
     ```
 
-### Procedure: Restoring individual hypertables from backup
+</procedure>
+
+<procedure>
+
+### Restoring individual hypertables from backup
 1.  At the command prompt, restore the schema:
     ```bash
     psql -d new_db < schema.sql
@@ -97,6 +107,8 @@ can provide a good opportunity for you to re-organize your hypertables if
 you need to. For example, you can change the partitioning key, the number of
 partitions, or the chunk interval sizes.
 
+</procedure>
+
 ### Troubleshoot version mismatches [](tshoot-version-mismatch)
 The PostgreSQL `pg_dump` command does not allow you to specify which version of
 the extension to use when backing up. This can create problems if you have a

timescaledb/how-to-guides/backup-and-restore/timescaledb-backup.md

@@ -19,7 +19,9 @@ If you have installed the `timescaledb-tools` package, you already have the
 get`, or download a binary from
 [our release page][gh-releases].
 
-### Procedure: Installing timescaledb-backup
+<procedure>
+
+### Installing timescaledb-backup
 1.  Ensure you have installed these packages on the machine that you want to
     backup:
     *   `pg_dump`
@@ -30,6 +32,8 @@ get`, or download a binary from
     $ go get github.com/timescale/timescaledb-backup/
     ```
 
+</procedure>
+
 ## Back up your database
 You can perform a backup using the `ts-dump` command at the command prompt. For
 example, to backup a database named `exampledb`:
@@ -77,7 +81,9 @@ parameters when you use the `ts-dump` command:
 You can restore your database from backup using the `ts-restore` command at the
 command prompt:
 
-### Procedure: Restoring your database from backup
+<procedure>
+
+### Restoring your database from backup
 1.  Create a new, empty, database in the location you want to restore to. In
     this example, the new database is called `newdb`.
 1.  Restore the database named `exampledb` to the new location, from the
@@ -86,6 +92,8 @@ command prompt:
     ts-restore --db-URI=postgresql://user@example.com/newdb --dump-dir=˜/backups/exampledb/
     ```
 
+</procedure>
+
 The two main parameters you need to specify are:
 *   `--db-URI`: the location of the new database that you want to restore to. It
     should already exist, but does not need to be set up. It should be in

timescaledb/how-to-guides/compression/about-compression.md

@@ -41,7 +41,9 @@ compressed.
 |8/22/2019 0:00|1|88.2|20|0.8|
 |8/22/2019 0:05|2|300.5|30|0.9|
 
-### Procedure: Enabling compression
+<procedure>
+
+### Enabling compression
 1.  At the `pgsl` prompt, alter the table:
     ```sql
     ALTER TABLE example SET (
@@ -54,6 +56,8 @@ compressed.
     SELECT add_compression_policy('example', INTERVAL '7 days');
     ```
 
+</procedure>
+
 ## Compression policy intervals
 Data is usually compressed after an interval of time has elapsed, and not
 immediately. In the "Enabling compression" procedure, we used a seven day

timescaledb/how-to-guides/compression/decompress-chunks.md

@@ -66,7 +66,9 @@ If you need to insert a batch of backfilled data, the [TimescaleDB
 extras][timescaledb-extras] GitHub repository includes functions for
 [backfilling batch data to compressed chunks][timescaledb-extras-backfill].  In this procedure, we describe how to use the `decompress_backfill` function.
 
-### Procedure: Backfilling with a supplied function
+<procedure>
+
+###  Backfilling with a supplied function
 1.  At the psql prompt, create a temporary table with the same schema as the hypertable you want to backfill into. In this example, our table is called `example`, and the data column is `cpu_temp`:
     ```sql
     CREATE TEMPORARY TABLE cpu_temp AS SELECT * FROM example WITH NO DATA;
@@ -80,12 +82,16 @@ extras][timescaledb-extras] GitHub repository includes functions for
     CALL decompress_backfill(staging_table=>'cpu_temp', destination_hypertable=>'example');
     ```
 
+</procedure>
+
 ## Backfill manually
 If you don't want to use a supplied function, you can perform the steps
 manually. In this procedure, we describe how to identify and turn off your
 compression policy, before manually decompressing chunks.
 
-### Procedure: Backfilling manually
+<procedure>
+
+### Backfilling manually
 1.  At the psql prompt, find the `job_id` of the policy:
     ```sql
     SELECT s.job_id
@@ -119,6 +125,7 @@ compression policy, before manually decompressing chunks.
     CALL run_job(<job_id>);
     ```
 
+</procedure>
 
 [timescaledb-extras]: https://github.com/timescale/timescaledb-extras
 [timescaledb-extras-backfill]: https://github.com/timescale/timescaledb-extras/blob/master/backfill.sql

timescaledb/how-to-guides/compression/manually-compress-chunks.md

@@ -12,7 +12,9 @@ Before you start, you need a list of chunks to compress. In this example, we are
 using a hypertable called `example`, and compressing these chunks that are older
 than three days.
 
-### Procedure: Selecting chunks to compress
+<procedure>
+
+### Selecting chunks to compress
 1.  At the psql prompt, select all chunks in the table `example` that are older
     than three days:
     ```sql
@@ -25,9 +27,13 @@ than three days.
     |1|_timescaledb_internal_hyper_1_2_chunk|
     |2|_timescaledb_internal_hyper_1_3_chunk|
 
+</procedure>
+
 When you are happy with the list of chunks, you can use the chunk names to manually compress each one.
 
-### Procedure: Compressing chunks manually
+<procedure>
+
+### Compressing chunks manually
 1.  At the psql prompt, compress the chunk:
     ```sql
     SELECT compress_chunk( '<chunk_name>');
@@ -46,6 +52,8 @@ When you are happy with the list of chunks, you can use the chunk names to manua
 
 1.  Repeat for all chunks you want to compress.
 
+</procedure>
+
 ## Manually compress chunks in a single command
 Alternatively, you can select the chunks and compress them in a single command
 by using the output of the `show_chunks` command to compress each one, like