]> git.apps.os.sepia.ceph.com Git - ceph-ansible.git/commitdiff
Docs: fix some typos
authorMatthew Vernon <mv3@sanger.ac.uk>
Wed, 10 Mar 2021 16:53:45 +0000 (16:53 +0000)
committerGuillaume Abrioux <gabrioux@redhat.com>
Thu, 11 Mar 2021 16:00:11 +0000 (17:00 +0100)
While working on the previous PR, I found a couple of typos in the
docs. This fixes those.

Signed-off-by: Matthew Vernon <mv3@sanger.ac.uk>
docs/source/day-2/upgrade.rst
docs/source/dev/index.rst
docs/source/index.rst
docs/source/installation/methods.rst
docs/source/installation/non-containerized.rst
docs/source/osds/scenarios.rst

index 47978321cd0d9d2bd3abc2243120842963fd8ebc..1ec658ccbcc6c01eb0b927164a7f7662b221370f 100644 (file)
@@ -3,7 +3,7 @@ Upgrading the ceph cluster
 
 ceph-ansible provides a playbook in ``infrastructure-playbooks`` for upgrading a Ceph cluster: ``rolling_update.yml``.
 
-This playbook could be used for both minor upgrade (X.Y to X.Z) or major upgrade (X to Y).
+This playbook could be used for both minor upgrades (X.Y to X.Z) or major upgrades (X to Y).
 
 Before running a major upgrade you need to update the ceph-ansible version first.
 
@@ -14,4 +14,4 @@ example:
    $ ansible-playbook -vv -i hosts infrastructure-playbooks/rolling_update.yml
 
 .. note::
-   This playbook isn't intended to be run with the ``--limit`` ansible option.
\ No newline at end of file
+   This playbook isn't intended to be run with the ``--limit`` ansible option.
index 0ce3305ae61e5ed0f3bf62691d9aa779a6a2124f..a3f56368f23da3a5183ed28d1ae296a407419319 100644 (file)
@@ -84,7 +84,7 @@ If a change should be backported to a ``stable-*`` Git branch:
   ``git checkout --no-track -b my-backported-change origin/stable-5.0``
 - Cherry-pick your change: ``git cherry-pick -x (your-sha1)``
 - Create a new pull request against the ``stable-5.0`` branch.
-- Ensure that your pull requests's title has the prefix "backport:", so it's clear
+- Ensure that your pull request's title has the prefix "backport:", so it's clear
   to reviewers what this is about.
 - Add a comment in your backport pull request linking to the original (master) pull request.
 
index 6e49224ced3441e95ac1a6885a5a95852340ac79..c26b6b6196bd4e7d3a2b37177a790b43052d45f2 100644 (file)
@@ -68,7 +68,7 @@ Releases
 ========
 
 The following branches should be used depending on your requirements. The ``stable-*``
-branches have been QE tested and sometimes recieve backport fixes throughout their lifecycle.
+branches have been QE tested and sometimes receive backport fixes throughout their lifecycle.
 The ``master`` branch should be considered experimental and used with caution.
 
 - ``stable-3.0`` Supports Ceph versions ``jewel`` and ``luminous``. This branch requires Ansible version ``2.4``.
@@ -198,7 +198,7 @@ Configuration
 The configuration for your Ceph cluster will be set by the use of ansible variables that ``ceph-ansible`` provides. All of these options and their default
 values are defined in the ``group_vars/`` directory at the root of the ``ceph-ansible`` project. Ansible will use configuration in a ``group_vars/`` directory
 that is relative to your inventory file or your playbook. Inside of the ``group_vars/`` directory there are many sample Ansible configuration files that relate
-to each of the Ceph daemon groups by their filename. For example, the ``osds.yml.sample`` contains all the default configuation for the OSD daemons. The ``all.yml.sample``
+to each of the Ceph daemon groups by their filename. For example, the ``osds.yml.sample`` contains all the default configuration for the OSD daemons. The ``all.yml.sample``
 file is a special ``group_vars`` file that applies to all hosts in your cluster.
 
 .. note::
index 7a927fd6c40e99a45643450ad001c2ed5a11513b..2c30943fa6097bb5c7f3756f4bb245af7e6691db 100644 (file)
@@ -9,4 +9,4 @@ ceph-ansible can deploy Ceph either in a non-containerized context (via packages
    non-containerized
    containerized
 
-The difference here is that you don't have the rbd command on the host when using the containerized deployment so everything related to ceph needs to be executed within a container. So in the case there is software like e.g. Open Nebula which requires that the rbd command is accessible directly on the host (non-containerized) then you have to install the rbd command by yourself on those servers outside of containers. (Or make sure that this software somehow runs within containers as well and that it can access rbd.
+The difference here is that you don't have the rbd command on the host when using the containerized deployment so everything related to ceph needs to be executed within a container. So in the case there is software like e.g. Open Nebula which requires that the rbd command is accessible directly on the host (non-containerized) then you have to install the rbd command by yourself on those servers outside of containers (or make sure that this software somehow runs within containers as well and that it can access rbd).
index a00d66648269a49f6c6096045cd0030c5677e693..f56bdec2aed9d45cb09c6498da8535ea0a37716b 100644 (file)
@@ -1,5 +1,5 @@
-Non containerized deployement
-=============================
+Non containerized deployment
+============================
 
 The following are all of the available options for the installing Ceph through different channels.
 
@@ -54,7 +54,7 @@ Custom repository
 ~~~~~~~~~~~~~~~~~
 
 If ``ceph_repository`` is set to ``custom``, packages you will be by default installed from a desired repository.
-This repository is specifie with ``ceph_custom_repo``, e.g: ``ceph_custom_repo: https://server.domain.com/ceph-custom-repo``.
+This repository is specified with ``ceph_custom_repo``, e.g: ``ceph_custom_repo: https://server.domain.com/ceph-custom-repo``.
 
 
 Origin: Distro
index 210b07797efedf24ed9d2d6d006036724fc9d40e..a4deb6ba0e8550b0b28242c0cae8fdee98c8cda6 100644 (file)
@@ -17,7 +17,7 @@ At present (starting from stable-4.0), there is only one scenario, which default
 
 So there is no need to configure ``osd_scenario`` anymore, it defaults to ``lvm``.
 
-The ``lvm`` scenario mentionned above support both containerized and non-containerized cluster.
+The ``lvm`` scenario mentioned above support both containerized and non-containerized cluster.
 As a reminder, deploying a containerized cluster can be done by setting ``containerized_deployment``
 to ``True``.
 
@@ -223,4 +223,4 @@ Supported ``lvm_volumes`` configuration settings:
        journal: journal-lv2
        journal_vg: journal-vg2
 
-.. note:: Volume groups and logical volumes must exist.
\ No newline at end of file
+.. note:: Volume groups and logical volumes must exist.