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 ...``.
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()``.