Merge pull request #35717 from dmick/wip-cephadm-doc

doc/dev/cephadm.rst: clarify, fix spelling nits
This commit is contained in:
Dan Mick 2020-07-11 00:13:06 -07:00 committed by GitHub
commit 832ed27afa
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View 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.
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 only do very few calls to remote hosts synchronously.
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()``.