Darrell,
I don’t think you can handle the error of unsupported replication mode the way
it is described here:
+ <column name="switch_fault_status"
+ key="unsupported_source_node_replication">
+ Indicates that the requested source node replication mode cannot be
+ supported by the physical switch; this specifically means in this
+ context that the physical switch lacks the capability to support
+ source node replication mode. This error occurs when a controller
+ attempts to set source node replication mode for one of the logical
+ switches that the physical switch is keeping context for. If this
+ error occurs, logical switches continue to use service node
+ replication mode.
+ </column>
If a given logical switch spans 2 or more physical switches, and one of them
can’t support source mode replication, but the other one can, then you’ll end
up with the logical switch in a mixed state, with one switch falling back to
service node mode and the other staying in source node mode. At this point I
don’t know what happens, but clearly the controller will not be able to report
what mode the logical switch is actually in (short of introducing an explicit
“mixed mode”).
I propose that the last sentence read: An NVC that observes this error
condition should take appropriate action (e.g. reverting the logical switch to
service node replication mode).
Regarding the description of the alt_replication_mode column, I think it could
be clearer. Suggested wording follows:
<group title="Per Logical-Switch Alternate Replication Mode">
<p>
For handling broadcast, multicast (in default manner) and unknown
unicast traffic, packets can be sent to all members of a logical
switch. There are different modes
to replicate the packets. The default mode of replication is to send
the
traffic to a service node, which can be a hypervisor, server or
appliance, and let the service node handle replication to other
transport nodes (hypervisors or other VTEP physical
switches). This mode is called service node replication. An alternate
mode of replication, called source node replication involves the
source node sending to all other transport nodes. Hypervisors are
always responsible for doing their own replication for locally
attached VMs in both modes.
Service node mode is the default (and was the only option for prior
versions of this schema).
Source node mode is an alternate replication mode that may be
configured using this column.
</p>
<column name="alt_replication_mode">
<p>
This column (if used) configures the alternate replication mode for
this
<ref table="Logical_Switch"/>. There is one valid value presently,
<code>source_node</code>.
</p>
Finally, it’s not strictly necessary to give this group such a long name. It’s
a per-logical switch feature by definition (it exists in the table where per
logical switch information is configured) so you could shorten the name as
follows:
<group title="Alternate Replication Mode”>
(The reason that the tunnel key gets the longwinded treatment is because it can
also be configured on a per tunnel basis elsewhere in the schema).
Bruce
_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev
