From b7b7fc4099da5f4bc2d4614cc1b95a1668cb6faa Mon Sep 17 00:00:00 2001 From: yatin karel Date: Sun, 16 Nov 2014 18:07:36 +0530 Subject: [PATCH] Documentation Bug fix committed I have corrected the spelling mistakes, that were described in the bug. Change-Id: I53371b9a70651078bf051d6bc384d1107724d39b Closes-Bug: #1393133 --- doc/source/devref/rpc.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/source/devref/rpc.rst b/doc/source/devref/rpc.rst index 7ac823fcb..cb7e4a292 100644 --- a/doc/source/devref/rpc.rst +++ b/doc/source/devref/rpc.rst @@ -35,7 +35,7 @@ Cinder implements RPC (both request+response, and one-way, respectively nickname Cinder RPC Mappings ------------------- -The figure below shows the internals of a message broker node (referred to as a RabbitMQ node in the diagrams) when a single instance is deployed and shared in an OpenStack cloud. Every Cinder component connects to the message broker and, depending on its personality (for example a compute node or a network node), may use the queue either as an Invoker (such as API or Scheduler) or a Worker (such as Compute, Volume or Network). Invokers and Workers do not actually exist in the Cinder object model, but we are going to use them as an abstraction for sake of clarity. An Invoker is a component that sends messages in the queuing system via two operations: 1) rpc.call and ii) rpc.cast; a Worker is a component that receives messages from the queuing system and reply accordingly to rcp.call operations. +The figure below shows the internals of a message broker node (referred to as a RabbitMQ node in the diagrams) when a single instance is deployed and shared in an OpenStack cloud. Every Cinder component connects to the message broker and, depending on its personality (for example a compute node or a network node), may use the queue either as an Invoker (such as API or Scheduler) or a Worker (such as Compute, Volume or Network). Invokers and Workers do not actually exist in the Cinder object model, but we are going to use them as an abstraction for sake of clarity. An Invoker is a component that sends messages in the queuing system via two operations: 1) rpc.call and ii) rpc.cast; a Worker is a component that receives messages from the queuing system and reply accordingly to rpc.call operations. Figure 2 shows the following internal elements: @@ -55,7 +55,7 @@ Figure 2 shows the following internal elements: RPC Calls --------- -The diagram below shows the message flow during an rp.call operation: +The diagram below shows the message flow during an rpc.call operation: 1. a Topic Publisher is instantiated to send the message request to the queuing system; immediately before the publishing operation, a Direct Consumer is instantiated to wait for the response message. 2. once the message is dispatched by the exchange, it is fetched by the Topic Consumer dictated by the routing key (such as 'topic.host') and passed to the Worker in charge of the task. @@ -70,7 +70,7 @@ The diagram below shows the message flow during an rp.call operation: RPC Casts --------- -The diagram below the message flow during an rp.cast operation: +The diagram below the message flow during an rpc.cast operation: 1. A Topic Publisher is instantiated to send the message request to the queuing system. 2. Once the message is dispatched by the exchange, it is fetched by the Topic Consumer dictated by the routing key (such as 'topic') and passed to the Worker in charge of the task. -- 2.45.2