mirror of https://github.com/ceph/ceph-ansible.git
Docs: fix some typos
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>pull/6333/head
parent
a7f2fa73e6
commit
8b1474ab75
|
@ -3,7 +3,7 @@ Upgrading the ceph cluster
|
||||||
|
|
||||||
ceph-ansible provides a playbook in ``infrastructure-playbooks`` for upgrading a Ceph cluster: ``rolling_update.yml``.
|
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.
|
Before running a major upgrade you need to update the ceph-ansible version first.
|
||||||
|
|
||||||
|
|
|
@ -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``
|
``git checkout --no-track -b my-backported-change origin/stable-5.0``
|
||||||
- Cherry-pick your change: ``git cherry-pick -x (your-sha1)``
|
- Cherry-pick your change: ``git cherry-pick -x (your-sha1)``
|
||||||
- Create a new pull request against the ``stable-5.0`` branch.
|
- 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.
|
to reviewers what this is about.
|
||||||
- Add a comment in your backport pull request linking to the original (master) pull request.
|
- Add a comment in your backport pull request linking to the original (master) pull request.
|
||||||
|
|
||||||
|
|
|
@ -68,7 +68,7 @@ Releases
|
||||||
========
|
========
|
||||||
|
|
||||||
The following branches should be used depending on your requirements. The ``stable-*``
|
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.
|
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``.
|
- ``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
|
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
|
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
|
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.
|
file is a special ``group_vars`` file that applies to all hosts in your cluster.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
|
@ -9,4 +9,4 @@ ceph-ansible can deploy Ceph either in a non-containerized context (via packages
|
||||||
non-containerized
|
non-containerized
|
||||||
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).
|
||||||
|
|
|
@ -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.
|
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.
|
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
|
Origin: Distro
|
||||||
|
|
|
@ -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``.
|
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``
|
As a reminder, deploying a containerized cluster can be done by setting ``containerized_deployment``
|
||||||
to ``True``.
|
to ``True``.
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue