Add legal disclaimer, fix failing checks

Signed-off-by: Sharon Koech <sharon.koech@canonical.com>

Author: skoech

docs/.sphinx/.wordlist.txt

@@ -329,3 +329,42 @@ snapcrafting
 subcluster
 swrast
 zSystems
+AZs
+bcache
+cephadm
+Clos
+colocated
+CPUs
+customized
+Disaggregated
+disaggregated
+DWPD
+Gbps
+Gbit
+GW
+HDDs
+Hyperconverged
+hyperconverged
+Juju's
+LACP
+lifecycle
+MDSs
+MGRs
+MONs
+NICs
+NL
+OAM
+oF
+OOB
+optimizing
+oversubscription
+PoC
+preboot
+RadosGW
+reachability
+RGWs
+SAS
+SSD
+SSDs
+TCO
+VMware

docs/explanation/canonical-ceph-reference-architecture/index.rst

@@ -21,14 +21,16 @@ configurations, to further inform your architectural choices.
 
 .. warning::
 
-   This reference architecture is not prescriptive, i.e., it serves only as a
-   recommendation for reference hardware. We advise that you have a specific
-   discussion with Canonical before purchasing any equipment, in particular to
-   ensure there are no performance or capacity pitfalls found after the
-   deployment. Canonical is not liable or responsible for any equipment
-   purchases made as a result of this reference architecture. Following these
-   recommendations does not guarantee that the proposed hardware will meet the
-   requirements of your project or use case.
+   This reference architecture is a starting point, not a prescription. Before making any
+   purchasing decisions, we recommend reviewing your plans with Canonical to ensure they
+   align with your specific needs. Hardware requirements can vary significantly depending
+   on your workload and goals.
+
+   Canonical is not liable or responsible for any equipment purchases made as a result
+   of this reference architecture. Following these recommendations does not guarantee
+   that the proposed hardware will meet the requirements of your project or use case.
+
+   To discuss your specific requirements, contact Canonical.
 
 .. toctree::
     :maxdepth: 2

docs/explanation/canonical-ceph-reference-architecture/processor-requirements.rst

@@ -35,7 +35,7 @@ OSDs
 In general, reserving 2 cores per OSD is sufficient. The type of storage
 device also impacts the number of cores utilised by the OSD. A non-volatile
 memory express (NVMe) OSD drive can leverage up to 6 cores, which will provide
-higher input/output operations per second (IOPs) than if fewer cores are
+higher input/output operations per second (IOPS) than if fewer cores are
 available. It is therefore more reliable to consider the desired IOPS and
 calculate the number of cores required from there. 1 core can provide
 1000–3000 IOPS and 200–500 MB/s throughput.

docs/reference/canonical-ceph-hardware-recommendations/software-requirements.rst

@@ -25,7 +25,7 @@ Canonical Ceph cluster deployment:
    * - Ubuntu (Host OS)
      - `Ubuntu releases <https://releases.ubuntu.com/>`__
    * - Linux Kernel
-     - `Ubuntu Kernel release cycle <https://ubuntu.com/about/release-cycle#ubuntu-kernel-release-cycle>`__
+     - `Ubuntu Kernel release cycle <https://ubuntu.com/about/release-cycle/>`__
    * - Canonical Ceph
      - `Charmed Ceph release notes <https://ubuntu.com/ceph/docs/release-notes>`__,
        `MicroCeph release notes <https://canonical-microceph.readthedocs-hosted.com/latest/reference/release-notes/>`__,