remove ceph code

This patch removes initial ceph code, due to license issue.

Change-Id: I092d44f601cdf34aed92300fe13214925563081c
Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com>

4 files changed, 0 insertions, 285 deletions

diff --git a/src/ceph/doc/ceph-volume/simple/activate.rst b/src/ceph/doc/ceph-volume/simple/activate.rst
deleted file mode 100644
index edbb1e3..0000000
--- a/src/ceph/doc/ceph-volume/simple/activate.rst
+++ /dev/null
@@ -1,80 +0,0 @@
-.. _ceph-volume-simple-activate:
-
-``activate``
-============
-Once :ref:`ceph-volume-simple-scan` has been completed, and all the metadata
-captured for an OSD has been persisted to ``/etc/ceph/osd/{id}-{uuid}.json``
-the OSD is now ready to get "activated".
-
-This activation process **disables** all ``ceph-disk`` systemd units by masking
-them, to prevent the UDEV/ceph-disk interaction that will attempt to start them
-up at boot time.
-
-The disabling of ``ceph-disk`` units is done only when calling ``ceph-volume
-simple activate`` directly, but is is avoided when being called by systemd when
-the system is booting up.
-
-The activation process requires using both the :term:`OSD id` and :term:`OSD uuid`
-To activate parsed OSDs::
-
-    ceph-volume simple activate 0 6cc43680-4f6e-4feb-92ff-9c7ba204120e
-
-The above command will assume that a JSON configuration will be found in::
-
-    /etc/ceph/osd/0-6cc43680-4f6e-4feb-92ff-9c7ba204120e.json
-
-Alternatively, using a path to a JSON file directly is also possible::
-
-    ceph-volume simple activate --file /etc/ceph/osd/0-6cc43680-4f6e-4feb-92ff-9c7ba204120e.json
-
-requiring uuids
-^^^^^^^^^^^^^^^
-The :term:`OSD uuid` is being required as an extra step to ensure that the
-right OSD is being activated. It is entirely possible that a previous OSD with
-the same id exists and would end up activating the incorrect one.
-
-
-Discovery
----------
-With OSDs previously scanned by ``ceph-volume``, a *discovery* process is
-performed using ``blkid`` and ``lvm``. There is currently support only for
-devices with GPT partitions and LVM logical volumes.
-
-The GPT partitions will have a ``PARTUUID`` that can be queried by calling out
-to ``blkid``, and the logical volumes will have a ``lv_uuid`` that can be
-queried against ``lvs`` (the LVM tool to list logical volumes).
-
-This discovery process ensures that devices can be correctly detected even if
-they are repurposed into another system or if their name changes (as in the
-case of non-persisting names like ``/dev/sda1``)
-
-The JSON configuration file used to map what devices go to what OSD will then
-coordinate the mounting and symlinking as part of activation.
-
-To ensure that the symlinks are always correct, if they exist in the OSD
-directory, the symlinks will be re-done.
-
-A systemd unit will capture the :term:`OSD id` and :term:`OSD uuid` and
-persist it. Internally, the activation will enable it like::
-
-    systemctl enable ceph-volume@simple-$id-$uuid
-
-For example::
-
-    systemctl enable ceph-volume@simple-0-8715BEB4-15C5-49DE-BA6F-401086EC7B41
-
-Would start the discovery process for the OSD with an id of ``0`` and a UUID of
-``8715BEB4-15C5-49DE-BA6F-401086EC7B41``.
-
-
-The systemd process will call out to activate passing the information needed to
-identify the OSD and its devices, and it will proceed to:
-
-# mount the device in the corresponding location (by convention this is
-  ``/var/lib/ceph/osd/<cluster name>-<osd id>/``)
-
-# ensure that all required devices are ready for that OSD and properly linked,
-regardless of objectstore used (filestore or bluestore). The symbolic link will
-**always** be re-done to ensure that the correct device is linked.
-
-# start the ``ceph-osd@0`` systemd unit
diff --git a/src/ceph/doc/ceph-volume/simple/index.rst b/src/ceph/doc/ceph-volume/simple/index.rst
deleted file mode 100644
index 6f2534a..0000000
--- a/src/ceph/doc/ceph-volume/simple/index.rst
+++ /dev/null
@@ -1,19 +0,0 @@
-.. _ceph-volume-simple:
-
-``simple``
-==========
-Implements the functionality needed to manage OSDs from the ``simple`` subcommand:
-``ceph-volume simple``
-
-**Command Line Subcommands**
-
-* :ref:`ceph-volume-simple-scan`
-
-* :ref:`ceph-volume-simple-activate`
-
-* :ref:`ceph-volume-simple-systemd`
-
-
-By *taking over* management, it disables all ``ceph-disk`` systemd units used
-to trigger devices at startup, relying on basic (customizable) JSON
-configuration and systemd for starting up OSDs.
diff --git a/src/ceph/doc/ceph-volume/simple/scan.rst b/src/ceph/doc/ceph-volume/simple/scan.rst
deleted file mode 100644
index afeddab..0000000
--- a/src/ceph/doc/ceph-volume/simple/scan.rst
+++ /dev/null
@@ -1,158 +0,0 @@
-.. _ceph-volume-simple-scan:
-
-``scan``
-========
-Scanning allows to capture any important details from an already-deployed OSD
-so that ``ceph-volume`` can manage it without the need of any other startup
-workflows or tools (like ``udev`` or ``ceph-disk``).
-
-The command has the ability to inspect a running OSD, by inspecting the
-directory where the OSD data is stored, or by consuming the data partition.
-
-Once scanned, information will (by default) persist the metadata as JSON in
-a file in ``/etc/ceph/osd``. This ``JSON`` file will use the naming convention
-of: ``{OSD ID}-{OSD FSID}.json``. An OSD with an id of 1, and an FSID like
-``86ebd829-1405-43d3-8fd6-4cbc9b6ecf96`` the absolute path of the file would
-be::
-
-    /etc/ceph/osd/1-86ebd829-1405-43d3-8fd6-4cbc9b6ecf96.json
-
-The ``scan`` subcommand will refuse to write to this file if it already exists.
-If overwriting the contents is needed, the ``--force`` flag must be used::
-
-    ceph-volume simple scan --force {path}
-
-If there is no need to persist the ``JSON`` metadata, there is support to send
-the contents to ``stdout`` (no file will be written)::
-
-    ceph-volume simple scan --stdout {path}
-
-
-.. _ceph-volume-simple-scan-directory:
-
-Directory scan
---------------
-The directory scan will capture OSD file contents from interesting files. There
-are a few files that must exist in order to have a successful scan:
-
-* ``ceph_fsid``
-* ``fsid``
-* ``keyring``
-* ``ready``
-* ``type``
-* ``whoami``
-
-In the case of any other file, as long as it is not a binary or a directory, it
-will also get captured and persisted as part of the JSON object.
-
-The convention for the keys in the JSON object is that any file name will be
-a key, and its contents will be its value. If the contents are a single line
-(like in the case of the ``whoami``) the contents are trimmed, and the newline
-is dropped. For example with an OSD with an id of 1, this is how the JSON entry
-would look like::
-
-    "whoami": "1",
-
-For files that may have more than one line, the contents are left as-is, for
-example, a ``keyring`` could look like this::
-
-    "keyring": "[osd.1]\n\tkey = AQBBJ/dZp57NIBAAtnuQS9WOS0hnLVe0rZnE6Q==\n",
-
-For a directory like ``/var/lib/ceph/osd/ceph-1``, the command could look
-like::
-
-    ceph-volume simple scan /var/lib/ceph/osd/ceph1
-
-
-.. note:: There is no support for encrypted OSDs
-
-
-.. _ceph-volume-simple-scan-device:
-
-Device scan
------------
-When an OSD directory is not available (OSD is not running, or device is not
-mounted) the ``scan`` command is able to introspect the device to capture
-required data. Just like :ref:`ceph-volume-simple-scan-directory`, it would
-still require a few files present. This means that the device to be scanned
-**must be** the data partition of the OSD.
-
-As long as the data partition of the OSD is being passed in as an argument, the
-sub-command can scan its contents.
-
-In the case where the device is already mounted, the tool can detect this
-scenario and capture file contents from that directory.
-
-If the device is not mounted, a temporary directory will be created, and the
-device will be mounted temporarily just for scanning the contents. Once
-contents are scanned, the device will be unmounted.
-
-For a device like ``/dev/sda1`` which **must** be a data partition, the command
-could look like::
-
-    ceph-volume simple scan /dev/sda1
-
-
-.. note:: There is no support for encrypted OSDs
-
-
-.. _ceph-volume-simple-scan-json:
-
-``JSON`` contents
------------------
-The contents of the JSON object is very simple. The scan not only will persist
-information from the special OSD files and their contents, but will also
-validate paths and device UUIDs. Unlike what ``ceph-disk`` would do, by storing
-them in ``{device type}_uuid`` files, the tool will persist them as part of the
-device type key.
-
-For example, a ``block.db`` device would look something like::
-
-    "block.db": {
-        "path": "/dev/disk/by-partuuid/6cc43680-4f6e-4feb-92ff-9c7ba204120e",
-        "uuid": "6cc43680-4f6e-4feb-92ff-9c7ba204120e"
-    },
-
-But it will also persist the ``ceph-disk`` special file generated, like so::
-
-    "block.db_uuid": "6cc43680-4f6e-4feb-92ff-9c7ba204120e",
-
-This duplication is in place because the tool is trying to ensure the
-following:
-
-# Support OSDs that may not have ceph-disk special files
-# Check the most up-to-date information on the device, by querying against LVM
-and ``blkid``
-# Support both logical volumes and GPT devices
-
-This is a sample ``JSON`` metadata, from an OSD that is using ``bluestore``::
-
-    {
-        "active": "ok",
-        "block": {
-            "path": "/dev/disk/by-partuuid/40fd0a64-caa5-43a3-9717-1836ac661a12",
-            "uuid": "40fd0a64-caa5-43a3-9717-1836ac661a12"
-        },
-        "block.db": {
-            "path": "/dev/disk/by-partuuid/6cc43680-4f6e-4feb-92ff-9c7ba204120e",
-            "uuid": "6cc43680-4f6e-4feb-92ff-9c7ba204120e"
-        },
-        "block.db_uuid": "6cc43680-4f6e-4feb-92ff-9c7ba204120e",
-        "block_uuid": "40fd0a64-caa5-43a3-9717-1836ac661a12",
-        "bluefs": "1",
-        "ceph_fsid": "c92fc9eb-0610-4363-aafc-81ddf70aaf1b",
-        "cluster_name": "ceph",
-        "data": {
-            "path": "/dev/sdr1",
-            "uuid": "86ebd829-1405-43d3-8fd6-4cbc9b6ecf96"
-        },
-        "fsid": "86ebd829-1405-43d3-8fd6-4cbc9b6ecf96",
-        "keyring": "[osd.3]\n\tkey = AQBBJ/dZp57NIBAAtnuQS9WOS0hnLVe0rZnE6Q==\n",
-        "kv_backend": "rocksdb",
-        "magic": "ceph osd volume v026",
-        "mkfs_done": "yes",
-        "ready": "ready",
-        "systemd": "",
-        "type": "bluestore",
-        "whoami": "3"
-    }
diff --git a/src/ceph/doc/ceph-volume/simple/systemd.rst b/src/ceph/doc/ceph-volume/simple/systemd.rst
deleted file mode 100644
index aa5bebf..0000000
--- a/src/ceph/doc/ceph-volume/simple/systemd.rst
+++ /dev/null
@@ -1,28 +0,0 @@
-.. _ceph-volume-simple-systemd:
-
-systemd
-=======
-Upon startup, it will identify the logical volume by loading the JSON file in
-``/etc/ceph/osd/{id}-{uuid}.json`` corresponding to the instance name of the
-systemd unit.
-
-After identifying the correct volume it will then proceed to mount it by using
-the OSD destination conventions, that is::
-
-    /var/lib/ceph/osd/{cluster name}-{osd id}
-
-For our example OSD with an id of ``0``, that means the identified device will
-be mounted at::
-
-
-    /var/lib/ceph/osd/ceph-0
-
-
-Once that process is complete, a call will be made to start the OSD::
-
-    systemctl start ceph-osd@0
-
-The systemd portion of this process is handled by the ``ceph-volume simple
-trigger`` sub-command, which is only in charge of parsing metadata coming from
-systemd and startup, and then dispatching to ``ceph-volume simple activate`` which
-would proceed with activation.