From 55968723d682ba20f0f0a25a7227c4b09247e53c Mon Sep 17 00:00:00 2001 From: Patrick Donnelly Date: Mon, 16 Mar 2026 11:56:43 -0400 Subject: [PATCH] doc: remove references to ceph-deploy Signed-off-by: Patrick Donnelly --- README.FreeBSD | 2 - doc/cephadm/adoption.rst | 2 +- ...s-integration-testing-teuthology-intro.rst | 61 ++++++++----------- doc/install/index.rst | 10 --- doc/start/quick-rbd.rst | 2 +- 5 files changed, 28 insertions(+), 49 deletions(-) diff --git a/README.FreeBSD b/README.FreeBSD index a3193f7d23e..8eb98e7c78a 100644 --- a/README.FreeBSD +++ b/README.FreeBSD @@ -149,8 +149,6 @@ Task to do: - Improve the FreeBSD /etc/rc.d initscripts in the Ceph stack. Both 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 tests on these. diff --git a/doc/cephadm/adoption.rst b/doc/cephadm/adoption.rst index d9f5f8c6199..177e5bedc2a 100644 --- a/doc/cephadm/adoption.rst +++ b/doc/cephadm/adoption.rst @@ -6,7 +6,7 @@ Converting an Existing Cluster to Cephadm 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 ``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 clusters can be converted to a state in which they can be managed by diff --git a/doc/dev/developer_guide/testing_integration_tests/tests-integration-testing-teuthology-intro.rst b/doc/dev/developer_guide/testing_integration_tests/tests-integration-testing-teuthology-intro.rst index e97911c3e4e..89e31563d60 100644 --- a/doc/dev/developer_guide/testing_integration_tests/tests-integration-testing-teuthology-intro.rst +++ b/doc/dev/developer_guide/testing_integration_tests/tests-integration-testing-teuthology-intro.rst @@ -110,9 +110,6 @@ integration tests for all the Ceph components. * - **Component** - **Function** - * - `ceph-deploy `_ - - install a Ceph cluster with ``ceph-deploy`` (`ceph-deploy man page`_) - * - `dummy `_ - get a machine, do nothing and return success (commonly used to verify 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 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: -* ceph-deploy/basic/distros/rocky_10.0.yaml -* ceph-deploy/basic/tasks/ceph-deploy.yaml +* foo/basic/distros/rocky_10.0.yaml +* foo/basic/tasks/ceph.yaml 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 subdirectories below the directory containing the operator. -For example, the `ceph-deploy suite -`_ is -defined by the ``suites/ceph-deploy/`` tree, which consists of the files and -subdirectories in the following structure +For example, a hypothetical ``foo`` suite is defined by the ``qa/suites/foo`` +tree, which consists of the files and subdirectories in the following structure .. code-block:: none - qa/suites/ceph-deploy + qa/suites/foo ├── % ├── distros │   ├── rocky_10.0.yaml │   └── ubuntu_24.04.yaml └── tasks - └── ceph-deploy.yaml + └── ceph.yaml This is interpreted as a 2x1 matrix consisting of two tests: -1. ceph-deploy/basic/{distros/rocky_10.0.yaml tasks/ceph-deploy.yaml} -2. ceph-deploy/basic/{distros/ubuntu_24.04.yaml tasks/ceph-deploy.yaml} +1. ``foo/{distros/rocky_10.0.yaml tasks/ceph.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 -the concatenation of ubuntu_24.04.yaml and ceph-deploy.yaml, respectively. -In human terms, this means that the task found in ``ceph-deploy.yaml`` is -intended to run on both Rocky Linux 10.0 and Ubuntu 24.04 LTS. +i.e. the concatenation of ``rocky_10.0.yaml`` and ``ceph.yaml`` and the +concatenation of ``ubuntu_24.04.yaml`` and ``ceph.yaml``, respectively. In +human terms, this means that the task found in ``ceph.yaml`` is intended to run +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: -* ceph-deploy/basic/distros/rocky_10.0.yaml -* ceph-deploy/basic/distros/ubuntu_24.04.yaml -* ceph-deploy/basic/tasks/ceph-deploy.yaml +* foo/distros/rocky_10.0.yaml +* foo/distros/ubuntu_24.04.yaml +* foo/tasks/ceph.yaml (which would of course be wrong in this case). -Referring to the `ceph/qa sub-directory`_, you will notice that the -``rocky_10.0.yaml`` and ``ubuntu_24.04.yaml`` files in the -``suites/ceph-deploy/basic/distros/`` directory are implemented as symlinks. -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. +You will notice that symlinks are sometimes used in QA suites. 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 -(also known as the "ceph-deploy suite") can be run with +All the tests generated from the ``suites/foo/`` directory tree +(which would be referred to as the "foo suite") can be run with .. 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 -``--filter`` option +An individual test would be run by adding the ``--filter`` option: .. prompt:: bash $ teuthology-suite \ --machine-type smithi \ - --suite ceph-deploy/basic \ - --filter 'ceph-deploy/basic/{distros/ubuntu_24.04.yaml tasks/ceph-deploy.yaml}' + --suite foo \ + --filter 'foo/{distros/ubuntu_24.04.yaml tasks/ceph.yaml}' .. 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 @@ -673,4 +665,3 @@ test will be first. .. _teuthology repository: https://github.com/ceph/teuthology .. _teuthology framework: https://github.com/ceph/teuthology .. _teuthology-describe usecases: https://gist.github.com/jdurgin/09711d5923b583f60afc -.. _ceph-deploy man page: ../../../../man/8/ceph-deploy diff --git a/doc/install/index.rst b/doc/install/index.rst index 82585edd8b8..ed3dec18888 100644 --- a/doc/install/index.rst +++ b/doc/install/index.rst @@ -43,16 +43,6 @@ Ceph clusters using Ansible. and dashboard integration introduced in Nautilus and Octopus are not available in Ceph clusters deployed by means of ceph-ansible. - -`ceph-deploy `_ 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 `_ installs Ceph using Salt and cephadm. `jaas.ai/ceph-mon `_ installs Ceph using Juju. diff --git a/doc/start/quick-rbd.rst b/doc/start/quick-rbd.rst index 3c095355895..7dcde79c9a9 100644 --- a/doc/start/quick-rbd.rst +++ b/doc/start/quick-rbd.rst @@ -14,7 +14,7 @@ before working with the :term:`Ceph Block Device`. /------------------\ /----------------\ | Admin Node | | ceph-client | | +-------->+ cCCC | - | ceph-deploy | | ceph | + | | | ceph | \------------------/ \----------------/