@@ -296,7 +296,7 @@ all traffic.
We should note that this method works well under the assumption that there
are no inter-gateway connectivity failures, in such case this method would fail
-to elect a single master. The simplest example is two gateways which stop seeing
+to elect a single leader. The simplest example is two gateways which stop seeing
each other but can still reach the hypervisors. Protocols like VRRP or CARP
have the same issue. A mitigation for this type of failure mode could be
achieved by having all network elements (hypervisors and gateways) periodically
@@ -164,7 +164,7 @@ is_local_chassis_only_candidate(const struct sbrec_ha_chassis_group *ha_ch_grp,
return (local_chassis_present && n_active_ha_chassis == 1);
}
-/* Returns true if the local_chassis is the master of
+/* Returns true if the local_chassis is the active chassis of
* the HA chassis group, false otherwise. */
bool
ha_chassis_group_is_active(
@@ -1813,7 +1813,7 @@
<p>
When multiple chassis have been specified for a gateway, all chassis that
may send packets to that gateway will enable BFD on tunnels to all
- configured gateway chassis. The current master chassis for the gateway
+ configured gateway chassis. The current active chassis for the gateway
is the highest priority gateway chassis that is currently viewed as
active based on BFD status.
</p>
@@ -943,7 +943,7 @@
send any traffic to this port. <code>OVN</code> can support
native services like DHCPv4/DHCPv6/DNS for this port.
If <ref column="ha_chassis_group"/> is defined,
- <code>ovn-controller</code> running in the master chassis of
+ <code>ovn-controller</code> running in the active chassis of
the HA chassis group will bind this port to provide these native
services. It is expected that this port belong to a bridged
logical switch (with a <code>localnet</code> port).
@@ -4794,10 +4794,10 @@ or
Table representing a group of chassis which can provide high availability
services. Each chassis in the group is represented by the table
<ref table="HA_Chassis"/>. The HA chassis with highest priority will
- be the master of this group. If the master chassis failover is detected,
- the HA chassis with the next higher priority takes over the
+ be the active chassis of this group. If the active chassis failover is
+ detected, the HA chassis with the next higher priority takes over the
responsibility of providing the HA. If a distributed gateway router port
- references a row in this table, then the master HA chassis in this group
+ references a row in this table, then the active HA chassis in this group
provides the gateway functionality.
</p>
@@ -4830,7 +4830,7 @@ or
<column name="priority">
<p>
Priority of the chassis. Chassis with highest priority will be
- the master.
+ the active chassis.
</p>
</column>
@@ -4682,7 +4682,7 @@ tcp.flags = RST;
<column name="priority">
<p>
Priority of the HA chassis. Chassis with highest priority will be
- the master in the HA chassis group.
+ the active chassis in the HA chassis group.
</p>
</column>
@@ -4698,13 +4698,13 @@ tcp.flags = RST;
Table representing a group of chassis which can provide High availability
services. Each chassis in the group is represented by the table
<ref table="HA_Chassis"/>. The HA chassis with highest priority will
- be the master of this group. If the master chassis failover is detected,
- the HA chassis with the next higher priority takes over the
+ be the active chassis of this group. If the active chassis failover is
+ detected, the HA chassis with the next higher priority takes over the
responsibility of providing the HA. If <ref db="OVN_Southbound"
table="Port_Binding" column="ha_chassis_group"/> column of the table
<ref db="OVN_Southbound" table="Port_Binding"/> references this table,
then this HA chassis group provides the gateway functionality and
- redirects the gateway traffic to the master of this group.
+ redirects the gateway traffic to the active chassis of this group.
</p>
<column name="name">
Name of the <ref table="HA_Chassis_Group"/>. Name should be unique.
@@ -518,8 +518,8 @@ OVN_CONTROLLER_EXPECT_HIT(
[ovn-nbctl --wait=hv lrp-set-gateway-chassis lr1-public hv5 10 && ovn-nbctl --wait=hv sync]
)
-# Make hv4 master. There is remote possibility that full recompute
-# triggers for hv1-hv5 after hv4 becomes master because of updates to the
+# Make hv4 active. There is remote possibility that full recompute
+# triggers for hv1-hv5 after hv4 becomes active because of updates to the
# ovn-hv$i-0 interfaces. Most of the time there will be no recompute.
ovn-nbctl --wait=hv lrp-set-gateway-chassis lr1-public hv4 40
hv4_ch=$(ovn-sbctl --bare --columns _uuid list chassis hv4)
@@ -12798,7 +12798,7 @@ AT_CHECK([uniq packets], [0], [expout])
$PYTHON "$ovs_srcdir/utilities/ovs-pcap.in" hv4/br-ex_n2-tx.pcap > empty
AT_CHECK([cat empty], [0], [])
-AS_BOX([Make hv4 master])
+AS_BOX([Make hv4 active])
as hv1 reset_pcap_file hv1-vif1 hv1/vif1
as hv4 reset_pcap_file br-ex_n2 hv4/br-ex_n2
ovn-nbctl --wait=sb ha-chassis-group-add-chassis hagrp1 hv4 40
@@ -14213,7 +14213,7 @@ AT_CLEANUP
])
OVN_FOR_EACH_NORTHD([
-AT_SETUP([ensure one gw controller restart in HA doesn't bounce the master])
+AT_SETUP([ensure one gw controller restart in HA doesn't bounce the active chassis])
ovn_start
net_add n1
@@ -20274,7 +20274,7 @@ ovn-nbctl ha-chassis-group-add-chassis hagrp1 hv3 10
ovn_wait_for_bfd_up hv1 hv2 hv3
-# hv1 should be master and claim ls1-lp_ext1
+# hv1 should be active and claim ls1-lp_ext1
wait_row_count Port_Binding 1 logical_port=ls1-lp_ext1 chassis=$hv1_uuid
wait_for_ports_up ls1-lp_ext1
@@ -20342,10 +20342,10 @@ rm -f ext1_v6.expected
rm -f ext1_v6.packets
as hv1 reset_pcap_file hv1-ext1 hv1/ext1
-# Now increase the priority of hv3 so it becomes master.
+# Now increase the priority of hv3 so it becomes active.
ovn-nbctl ha-chassis-group-add-chassis hagrp1 hv3 50
-# hv3 should be master and claim ls1-lp_ext1
+# hv3 should be active and claim ls1-lp_ext1
wait_row_count Port_Binding 1 logical_port=ls1-lp_ext1 chassis=$hv3_uuid
wait_for_ports_up ls1-lp_ext1
@@ -20420,7 +20420,7 @@ as hv3
port=${sandbox}_br-phys
as main ovs-vsctl del-port n1 $port
-# hv1 should be master and claim ls1-lp_ext1
+# hv1 should be active and claim ls1-lp_ext1
wait_row_count Port_Binding 1 logical_port=ls1-lp_ext1 chassis=$hv1_uuid
wait_for_ports_up ls1-lp_ext1
@@ -20434,7 +20434,7 @@ grep -c "actions=drop"], [0], [1
as hv1 ovn-appctl -t ovn-controller exit
as hv3 ovn-appctl -t ovn-controller exit
-# hv2 should be master and claim ls1-lp_ext1
+# hv2 should be active and claim ls1-lp_ext1
wait_row_count Port_Binding 1 logical_port=ls1-lp_ext1 chassis=$hv2_uuid
wait_for_ports_up ls1-lp_ext1
This commit replaces the word "master" with alternative words. Places where "master" is not replaced: * References to third-party URLs, option names, and code repositories. * The "integration" documentation is unchanged. It references pacemaker options which use the word "master". The text also refers to both "masters" and "slaves". In this case, changing the text could cause confusion if pacemaker uses "master" and "slave" in its user-facing options/documentation. Signed-off-by: Mark Michelson <mmichels@redhat.com> --- Documentation/topics/high-availability.rst | 2 +- controller/ha-chassis.c | 2 +- ovn-architecture.7.xml | 2 +- ovn-nb.xml | 10 +++++----- ovn-sb.xml | 8 ++++---- tests/ovn-performance.at | 4 ++-- tests/ovn.at | 14 +++++++------- 7 files changed, 21 insertions(+), 21 deletions(-)