From: Sebastian Wagner Date: Fri, 21 Feb 2020 17:15:14 +0000 (+0100) Subject: doc/orchestrator: Substitute `host` for `node` X-Git-Tag: v15.1.1~294^2 X-Git-Url: http://git-server-git.apps.pok.os.sepia.ceph.com/?a=commitdiff_plain;h=163be4e0afdf58d00c011050a84a820e98d353d9;p=ceph.git doc/orchestrator: Substitute `host` for `node` Signed-off-by: Sebastian Wagner --- diff --git a/doc/mgr/cephadm.rst b/doc/mgr/cephadm.rst index 739d79996806..d90a1ae08331 100644 --- a/doc/mgr/cephadm.rst +++ b/doc/mgr/cephadm.rst @@ -5,7 +5,7 @@ cephadm orchestrator ==================== The cephadm orchestrator is an orchestrator module that does not rely on a separate -system such as Rook or Ansible, but rather manages nodes in a cluster by +system such as Rook or Ansible, but rather manages hosts in a cluster by establishing an SSH connection and issuing explicit management commands. Orchestrator modules only provide services to other modules, which in turn diff --git a/doc/mgr/orchestrator.rst b/doc/mgr/orchestrator.rst index 3498badb5e36..f239b50078c5 100644 --- a/doc/mgr/orchestrator.rst +++ b/doc/mgr/orchestrator.rst @@ -115,8 +115,8 @@ OSD Management List Devices ^^^^^^^^^^^^ -Print a list of discovered devices, grouped by node and optionally -filtered to a particular node: +Print a list of discovered devices, grouped by host and optionally +filtered to a particular host: :: @@ -211,13 +211,13 @@ Monitor and manager management Creates or removes MONs or MGRs from the cluster. Orchestrator may return an error if it doesn't know how to do this transition. -Update the number of monitor nodes:: +Update the number of monitor hosts:: ceph orch apply mon [host, host:network...] Each host can optionally specify a network for the monitor to listen on. -Update the number of manager nodes:: +Update the number of manager hosts:: ceph orch apply mgr [host...] diff --git a/doc/mgr/orchestrator_modules.rst b/doc/mgr/orchestrator_modules.rst index deff5aaa32ca..43160708a3cb 100644 --- a/doc/mgr/orchestrator_modules.rst +++ b/doc/mgr/orchestrator_modules.rst @@ -72,9 +72,9 @@ Stateless service Label arbitrary string tags that may be applied by administrators - to nodes. Typically administrators use labels to indicate - which nodes should run which kinds of service. Labels are - advisory (from human input) and do not guarantee that nodes + to hosts. Typically administrators use labels to indicate + which hosts should run which kinds of service. Labels are + advisory (from human input) and do not guarantee that hosts have particular physical capabilities. Drive group @@ -83,20 +83,20 @@ Drive group journals/dbs for a group of HDDs). Placement - choice of which node is used to run a service. + choice of which host is used to run a service. Key Concepts ------------ The underlying orchestrator remains the source of truth for information about whether a service is running, what is running where, which -nodes are available, etc. Orchestrator modules should avoid taking +hosts are available, etc. Orchestrator modules should avoid taking any internal copies of this information, and read it directly from the orchestrator backend as much as possible. -Bootstrapping nodes and adding them to the underlying orchestration +Bootstrapping hosts and adding them to the underlying orchestration system is outside the scope of Ceph's orchestrator interface. Ceph -can only work on nodes when the orchestrator is already aware of them. +can only work on hosts when the orchestrator is already aware of them. Calls to orchestrator modules are all asynchronous, and return *completion* objects (see below) rather than returning values immediately. @@ -207,7 +207,7 @@ Excluded functionality the Ceph cluster's services only. - Multipathed storage is not handled (multipathing is unnecessary for Ceph clusters). Each drive is assumed to be visible only on - a single node. + a single host. Host management ---------------