]> git-server-git.apps.pok.os.sepia.ceph.com Git - ceph.git/commitdiff
doc: remove references to ceph-deploy
authorPatrick Donnelly <pdonnell@ibm.com>
Mon, 16 Mar 2026 15:56:43 +0000 (11:56 -0400)
committerPatrick Donnelly <pdonnell@ibm.com>
Tue, 14 Apr 2026 13:03:58 +0000 (09:03 -0400)
Signed-off-by: Patrick Donnelly <pdonnell@ibm.com>
README.FreeBSD
doc/cephadm/adoption.rst
doc/dev/developer_guide/testing_integration_tests/tests-integration-testing-teuthology-intro.rst
doc/install/index.rst
doc/start/quick-rbd.rst

index a3193f7d23e39285dca5161b36343e899e9df7e0..8eb98e7c78ae888ae8415a43f047d0897c19089c 100644 (file)
@@ -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.
index d9f5f8c6199aed34d9b0eeea499403ea2f6897c0..177e5bedc2adcab792902ae62d464d4e01053884 100644 (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
 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
index e97911c3e4efa9cfe680270cbf2ee59940b85bd7..89e31563d60680fdc1447e56fe073b34b3faf8e5 100644 (file)
@@ -110,9 +110,6 @@ integration tests for all the Ceph components.
   * - **Component**
     - **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>`_
     - 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
-<https://github.com/ceph/ceph/tree/master/qa/suites/ceph-deploy/>`_ 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
index 82585edd8b8c62a76afc826b8c1dfc5a290b07ef..ed3dec18888fe136b0ffeebe17740f69ccd7d473 100644 (file)
@@ -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 <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.
 
 `jaas.ai/ceph-mon <https://jaas.ai/ceph-mon>`_ installs Ceph using Juju.
index 3c095355895d2aabc99dc11cff809b1bd9884547..7dcde79c9a9e9ae4d27f13be3283737c7bc31224 100644 (file)
@@ -14,7 +14,7 @@ before working with the :term:`Ceph Block Device`.
            /------------------\         /----------------\
            |    Admin Node    |         |   ceph-client  |
            |                  +-------->+ cCCC           |
-           |    ceph-deploy   |         |      ceph      |
+           |                  |         |      ceph      |
            \------------------/         \----------------/