]> git.proxmox.com Git - ceph.git/blobdiff - ceph/doc/dev/cephadm.rst
import 15.2.5
[ceph.git] / ceph / doc / dev / cephadm.rst
index 1784de422968b69c02c0cfef0baf2b8b7f9ab234..4cd811f781220b8dba3b0eac4b1361c215ae7fbc 100644 (file)
@@ -25,11 +25,12 @@ cephadm/cephadm script into memory.)
    MON=1 MGR=1 OSD=0 MDS=0 ../src/vstart.sh -d -n -x --cephadm
 
 - ``~/.ssh/id_dsa[.pub]`` is used as the cluster key.  It is assumed that
-  this key is authorized to ssh to root@`hostname`.
-- No service spec is defined for mon or mgr, which means that cephadm
-  does not try to manage them.
+  this key is authorized to ssh with no passphrase to root@`hostname`.
+- cephadm does not try to manage any daemons started by vstart.sh (any
+  nonzero number in the environment variables).  No service spec is defined
+  for mon or mgr.
 - You'll see health warnings from cephadm about stray daemons--that's because
-  the vstart-launched mon and mgr aren't controlled by cephadm.
+  the vstart-launched daemons aren't controlled by cephadm.
 - The default image is ``quay.io/ceph-ci/ceph:master``, but you can change
   this by passing ``-o container_image=...`` or ``ceph config set global container_image ...``.
 
@@ -89,14 +90,15 @@ When you're done, you can tear down the cluster with::
 Note regarding network calls from CLI handlers
 ==============================================
 
-Executing any cephadm CLI commands like ``ceph orch ls`` will block
-the mon command handler thread within the MGR, thus preventing any
-concurrent CLI calls. Note that pressing ``^C`` will not resolve this
-situation, as *only* the client will be aborted, but not exceution
-itself. This means, cephadm will be completely unresonsive, until the
-execution of the CLI handler is fully completed. Note that even
-``ceph orch ps`` will not respond, while another handler is executed.
-
-This means, we should only do very few calls to remote hosts synchronously. 
-As a guideline, cephadm should do at most ``O(1)`` network calls in CLI handlers. 
+Executing any cephadm CLI commands like ``ceph orch ls`` will block the
+mon command handler thread within the MGR, thus preventing any concurrent
+CLI calls. Note that pressing ``^C`` will not resolve this situation,
+as *only* the client will be aborted, but not execution of the command
+within the orchestrator manager module itself. This means, cephadm will
+be completely unresponsive until the execution of the CLI handler is
+fully completed. Note that even ``ceph orch ps`` will not respond while
+another handler is executing.
+
+This means we should do very few synchronous calls to remote hosts.
+As a guideline, cephadm should do at most ``O(1)`` network calls in CLI handlers.
 Everything else should be done asynchronously in other threads, like ``serve()``.