docs: make docs work better with docusaurus

Signed-off-by: Joao Eduardo Luis <[email protected]>

docs/decisions/0007-release-process.md

@@ -6,9 +6,9 @@ This document is superseded by three different ADRs, covering the same topics
 and expanding them: [Release Methodology][adr_methodology],
 [Release Steps][adr_steps], and [Release Testing][adr_testing].
 
-[adr_methodology]: /docs/decisions/0015-release-methodology.md
-[adr_steps]: /docs/decisions/0016-release-steps.md
-[adr_testing]: /docs/decisions/0017-release-testing.md
+[adr_methodology]: ./0015-release-methodology.md
+[adr_steps]: ./0016-release-steps.md
+[adr_testing]: ./0017-release-testing.md
 
 ## Context and Problem Statement
 
@@ -19,7 +19,7 @@ eventually released, the Release Process is not trivial.
 This document defines and agrees on the Release Process for the `s3gw` project,
 including the steps to be taken on its individual sub-projects, and results
 from several iterations defining the Release Process (previously kept in the
-[Release Captain ADR](/decisions/0004-release-captain)). The previous
+[Release Captain ADR](./0004-release-captain)). The previous
 document suffered significant changes since its inception, being modified for
 almost every release we have had; we are hoping the present document will
 benefit from more stability.
@@ -334,7 +334,7 @@ release candidate was properly validated, version `vX.Y.1` was released.
     release it is important to keep this information. A lightweight tag, on the
     other hand, is often used for temporary purposes.
 
-### [Sanity Checks](sanity-checks)
+### [Sanity Checks] {#sanity-checks}
 
 - [ ] `s3gw` container has been published on Quay for `vX.Y.Z`.
 - [ ] `s3gw-ui` container has been published on Quay for `vX.Y.Z`.
@@ -348,7 +348,7 @@ release candidate was properly validated, version `vX.Y.1` was released.
 - [ ] The release notes are in place, both on the `s3gw` repository's `main`
       branch and on the `s3gw-vX.Y` branch.
 
-## [Testing](testing)
+## [Testing] {#testing}
 
 To be expanded in the future, or maybe link to a proper testing document.
 

docs/decisions/0015-release-methodology.md

@@ -168,9 +168,9 @@ patch `F'` backported, and a new release candidate for version `X.Y.1` was
 created, `s3gw-vX.Y.1-rc1`. Once this release candidate was properly validated,
 version `vX.Y.1` was released.
 
-[process_adr]: /docs/decisions/0007-release-process.md
-[steps_adr]: /docs/decisions/0016-release-steps.md
-[testing_adr]: /docs/decisions/0017-release-testing.md
+[process_adr]: ./0007-release-process.md
+[steps_adr]: ./0016-release-steps.md
+[testing_adr]: ./0017-release-testing.md
 [quay_url]: https://quay.io
 [1_1]: https://github.com/aquarist-labs/s3gw-ui/
 [1_2]: https://github.com/aquarist-labs/s3gw-charts/

docs/decisions/0016-release-steps.md

@@ -31,7 +31,7 @@ There are five repositories involved in the release process:
 Of these, we refer to `s3gw` as the project's repository, and the remaining four
 to be sub-projects of the `s3gw` project.
 
-### [Note on the `s3gw-charts` repository](s3gw-charts-note)
+### [Note on the `s3gw-charts` repository] {#s3gw-charts-note}
 
 The Helm Chart requires the containers to be available for download from Quay
 before it can be published. Therefore, we can't trigger the `s3gw-charts`
@@ -211,7 +211,7 @@ For example purposes, we assume we are releasing version `0.99.0`.
     - project mailing list at `[email protected]`
 
     The format for the release announcement can be found in the
-    [Release Announcement][#announcement] section.
+    [Release Announcement](#announcement) section.
 
 19. Finally, we need to synchronize the `main` branches of the `s3gw` and the
     `s3gw-charts` repositories with their respective `s3gw-v0.99` branches, so
@@ -241,7 +241,7 @@ For example purposes, we assume we are releasing version `0.99.0`.
     release it is important to keep this information. A lightweight tag, on the
     other hand, is often used for temporary purposes.
 
-## [Manual Process](manual-process)
+## [Manual Process] {#manual-process}
 
 Assuming we are releasing version `0.99.0`, for every repository, first we need
 to branch off `main` to a new branch `s3gw-v0.99.0`. We can do this via the
@@ -367,7 +367,7 @@ GitHub web UI or via the CLI. This document describes doing it via the CLI.
    ```
 
 9. Once the release workflow finishes, and the containers are available in
-   [s3gw's Quay][quay_s3gw], we can start testing the release candidate. Please
+   [s3gw's Quay][s3gw_quay], we can start testing the release candidate. Please
    refer to the [Release Testing ADR][testing_adr] for more information
 
 10. If there is a need for further release candidates, go back to `step 4.`, and
@@ -393,7 +393,7 @@ GitHub web UI or via the CLI. This document describes doing it via the CLI.
     There may be drafts for the release candidates as well - delete them
 
 13. Announce the release on the various communication channels. Please refer to
-    the [Release Announcement][#announcement] section for more information.
+    the [Release Announcement](#announcement) section for more information.
 
 14. Finally, we just synchronize the `main` branches of the `s3gw` and the
     `s3gw-charts` repositories with their respective `s3gw-v0.99` branches, so
@@ -417,7 +417,7 @@ GitHub web UI or via the CLI. This document describes doing it via the CLI.
     And then open a Pull Request on each branch, from their respective
     `merge_v0.99_into_main` branches to `main`, and ask for a review.
 
-## [Release Announcement](announcement)
+## [Release Announcement] {#announcement}
 
 ### via Slack
 
@@ -485,7 +485,7 @@ Subject: Release v0.99.0
   [2] https://artifacthub.io/packages/helm/s3gw/s3gw
 ```
 
-### [Sanity Checks](sanity-checks)
+### [Sanity Checks] {#sanity-checks}
 
 - [ ] `s3gw` container has been published on Quay for `vX.Y.Z`.
 - [ ] `s3gw-ui` container has been published on Quay for `vX.Y.Z`.
@@ -494,15 +494,14 @@ Subject: Release v0.99.0
 - [ ] `latest` version containers are the same as the `vX.Y.Z` containers on
       Quay.
 - [ ] Helm Chart has been properly updated for `vX.Y.Z`.
-- [ ] Helm Chart for `vX.Y.Z` is visible on [ArtifactHub][10]. This can take
+- [ ] Helm Chart for `vX.Y.Z` is visible on [ArtifactHub][artifacthub]. This can take
       about 20 minutes.
 - [ ] The release notes are in place, both on the `s3gw` repository's `main`
       branch and on the `s3gw-vX.Y` branch.
 
-[process_adr]: /docs/decisions/0007-release-process.md
-[methodology_adr]: /docs/decisions/0015-release-methodology.md
-[testing_adr]: /docs/decisions/0017-release-testing.md
-[quay_url]: https://quay.io
+[process_adr]: ./0007-release-process.md
+[methodology_adr]: ./0015-release-methodology.md
+[testing_adr]: ./0017-release-testing.md
 [repo_ui]: https://github.com/aquarist-labs/s3gw-ui/
 [repo_charts]: https://github.com/aquarist-labs/s3gw-charts/
 [repo_s3gw]: https://github.com/aquarist-labs/s3gw/

docs/decisions/0017-release-testing.md

@@ -64,8 +64,8 @@ document with further testing scenarios.
 7. If at any point there's an indication that something is not working right, or
    you find a crash, please file an [issue on GitHub][new_issue].
 
-[process_adr]: /docs/decisions/0007-release-process.md
-[methodology_adr]: /docs/decisions/0015-release-methodology.md
-[release_adr]: /docs/decisions/0016-release-steps.md
+[process_adr]: ./0007-release-process.md
+[methodology_adr]: ./0015-release-methodology.md
+[release_adr]: ./0016-release-steps.md
 [helm_install_docs]: https://s3gw-docs.readthedocs.io/en/latest/helm-charts/
 [new_issue]: https://github.com/aquarist-labs/s3gw/issues/new/choose

docs/decisions/0018-s3gw-ha-model.md

@@ -6,7 +6,7 @@ We analyzed some High Availability - HA - concepts applied to the s3gw when used
 The final aim of the research is to identify an HA model we can reasonably rely on.
 
 The full and initial HA research document can be found here:
-[High Availability research](../research/ha/RATIONALE.md).
+[High Availability research](../research/ha/RATIONALE).
 You can find there all the rationales, motivations and the details about the tests performed.
 
 ## Considered Options
@@ -32,7 +32,7 @@ List of *desirable* characteristics owned by the *Active/Standby* model
 - Compatible with RWO persistent volume semantics
 - Acceptable restart timings on switch-overs and fail-overs (excluding the non-graceful node failure)
 
-Be aware that the [non-graceful node failure](../research/ha/RATIONALE.md#non-graceful-node-failure)
+Be aware that the [non-graceful node failure](../research/ha/RATIONALE#non-graceful-node-failure)
 problem cannot be entirely solved with the *Active/Standby* model alone.
 Regarding this, we have opened a [dedicated issue](https://github.com/longhorn/longhorn/issues/6803)
 within the Longhorn project.

docs/guide/helm-charts.md

@@ -24,8 +24,8 @@ the domain and then set the options on the command line directly using
 `helm --set key=value`.
 
 > **Note:** We do recommend at least updating the default access credentials,
-> but it is not necessary for a test installation. See the [options](#options)
-> section for more details.
+> but it is not necessary for a test installation. See the [Configuration](./config-s3gw.md)
+> document for more details.
 
 Once the domain has been configured, the chart can then be installed from
 within the repository directory:

docs/guide/quickstart.md

@@ -31,6 +31,4 @@ docker run -p 7480:7480 quay.io/s3gw/s3gw:latest
 ```
 
 For more information on building and running a container, read our
-[guide](../developing/#how-to-build-your-own-containers/).
-
-[1]: https://github.com/s3gw-tech/s3gw/blob/main/docs/helm-charts.md#options
+[guide](./developing#how-to-build-your-own-containers).

docs/research/ha/RATIONALE.md

@@ -1,6 +1,8 @@
 # High Availability with s3gw + Longhorn
 
-- [High Availability with s3gw + Longhorn](#high-availability-with-s3gw--longhorn)
+<!-- markdownlint-disable MD045 -->
+
+- High Availability with s3gw + Longhorn
   - [Active/Active](#activeactive)
   - [Active/Warm Standby](#activewarm-standby)
   - [Active/Standby](#activestandby)