doc: remove references to ceph-deploy

Signed-off-by: Patrick Donnelly <pdonnell@ibm.com>
This commit is contained in:
Patrick Donnelly 2026-03-16 11:56:43 -04:00
parent 4ebd6f62eb
commit 55968723d6
No known key found for this signature in database
GPG Key ID: 053758C0A8A3CE2F
5 changed files with 28 additions and 49 deletions

View File

@ -149,8 +149,6 @@ Task to do:
- Improve the FreeBSD /etc/rc.d initscripts in the Ceph stack. Both - Improve the FreeBSD /etc/rc.d initscripts in the Ceph stack. Both
for testing, but mainly for running Ceph on production machines. for testing, but mainly for running Ceph on production machines.
Work on ceph-disk and ceph-deploy to make it more FreeBSD and ZFS
compatible.
- Build test-cluster and start running some of the teuthology integration - Build test-cluster and start running some of the teuthology integration
tests on these. tests on these.

View File

@ -6,7 +6,7 @@ Converting an Existing Cluster to Cephadm
It is possible to convert some existing clusters so that they can be managed It is possible to convert some existing clusters so that they can be managed
with ``cephadm``. This statement applies to some clusters that were deployed with ``cephadm``. This statement applies to some clusters that were deployed
with ``ceph-deploy``, ``ceph-ansible``, or ``DeepSea``. with ``ceph-deploy`` (a legacy deployment tool), ``ceph-ansible``, or ``DeepSea``.
This section of the documentation explains how to determine whether your This section of the documentation explains how to determine whether your
clusters can be converted to a state in which they can be managed by clusters can be converted to a state in which they can be managed by

View File

@ -110,9 +110,6 @@ integration tests for all the Ceph components.
* - **Component** * - **Component**
- **Function** - **Function**
* - `ceph-deploy <https://github.com/ceph/ceph/tree/master/qa/suites/ceph-deploy>`_
- install a Ceph cluster with ``ceph-deploy`` (`ceph-deploy man page`_)
* - `dummy <https://github.com/ceph/ceph/tree/master/qa/suites/dummy>`_ * - `dummy <https://github.com/ceph/ceph/tree/master/qa/suites/dummy>`_
- get a machine, do nothing and return success (commonly used to verify - get a machine, do nothing and return success (commonly used to verify
that the integration testing infrastructure works as expected) that the integration testing infrastructure works as expected)
@ -300,12 +297,12 @@ yaml facets, followed by an expression in curly braces (``{}``) consisting of
a list of yaml facets in order of concatenation. For instance the a list of yaml facets in order of concatenation. For instance the
test description:: test description::
ceph-deploy/basic/{distros/rocky_10.0.yaml tasks/ceph-deploy.yaml} foo/basic/{distros/rocky_10.0.yaml tasks/ceph.yaml}
signifies the concatenation of two files: signifies the concatenation of two files:
* ceph-deploy/basic/distros/rocky_10.0.yaml * foo/basic/distros/rocky_10.0.yaml
* ceph-deploy/basic/tasks/ceph-deploy.yaml * foo/basic/tasks/ceph.yaml
How tests are built from directories How tests are built from directories
------------------------------------ ------------------------------------
@ -329,62 +326,57 @@ The convolution operator, implemented as a (typically empty) file called ``%``,
tells teuthology to construct a test matrix from YAML facets found in tells teuthology to construct a test matrix from YAML facets found in
subdirectories below the directory containing the operator. subdirectories below the directory containing the operator.
For example, the `ceph-deploy suite For example, a hypothetical ``foo`` suite is defined by the ``qa/suites/foo``
<https://github.com/ceph/ceph/tree/master/qa/suites/ceph-deploy/>`_ is tree, which consists of the files and subdirectories in the following structure
defined by the ``suites/ceph-deploy/`` tree, which consists of the files and
subdirectories in the following structure
.. code-block:: none .. code-block:: none
qa/suites/ceph-deploy qa/suites/foo
├── % ├── %
├── distros ├── distros
│   ├── rocky_10.0.yaml │   ├── rocky_10.0.yaml
│   └── ubuntu_24.04.yaml │   └── ubuntu_24.04.yaml
└── tasks └── tasks
└── ceph-deploy.yaml └── ceph.yaml
This is interpreted as a 2x1 matrix consisting of two tests: This is interpreted as a 2x1 matrix consisting of two tests:
1. ceph-deploy/basic/{distros/rocky_10.0.yaml tasks/ceph-deploy.yaml} 1. ``foo/{distros/rocky_10.0.yaml tasks/ceph.yaml}``
2. ceph-deploy/basic/{distros/ubuntu_24.04.yaml tasks/ceph-deploy.yaml} 2. ``foo/{distros/ubuntu_24.04.yaml tasks/ceph.yaml}``
i.e. the concatenation of rocky_10.0.yaml and ceph-deploy.yaml and i.e. the concatenation of ``rocky_10.0.yaml`` and ``ceph.yaml`` and the
the concatenation of ubuntu_24.04.yaml and ceph-deploy.yaml, respectively. concatenation of ``ubuntu_24.04.yaml`` and ``ceph.yaml``, respectively. In
In human terms, this means that the task found in ``ceph-deploy.yaml`` is human terms, this means that the task found in ``ceph.yaml`` is intended to run
intended to run on both Rocky Linux 10.0 and Ubuntu 24.04 LTS. on both Rocky Linux 10.0 and Ubuntu 24.04 LTS.
Without the file percent, the ``ceph-deploy`` tree would be interpreted as Without the file percent, the ``foo`` tree would be interpreted as
three standalone tests: three standalone tests:
* ceph-deploy/basic/distros/rocky_10.0.yaml * foo/distros/rocky_10.0.yaml
* ceph-deploy/basic/distros/ubuntu_24.04.yaml * foo/distros/ubuntu_24.04.yaml
* ceph-deploy/basic/tasks/ceph-deploy.yaml * foo/tasks/ceph.yaml
(which would of course be wrong in this case). (which would of course be wrong in this case).
Referring to the `ceph/qa sub-directory`_, you will notice that the You will notice that symlinks are sometimes used in QA suites. By using
``rocky_10.0.yaml`` and ``ubuntu_24.04.yaml`` files in the symlinks instead of copying, a single file can appear in multiple suites. This
``suites/ceph-deploy/basic/distros/`` directory are implemented as symlinks. eases the maintenance of the test framework as a whole.
By using symlinks instead of copying, a single file can appear in multiple
suites. This eases the maintenance of the test framework as a whole.
All the tests generated from the ``suites/ceph-deploy/`` directory tree All the tests generated from the ``suites/foo/`` directory tree
(also known as the "ceph-deploy suite") can be run with (which would be referred to as the "foo suite") can be run with
.. prompt:: bash $ .. prompt:: bash $
teuthology-suite --machine-type smithi --suite ceph-deploy teuthology-suite --machine-type smithi --suite foo
An individual test from the `ceph-deploy suite`_ can be run by adding the An individual test would be run by adding the ``--filter`` option:
``--filter`` option
.. prompt:: bash $ .. prompt:: bash $
teuthology-suite \ teuthology-suite \
--machine-type smithi \ --machine-type smithi \
--suite ceph-deploy/basic \ --suite foo \
--filter 'ceph-deploy/basic/{distros/ubuntu_24.04.yaml tasks/ceph-deploy.yaml}' --filter 'foo/{distros/ubuntu_24.04.yaml tasks/ceph.yaml}'
.. note:: To run a standalone test like the one in `Reading a standalone .. note:: To run a standalone test like the one in `Reading a standalone
test`_, ``--suite`` alone is sufficient. If you want to run a single test`_, ``--suite`` alone is sufficient. If you want to run a single
@ -673,4 +665,3 @@ test will be first.
.. _teuthology repository: https://github.com/ceph/teuthology .. _teuthology repository: https://github.com/ceph/teuthology
.. _teuthology framework: https://github.com/ceph/teuthology .. _teuthology framework: https://github.com/ceph/teuthology
.. _teuthology-describe usecases: https://gist.github.com/jdurgin/09711d5923b583f60afc .. _teuthology-describe usecases: https://gist.github.com/jdurgin/09711d5923b583f60afc
.. _ceph-deploy man page: ../../../../man/8/ceph-deploy

View File

@ -43,16 +43,6 @@ Ceph clusters using Ansible.
and dashboard integration introduced in Nautilus and Octopus are not and dashboard integration introduced in Nautilus and Octopus are not
available in Ceph clusters deployed by means of ceph-ansible. available in Ceph clusters deployed by means of ceph-ansible.
`ceph-deploy <https://docs.ceph.com/projects/ceph-deploy/en/latest/>`_ is a
tool that can be used to quickly deploy clusters. It is deprecated.
.. IMPORTANT::
ceph-deploy is not actively maintained. It is not tested on versions of Ceph
newer than Nautilus. It does not support RHEL8, CentOS 8, or newer operating
systems.
`ceph-salt <https://github.com/ceph/ceph-salt>`_ installs Ceph using Salt and cephadm. `ceph-salt <https://github.com/ceph/ceph-salt>`_ installs Ceph using Salt and cephadm.
`jaas.ai/ceph-mon <https://jaas.ai/ceph-mon>`_ installs Ceph using Juju. `jaas.ai/ceph-mon <https://jaas.ai/ceph-mon>`_ installs Ceph using Juju.

View File

@ -14,7 +14,7 @@ before working with the :term:`Ceph Block Device`.
/------------------\ /----------------\ /------------------\ /----------------\
| Admin Node | | ceph-client | | Admin Node | | ceph-client |
| +-------->+ cCCC | | +-------->+ cCCC |
| ceph-deploy | | ceph | | | | ceph |
\------------------/ \----------------/ \------------------/ \----------------/