]> git.proxmox.com Git - ceph.git/blobdiff - ceph/doc/man/8/ceph-deploy.rst
update sources to ceph Nautilus 14.2.1
[ceph.git] / ceph / doc / man / 8 / ceph-deploy.rst
index ff96574dff6b290ba6ee4c3b49486dd82886a396..3d099252a992978357e0342aec754aa7f072710c 100644 (file)
@@ -1,5 +1,7 @@
 :orphan:
 
+.. _ceph-deploy:
+
 =====================================
  ceph-deploy -- Ceph deployment tool
 =====================================
@@ -15,11 +17,7 @@ Synopsis
 
 | **ceph-deploy** **mon** *create-initial*
 
-| **ceph-deploy** **osd** *prepare* [*ceph-node*]:[*dir-path*]
-
-| **ceph-deploy** **osd** *activate* [*ceph-node*]:[*dir-path*]
-
-| **ceph-deploy** **osd** *create* [*ceph-node*]:[*dir-path*]
+| **ceph-deploy** **osd** *create* *--data* *device* *ceph-node*
 
 | **ceph-deploy** **admin** [*admin-node*][*ceph-node*...]
 
@@ -188,7 +186,7 @@ Subcommand ``add`` is used to add a monitor to an existing cluster. It first
 detects platform and distro for desired host and checks if hostname is compatible
 for deployment. It then uses the monitor keyring, ensures configuration for new
 monitor host and adds the monitor to the cluster. If the section for the monitor
-exists and defines a mon addr that will be used, otherwise it will fallback by
+exists and defines a monitor address that will be used, otherwise it will fallback by
 resolving the hostname to an IP. If :option:`--address` is used it will override
 all other options. After adding the monitor to the cluster, it gives it some time
 to start. It then looks for any monitor errors and checks monitor status. Monitor
@@ -244,53 +242,19 @@ Here, [HOST] is hostname of the monitor from where keys are to be pulled.
 disk
 ----
 
-Manage disks on a remote host. It actually triggers the ``ceph-disk`` utility
-and it's subcommands to manage disks.
+Manage disks on a remote host. It actually triggers the ``ceph-volume`` utility
+and its subcommands to manage disks.
 
 Subcommand ``list`` lists disk partitions and Ceph OSDs.
 
 Usage::
 
-       ceph-deploy disk list [HOST:[DISK]]
-
-Here, [HOST] is hostname of the node and [DISK] is disk name or path.
-
-Subcommand ``prepare`` prepares a directory, disk or drive for a Ceph OSD. It
-creates a GPT partition, marks the partition with Ceph type uuid, creates a
-file system, marks the file system as ready for Ceph consumption, uses entire
-partition and adds a new partition to the journal disk.
-
-Usage::
-
-       ceph-deploy disk prepare [HOST:[DISK]]
-
-Here, [HOST] is hostname of the node and [DISK] is disk name or path.
-
-Subcommand ``activate`` activates the Ceph OSD. It mounts the volume in a
-temporary location, allocates an OSD id (if needed), remounts in the correct
-location ``/var/lib/ceph/osd/$cluster-$id`` and starts ``ceph-osd``. It is
-triggered by ``udev`` when it sees the OSD GPT partition type or on ceph service
-start with ``ceph disk activate-all``.
-
-Usage::
-
-       ceph-deploy disk activate [HOST:[DISK]]
-
-Here, [HOST] is hostname of the node and [DISK] is disk name or path.
-
-Subcommand ``zap`` zaps/erases/destroys a device's partition table and contents.
-It actually uses ``sgdisk`` and it's option ``--zap-all`` to destroy both GPT and
-MBR data structures so that the disk becomes suitable for repartitioning.
-``sgdisk`` then uses ``--mbrtogpt`` to convert the MBR or BSD disklabel disk to a
-GPT disk. The ``prepare`` subcommand can now be executed which will create a new
-GPT partition.
-
-Usage::
-
-       ceph-deploy disk zap [HOST:[DISK]]
+       ceph-deploy disk list HOST
 
-Here, [HOST] is hostname of the node and [DISK] is disk name or path.
 
+Subcommand ``zap`` zaps/erases/destroys a device's partition table and
+contents.  It actually uses ``ceph-volume lvm zap`` remotely, alternatively
+allowing someone to remove the Ceph metadata from the logical volume.
 
 osd
 ---
@@ -298,46 +262,35 @@ osd
 Manage OSDs by preparing data disk on remote host. ``osd`` makes use of certain
 subcommands for managing OSDs.
 
-Subcommand ``prepare`` prepares a directory, disk or drive for a Ceph OSD. It
-first checks against multiple OSDs getting created and warns about the
-possibility of more than the recommended which would cause issues with max
-allowed PIDs in a system. It then reads the bootstrap-osd key for the cluster or
-writes the bootstrap key if not found. It then uses :program:`ceph-disk`
-utility's ``prepare`` subcommand to prepare the disk, journal and deploy the OSD
-on the desired host. Once prepared, it gives some time to the OSD to settle and
-checks for any possible errors and if found, reports to the user.
-
-Usage::
-
-       ceph-deploy osd prepare HOST:DISK[:JOURNAL] [HOST:DISK[:JOURNAL]...]
+Subcommand ``create`` prepares a device for Ceph OSD. It first checks against
+multiple OSDs getting created and warns about the possibility of more than the
+recommended which would cause issues with max allowed PIDs in a system. It then
+reads the bootstrap-osd key for the cluster or writes the bootstrap key if not
+found.
+It then uses :program:`ceph-volume` utility's ``lvm create`` subcommand to
+prepare the disk, (and journal if using filestore) and deploy the OSD on the desired host.
+Once prepared, it gives some time to the OSD to start and checks for any
+possible errors and if found, reports to the user.
 
-Subcommand ``activate`` activates the OSD prepared using ``prepare`` subcommand.
-It actually uses :program:`ceph-disk` utility's ``activate`` subcommand with
-appropriate init type based on distro to activate the OSD. Once activated, it
-gives some time to the OSD to start and checks for any possible errors and if
-found, reports to the user. It checks the status of the prepared OSD, checks the
-OSD tree and makes sure the OSDs are up and in.
+Bluestore Usage::
 
-Usage::
+       ceph-deploy osd create --data DISK HOST
 
-       ceph-deploy osd activate HOST:DISK[:JOURNAL] [HOST:DISK[:JOURNAL]...]
+Filestore Usage::
 
-Subcommand ``create`` uses ``prepare`` and ``activate`` subcommands to create an
-OSD.
+       ceph-deploy osd create --data DISK --journal JOURNAL HOST
 
-Usage::
 
-       ceph-deploy osd create HOST:DISK[:JOURNAL] [HOST:DISK[:JOURNAL]...]
+.. note:: For other flags available, please see the man page or the --help menu
+          on ceph-deploy osd create
 
-Subcommand ``list`` lists disk partitions, Ceph OSDs and prints OSD metadata.
-It gets the osd tree from a monitor host, uses the ``ceph-disk-list`` output
-and gets the mount point by matching the line where the partition mentions
-the OSD name, reads metadata from files, checks if a journal path exists,
-if the OSD is in a OSD tree and prints the OSD metadata.
+Subcommand ``list`` lists devices associated to Ceph as part of an OSD.
+It uses the ``ceph-volume lvm list`` output that has a rich output, mapping
+OSDs to devices and other interesting information about the OSD setup.
 
 Usage::
 
-       ceph-deploy osd list HOST:DISK[:JOURNAL] [HOST:DISK[:JOURNAL]...]
+       ceph-deploy osd list HOST
 
 
 admin
@@ -452,35 +405,6 @@ Here, [PKGs] is comma-separated package names and [HOST] is hostname of the
 remote node where packages are to be installed or removed from.
 
 
-calamari
---------
-
-Install and configure Calamari nodes. It first checks if distro is supported
-for Calamari installation by ceph-deploy. An argument ``connect`` is used for
-installation and configuration. It checks for ``ceph-deploy`` configuration
-file (cd_conf) and Calamari release repo or ``calamari-minion`` repo. It relies
-on default for repo installation as it doesn't install Ceph unless specified
-otherwise. ``options`` dictionary is also defined because ``ceph-deploy``
-pops items internally which causes issues when those items are needed to be
-available for every host. If the distro is Debian/Ubuntu, it is ensured that
-proxy is disabled for ``calamari-minion`` repo. ``calamari-minion`` package is
-then installed and custom repository files are added. minion config  is placed
-prior to installation so that it is present when the minion first starts.
-config directory, calamari salt config are created and salt-minion package
-is installed. If the distro is Redhat/CentOS, the salt-minion service needs to
-be started.
-
-Usage::
-
-       ceph-deploy calamari {connect} [HOST] [HOST...]
-
-Here, [HOST] is the hostname where Calamari is to be installed.
-
-An option ``--release`` can be used to use a given release from repositories
-defined in :program:`ceph-deploy`'s configuration. Defaults to ``calamari-minion``.
-
-Another option :option:`--master` can also be used with this command.
-
 Options
 =======
 
@@ -540,10 +464,6 @@ Options
 
        Fetch packages and push them to hosts for a local repo mirror.
 
-.. option:: --master
-
-       The domain for the Calamari master server.
-
 .. option:: --mkfs
 
        Inject keys to MONs on remote nodes.
@@ -597,7 +517,7 @@ Availability
 ============
 
 :program:`ceph-deploy` is part of Ceph, a massively scalable, open-source, distributed storage system. Please refer to
-the documentation at http://ceph.com/ceph-deploy/docs for more information.
+the documentation at https://ceph.com/ceph-deploy/docs for more information.
 
 
 See also
@@ -605,5 +525,5 @@ See also
 
 :doc:`ceph-mon <ceph-mon>`\(8),
 :doc:`ceph-osd <ceph-osd>`\(8),
-:doc:`ceph-disk <ceph-disk>`\(8),
+:doc:`ceph-volume <ceph-volume>`\(8),
 :doc:`ceph-mds <ceph-mds>`\(8)