new

Usage:

ceph-deploy new [MON][MON...]

Here, [MON] is the initial monitor hostname (short hostname i.e, hostname -s).

Other options like --no-ssh-copykey, --fsid, --cluster-network and --public-network can also be used with this command.

If more than one network interface is used, public network setting has to be added under [global] section of Ceph configuration file. If the public subnet is given, new command will choose the one IP from the remote host that exists within the subnet range. Public network can also be added at runtime using --public-network option with the command as mentioned above.

install

If the user explicitly specifies a custom repo url with --repo-url for installation, anything detected from the configuration will be overridden and the custom repository location will be used for installation of Ceph packages. If required, valid custom repositories are also detected and installed. In case of installation from a custom repo a boolean is used to determine the logic needed to proceed with a custom repo installation. A custom repo install helper is used that goes through config checks to retrieve repos (and any extra repos defined) and installs them. cd_conf is the object built from argparse that holds the flags and information needed to determine what metadata from the configuration is to be used.

A user can also opt to install only the repository without installing Ceph and its dependencies by using --repo option.

Usage:

ceph-deploy install [HOST][HOST...]

Here, [HOST] is/are the host node(s) where Ceph is to be installed.

An option --release is used to install a release known as CODENAME (default: firefly).

Other options like --testing, --dev, --adjust-repos, --no-adjust-repos, --repo, --local-mirror, --repo-url and --gpg-url can also be used with this command.

mds

Usage:

ceph-deploy mds create [HOST[:DAEMON-NAME]] [HOST[:DAEMON-NAME]...]

The [DAEMON-NAME] is optional.

mon

Subcommand create-initial deploys for monitors defined in mon initial members under [global] section in Ceph configuration file, wait until they form quorum and then gatherkeys, reporting the monitor status along the process. If monitors don't form quorum the command will eventually time out.

Usage:

ceph-deploy mon create-initial

Subcommand create is used to deploy Ceph monitors by explicitly specifying the hosts which are desired to be made monitors. If no hosts are specified it will default to use the mon initial members defined under [global] section of Ceph configuration file. create first detects platform and distro for desired hosts and checks if hostname is compatible for deployment. It then uses the monitor keyring initially created using new command and deploys the monitor in desired host. If multiple hosts were specified during new command i.e, if there are multiple hosts in mon initial members and multiple keyrings were created then a concatenated keyring is used for deployment of monitors. In this process a keyring parser is used which looks for [entity] sections in monitor keyrings and returns a list of those sections. A helper is then used to collect all keyrings into a single blob that will be used to inject it to monitors with --mkfs on remote nodes. All keyring files are concatenated to be in a directory ending with .keyring. During this process the helper uses list of sections returned by keyring parser to check if an entity is already present in a keyring and if not, adds it. The concatenated keyring is used for deployment of monitors to desired multiple hosts.

Usage:

ceph-deploy mon create [HOST] [HOST...]

Here, [HOST] is hostname of desired monitor host(s).

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 monitor address that will be used, otherwise it will fallback by resolving the hostname to an IP. If --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 errors arise if the monitor is not added in mon initial members, if it doesn't exist in monmap and if neither public_addr nor public_network keys were defined for monitors. Under such conditions, monitors may not be able to form quorum. Monitor status tells if the monitor is up and running normally. The status is checked by running ceph daemon mon.hostname mon_status on remote end which provides the output and returns a boolean status of what is going on. False means a monitor that is not fine even if it is up and running, while True means the monitor is up and running correctly.

Usage:

ceph-deploy mon add [HOST]
ceph-deploy mon add [HOST] --address [IP]

Here, [HOST] is the hostname and [IP] is the IP address of the desired monitor node. Please note, unlike other mon subcommands, only one node can be specified at a time.

Subcommand destroy is used to completely remove monitors on remote hosts. It takes hostnames as arguments. It stops the monitor, verifies if ceph-mon daemon really stopped, creates an archive directory mon-remove under /var/lib/ceph/, archives old monitor directory in {cluster}-{hostname}-{stamp} format in it and removes the monitor from cluster by running ceph remove... command.

Usage:

ceph-deploy mon destroy [HOST] [HOST...]

Here, [HOST] is hostname of monitor that is to be removed.

gatherkeys

Usage:

ceph-deploy gatherkeys [HOST] [HOST...]

Here, [HOST] is hostname of the monitor from where keys are to be pulled.

disk

Subcommand list lists disk partitions and Ceph OSDs.

Usage:

ceph-deploy disk list HOST

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

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 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.

Bluestore Usage:

ceph-deploy osd create --data DISK HOST

Filestore Usage:

ceph-deploy osd create --data DISK --journal JOURNAL HOST

NOTE:

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

admin

Usage:

ceph-deploy admin [HOST] [HOST...]

Here, [HOST] is desired host to be configured for Ceph administration.

config

Usage:

ceph-deploy config push [HOST] [HOST...]
ceph-deploy config pull [HOST] [HOST...]

Here, [HOST] is the hostname of the node where config file will be pushed to or pulled from.

uninstall

Usage:

ceph-deploy uninstall [HOST] [HOST...]

Here, [HOST] is hostname of the node from where Ceph will be uninstalled.

purge

Usage:

ceph-deploy purge [HOST] [HOST...]

Here, [HOST] is hostname of the node from where Ceph will be purged.

purgedata

Usage:

ceph-deploy purgedata [HOST] [HOST...]

Here, [HOST] is hostname of the node from where Ceph data will be purged.

forgetkeys

Usage:

ceph-deploy forgetkeys

pkg

Usage:

ceph-deploy pkg --install [PKGs] [HOST] [HOST...]
ceph-deploy pkg --remove [PKGs] [HOST] [HOST...]

Here, [PKGs] is comma-separated package names and [HOST] is hostname of the remote node where packages are to be installed or removed from.