openstack/openstack-manuals
Code Issues Proposed changes

change to module001-ch008-queues-messaging

Browse Source 
changed rpc worker and rpc cast sentence
changed reply to plural
paces around "and"
removed "we"
revised sentence
added space "using <command>"
added a space before A
added space and capitals after </emphasis>

Change-Id: I3f9d5fb147aaacd42e5790aa751547e5821482a7
This commit is contained in:
Shilla Saebi 2014-03-14 01:48:54 -04:00 committed by shillasaebi
parent eaee19793c
commit 0f0fd7299d
1 changed files with 34 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

62
doc/training-guides/module001-ch008-queues-messaging.xml
View File

@ -64,21 +64,21 @@
<para><guilabel>Nova RPC Mappings</guilabel></para>
<para>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 Nova
component connects to the message broker and, depending on its
instance is deployed and shared in an OpenStack cloud. Every component
within Nova connects to the message broker and, depending on its
personality, such as 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 or Network). Invokers and Workers do not
actually exist in the Nova 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
actually exist in the Nova object model, but in this example they are used
as an abstraction for the sake of clarity. An Invoker is a
component that sends messages in the queuing system using <command>rpc.call
</command> and <command>rpc.cast</command>. A worker is a component
that receives messages from the queuing system and replies
accordingly to rcp.call operations.</para>
<para>Figure 2 shows the following internal elements:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Topic Publisher:</emphasis>a Topic
<para><emphasis role="bold">Topic Publisher:</emphasis> A Topic
Publisher comes to life when an rpc.call or an rpc.cast
operation is executed; this object is instantiated and used to
push a message to the queuing system. Every publisher connects
@ -86,7 +86,7 @@
limited to the message delivery.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Direct Consumer:</emphasis>a Direct
<para><emphasis role="bold">Direct Consumer:</emphasis> A Direct
Consumer comes to life if (an only if) a rpc.call operation is
executed; this object is instantiated and used to receive a
response message from the queuing system; Every consumer
@ -97,7 +97,7 @@
Topic Publisher (only rpc.call operations).</para>
</listitem>
<listitem>
<para><emphasis role="bold">Topic Consumer:</emphasis>a Topic
<para><emphasis role="bold">Topic Consumer:</emphasis> A Topic
Consumer comes to life as soon as a Worker is instantiated and
exists throughout its life-cycle; this object is used to
receive messages from the queue and it invokes the appropriate
@ -111,7 +111,7 @@
exchange key is ‘topic.host’).</para>
</listitem>
<listitem>
<para><emphasis role="bold">Direct Publisher:</emphasis>a Direct
<para><emphasis role="bold">Direct Publisher:</emphasis> A Direct
Publisher comes to life only during rpc.call operations and it
is instantiated to return the message required by the
request/response operation. The object connects to a
@ -127,7 +127,7 @@
topic-based exchange for every topic in Nova.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Direct Exchange:</emphasis>this is a
<para><emphasis role="bold">Direct Exchange:</emphasis> This is a
routing table that is created during rpc.call operations;
there are many instances of this kind of exchange throughout
the life-cycle of a message broker node, one for each rpc.call
@ -302,56 +302,56 @@
<para>The following parameters are default:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Insist:</emphasis> insist on
<para><emphasis role="bold">Insist:</emphasis> Insist on
connecting to a server. In a configuration with multiple
load-sharing servers, the Insist option tells the server that
the client is insisting on a connection to the specified
server. Default is False.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Connect_timeout:</emphasis> the
<para><emphasis role="bold">Connect_timeout:</emphasis> The
timeout in seconds before the client gives up connecting to
the server. The default is no timeout.</para>
</listitem>
<listitem>
<para><emphasis role="bold">SSL:</emphasis> use SSL to connect
<para><emphasis role="bold">SSL:</emphasis> Use SSL to connect
to the server. The default is False.</para>
</listitem>
</itemizedlist>
<para>More precisely consumers need the following parameters:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Connection:</emphasis> the above
<para><emphasis role="bold">Connection:</emphasis> The above
mentioned Connection object.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Queue:</emphasis>name of the
<para><emphasis role="bold">Queue:</emphasis> Name of the
queue.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Exchange:</emphasis>name of the
<para><emphasis role="bold">Exchange:</emphasis> Name of the
exchange the queue binds to.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Routing_key:</emphasis>the
<para><emphasis role="bold">Routing_key:</emphasis> The
interpretation of the routing key depends on the value of the
exchange_type attribute.</para>
</listitem>
</itemizedlist>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Direct exchange:</emphasis>if the
<para><emphasis role="bold">Direct exchange:</emphasis> If the
routing key property of the message and the routing_key
attribute of the queue are identical, then the message is
forwarded to the queue.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Fanout exchange:</emphasis>messages
<para><emphasis role="bold">Fanout exchange:</emphasis> Messages
are forwarded to the queues bound the exchange, even if the
binding does not have a key.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Topic exchange:</emphasis>if the
<para><emphasis role="bold">Topic exchange:</emphasis> If the
routing key property of the message matches the routing key of
the key according to a primitive pattern matching scheme, then
the message is forwarded to the queue. The message routing key
@ -365,7 +365,7 @@
</itemizedlist>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Durable:</emphasis>this flag
<para><emphasis role="bold">Durable:</emphasis> This flag
determines the durability of both exchanges and queues;
durable exchanges and queues remain active when a RabbitMQ
server restarts. Non-durable exchanges/queues (transient
@ -374,12 +374,12 @@
bind to transient exchanges. Default is True.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Auto_delete:</emphasis>if set, the
<para><emphasis role="bold">Auto_delete:</emphasis> If set, the
exchange is deleted when all queues have finished using it.
Default is False.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Exclusive:</emphasis>exclusive
<para><emphasis role="bold">Exclusive:</emphasis> Exclusive
queues (such as non-shared) may only be consumed from by the
current connection. When exclusive is on, this also implies
auto_delete. Default is False.</para>
@ -390,13 +390,13 @@
that covers most of the common messaging use cases.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Auto_ack:</emphasis>acknowledgement
<para><emphasis role="bold">Auto_ack:</emphasis> Acknowledgement
is handled automatically once messages are received. By
default auto_ack is set to False, and the receiver is required
to manually handle acknowledgment.</para>
</listitem>
<listitem>
<para><emphasis role="bold">No_ack:</emphasis>it disable
<para><emphasis role="bold">No_ack:</emphasis> It disables
acknowledgement on the server-side. This is different from
auto_ack in that acknowledgement is turned off altogether.
This functionality increases performance but at the cost of
@ -404,7 +404,7 @@
can deliver them to the application.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Auto_declare:</emphasis>if this is
<para><emphasis role="bold">Auto_declare:</emphasis> If this is
True and the exchange name is set, the exchange will be
automatically declared at instantiation. Auto declare is on by
default. Publishers specify most the parameters of consumers
@ -412,19 +412,19 @@
specify the following:</para>
</listitem>
<listitem>
<para><emphasis role="bold">Delivery_mode:</emphasis>the default
<para><emphasis role="bold">Delivery_mode:</emphasis> The default
delivery mode used for messages. The value is an integer. The
following delivery modes are supported by RabbitMQ:</para>
</listitem>
</itemizedlist>
<itemizedlist>
<listitem>
<para><emphasis role="bold">1 or “transient”:</emphasis>the
<para><emphasis role="bold">1 or “transient”:</emphasis> The
message is transient. Which means it is stored in memory only,
and is lost if the server dies or restarts.</para>
</listitem>
<listitem>
<para><emphasis role="bold">2 or “persistent”:</emphasis>the
<para><emphasis role="bold">2 or “persistent”:</emphasis> The
message is persistent. Which means the message is stored both
in-memory, and on disk, and therefore preserved if the server
dies or restarts.</para>