This is the mail archive of the cluster-cvs@sourceware.org mailing list for the cluster.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

cluster: STABLE3 - cman: Change openais references to corosync in manpages.


Gitweb:        http://git.fedorahosted.org/git/cluster.git?p=cluster.git;a=commitdiff;h=c98f3fb5b1be9755f07b3358d1a3174a9577f326
Commit:        c98f3fb5b1be9755f07b3358d1a3174a9577f326
Parent:        29dc34349cf0952234db11e1b702b850af900bde
Author:        Christine Caulfield <ccaulfie@redhat.com>
AuthorDate:    Thu Mar 26 08:16:23 2009 +0000
Committer:     Christine Caulfield <ccaulfie@redhat.com>
CommitterDate: Thu Mar 26 08:16:23 2009 +0000

cman: Change openais references to corosync in man pages.

Also change the logging example as that has changed too.

Signed-off-by: Christine Caulfield <ccaulfie@redhat.com>
---
 cman/man/cman.5      |   34 +++++++++++++++++-----------------
 cman/man/cman_tool.8 |   20 ++++++++++----------
 2 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/cman/man/cman.5 b/cman/man/cman.5
index d36f484..9077ceb 100644
--- a/cman/man/cman.5
+++ b/cman/man/cman.5
@@ -93,14 +93,14 @@ the nodeid to one that is already used.
 .in +7
 It is quite common to use multiple ethernet adapters for cluster nodes, so
 they will tolerate the failure of one link. A common way to do this is to use
-ethernet bonding. Alternatively you can get openais to run in redundant ring
+ethernet bonding. Alternatively you can get corosync to run in redundant ring
 mode by specifying an 'altname' for the node. This is an alternative name by
 which the node is known, that resolves to another IP address used on the 
 other ethernet adapter(s). You can optionally specify a different port and/or 
 multicast address for each altname in use. Up to 9 altnames (10 interfaces 
 in total) can be used.
 
-Note that if you are using the DLM with cman/openais then you MUST tell it 
+Note that if you are using the DLM with cman/corosync then you MUST tell it 
 to use SCTP as it's communications protocol as TCP does not support multihoming.
 
   <clusternode name="nd1" nodeid="1"> 
@@ -141,15 +141,15 @@ you feel the need. Sometimes cluster names can hash to the same ID.
 
 .in -7
 
-\fIopenais security key\fR
+\fIcorosync security key\fR
 .in +7
-All traffic sent out by cman/openais is encrypted. By default the security key 
+All traffic sent out by cman/corosync is encrypted. By default the security key 
 used is simply the cluster name. If you need more security you can specify a
 key file that contains the key used to encrypt cluster communications.
 Of course, the contents of the key file must be the same on all nodes in the
 cluster. It is up to you to securely copy the file to the nodes.
 
-  <cman keyfile="/etc/openais.key">
+  <cman keyfile="/etc/cluster/corosync.key">
   </cman>
 
 Note that this only applies to cluster communication. The DLM does not encrypt 
@@ -157,13 +157,13 @@ traffic.
 .in -7
 
 
-\fIOther openais parameters\fR
+\fIOther corosync parameters\fR
 .in +7
-When openais is started by cman (cman_tool runs aisexec), the openais.conf
+When corosync is started by cman (cman_tool runs aisexec), the corosync.conf
 file is not used.  Many of the configuration parameters listed in
-openais.conf can be set in cluster.conf (CCS) instead.  Cman will read
-openais parameters from the following sections in cluster.conf and load
-them into openais:
+corosync.conf can be set in cluster.conf (CCS) instead.  Cman will read
+corosync parameters from the following sections in cluster.conf and load
+them into corosync:
 
   <cluster>
     <totem />
@@ -174,15 +174,15 @@ them into openais:
   </cluster>
 
 See the 
-.B openais.conf(5)
+.B corosync.conf(5)
 man page for more information on keys that are valid for these sections.
 Note that settings in the <clusternodes> section will override settings in
 the sections above, and options on the cman_tool command line will
 override both.  In particular, settings like bindnetaddr, mcastaddr,
 mcastport and nodeid will always be replaced by values in <clusternodes>.
 
-Cman uses different defaults for some of the openais parameters listed in
-openais.conf(5).  If you wish to use a non-default setting, they can be
+Cman uses different defaults for some of the corosync parameters listed in
+corosync.conf(5).  If you wish to use a non-default setting, they can be
 configured in cluster.conf as shown above.  Cman uses the following
 default values:
 
@@ -202,12 +202,12 @@ Here's how to set the token timeout to five seconds:
 
   <totem token="5000"/>
 
-And this is how to add extra openais logging options to CMAN and CPG:
+And this is how to add extra corosync logging options to CMAN and CPG:
 
   <logging to_stderr="yes">
-    <logger ident="CPG" debug="on" to_stderr="yes">
+    <logger_subsys subsys="CPG" debug="on">
     </logger>
-    <logger ident="CMAN" debug="on" to_stderr="yes">
+    <logger_subsys subsys="CMAN" debug="on">
     </logger>
   </logging>
 
@@ -218,5 +218,5 @@ And this is how to add extra openais logging options to CMAN and CPG:
 
 .SH "SEE ALSO"
 
-cluster.conf(5), openais.conf(5), ccs(7), cman_tool(8)
+cluster.conf(5), corosync.conf(5), ccs(7), cman_tool(8)
 
diff --git a/cman/man/cman_tool.8 b/cman/man/cman_tool.8
index 46a78d8..914e709 100644
--- a/cman/man/cman_tool.8
+++ b/cman/man/cman_tool.8
@@ -237,7 +237,7 @@ command without -w followed by
 .B cman_tool wait.
 .TP
 .I -k <keyfile>
-All traffic sent out by cman/openais is encrypted. By default the security key 
+All traffic sent out by cman/corosync is encrypted. By default the security key 
 used is simply the cluster name. If you need more security you can specify a
 key file that contains the key used to encrypt cluster communications.
 Of course, the contents of the key file must be the same on all nodes in the
@@ -319,7 +319,7 @@ The value is a bitmask of
 .br
 8 Daemon operation, including command-line interaction
 .br
-16 Interaction with OpenAIS
+16 Interaction with Corosync
 .br
 32 Startup debugging (cman_tool join operations only)
 .br
@@ -336,20 +336,20 @@ X	The node is not a member of the cluster
 d	The node is known to the cluster but disallowed access to it.
 .br
 .SH ENVIRONMENT VARIABLES
-cman_tool removes most environment variables before forking and running OpenAIS, as well as adding some of its own for setting up
+cman_tool removes most environment variables before forking and running Corosync, as well as adding some of its own for setting up
 configuration parameters that were overridden on the command-line, the exception to this is that variable with names starting
 COROSYNC_ will be passed down intact as they are assumed to be used for configuring the daemon. 
 
 .SH DISALLOWED NODES
-Occasionally (but very infrequently I hope) you may see nodes marked as "Disallowed" in cman_tool status or "d" in cman_tool nodes.  This is a bit of a nasty hack to get around mismatch between what the upper layers expect of the cluster manager and OpenAIS.
+Occasionally (but very infrequently I hope) you may see nodes marked as "Disallowed" in cman_tool status or "d" in cman_tool nodes.  This is a bit of a nasty hack to get around mismatch between what the upper layers expect of the cluster manager and corosync.
 .TP
-If a node experiences a momentary lack of connectivity, but one that is long enough to trigger the token timeouts, then it will be removed from the cluster. When connectivity is restored OpenAIS will happily let it rejoin the cluster with no fuss. Sadly the upper layers don't like this very much. They may (indeed probably will have) have changed their internal state while the other node was away and there is no straightforward way to bring the rejoined node up-to-date with that state. When this happens the node is marked "Disallowed" and is not permitted to take part in cman operations.  
+If a node experiences a momentary lack of connectivity, but one that is long enough to trigger the token timeouts, then it will be removed from the cluster. When connectivity is restored corosync will happily let it rejoin the cluster with no fuss. Sadly the upper layers don't like this very much. They may (indeed probably will have) have changed their internal state while the other node was away and there is no straightforward way to bring the rejoined node up-to-date with that state. When this happens the node is marked "Disallowed" and is not permitted to take part in cman operations.  
 .P
 If the remainder of the cluster is quorate the the node will be sent a kill message and it will be forced to leave the cluster that way. Note that fencing should kick in to remove the node permanently anyway, but it may take longer than the network outage for this to complete.
 
 If the remainder of the cluster is inquorate then we have a problem. The likelihood is that we will have two (or more) partitioned clusters and we cannot decide which is the "right" one. In this case we need to defer to the system administrator to kill an appropriate selection of nodes to restore the cluster to sensible operation.
 
-The latter scenario should be very rare and may indicate a bug somewhere in the code. If the local network is very flaky or busy it may be necessary to increase some of the protocol timeouts for OpenAIS. We are trying to think of better solutions to this problem.
+The latter scenario should be very rare and may indicate a bug somewhere in the code. If the local network is very flaky or busy it may be necessary to increase some of the protocol timeouts for corosync. We are trying to think of better solutions to this problem.
 
 Recovering from this state can, unfortunately, be complicated. Fortunately, in the majority of cases, fencing will do the job for you, and the disallowed state will only be temporary. If it persists, the recommended approach it is to do a cman tool nodes on all systems in the cluster and determine the largest common subset of nodes that are valid members to each other. Then reboot the others and let them rejoin correctly. In the case of a single-node disconnection this should be straightforward, with a large cluster that has experienced a network partition it could get very complicated!
 
@@ -398,11 +398,11 @@ In this scenario we should kill the node node-02 and node-03. Of course, the 3 n
 This section details how the configuration systems work in cman. You might need to know this if you are using the -C option
 to cman_tool, or writing your own configuration subsystem.
 .br
-By default cman uses two configuration plugins to OpenAIS. The first, 'ccsconfig', reads the configuration information
+By default cman uses two configuration plugins to corosync. The first, 'ccsconfig', reads the configuration information
 stored in cluster.conf and stores it in an internal database, in the same schema as it finds in cluster.conf. 
 The second plugin, 'cmanpreconfig', takes the information in that the database, adds several cman defaults, determines 
-the OpenAIS node name and nodeID
-and formats the information in a similar manner to openais.conf(5). OpenAIS then reads those keys to start the cluster protocol.
+the corosync node name and nodeID
+and formats the information in a similar manner to corosync.conf(5). Corosync then reads those keys to start the cluster protocol.
 cmanpreconfig also reads several environment variables that might be set by cman_tool which can override information in the 
 configuration.
 .br
@@ -410,6 +410,6 @@ In the absence of ccsconfig, ie when 'cman_tool join' is run with -X switch (thi
 cmanpreconfig also generates several defaults so that the cluster can be got running without any configuration information - see above
 for the details.
 .br
-Note that cmanpreconfig will not overwrite OpenAIS keys that are explicitly set in the configuration file, allowing you to provide
+Note that cmanpreconfig will not overwrite corosync keys that are explicitly set in the configuration file, allowing you to provide
 custom values for token timeouts etc, even though cman has its own defaults for some of those values. The exception to this is the node
 name/address and multicast values, which are always taken from the cman configuration keys.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]