Changes in 11270d7: bug fix: use numeric replica IP instead of trying to resolve internal DNS name; resolving an internal IP to a DNS host name won't work cross-region; a host effectively in eu-west-2 may hence resolve to an internal DNS name from eu-west-1 when the resolution is computed in eu-west-1.

				java/com.sap.sailing.gwt.ui/src/main/java/com/sap/sailing/gwt/ui/server/SailingServiceImpl.java
			
          @@ -3402,7 +3402,7 @@ public class SailingServiceImpl extends ResultCachingProxiedRemoteServiceServlet

                       for (Entry<Class<? extends OperationWithResult<?, ?>>, Integer> e : statistics.entrySet()) {

                           replicationCountByOperationClassName.put(e.getKey().getName(), e.getValue());

                       }

          -            replicaDTOs.add(new ReplicaDTO(replicaDescriptor.getIpAddress().getHostName(),

          +            replicaDTOs.add(new ReplicaDTO(replicaDescriptor.getIpAddress().getHostAddress(),

                               replicaDescriptor.getRegistrationTime().asDate(), replicaDescriptor.getUuid().toString(),

                               replicaDescriptor.getReplicableIdsAsStrings(), replicaDescriptor.getAdditionalInformation(),

                               replicationCountByOperationClassName,

				java/com.sap.sailing.landscape/src/com/sap/sailing/landscape/impl/LandscapeServiceImpl.java
			
          @@ -1099,7 +1099,7 @@ public class LandscapeServiceImpl implements LandscapeService {

                       // old replica was on a shared instance; in this case we'll over-provision, but it won't be long.

                       replicaConfigurationBuilder

                           .setInboundReplicationConfiguration(InboundReplicationConfiguration.builder()

          -                    .setMasterHostname(master.getHost().getPrivateAddress().getHostName())

          +                    .setMasterHostname(master.getHost().getPrivateAddress().getHostAddress())

                               .setMasterHttpPort(master.getPort())

                               .setCredentials(new BearerTokenReplicationCredentials(replicationBearerToken))

                               .build());

				java/com.sap.sailing.www/release_notes_admin.html
			
          @@ -53,6 +53,11 @@

                           otherwise.

                       </li>

                       <li>Sorting of replica-set table by name is now case-insensitive.</li>

          +            <li>Bug fix: when working cross-region with the Landscape panel, temporary upgrade replicas were identified

          +                trying to obtain their host name from their IP address. When this is attempted, however, for an IP address

          +                identifying a host in one region and the host name is determined from within another region then the

          +                internal DNS name chosen is that of the other region and therefore incorrect. Instead, now the IP address's

          +                numeric representation is used instead.</li>

                     </ul>

                     <h2 class="articleSubheadline">February 2023</h2>

                     <ul class="bulletList">

				wiki/info/landscape/olympic-failover.md
			
          @@ -24,6 +24,8 @@ SSH tunnels won't need to change.

           The local replica has to be safely shut down, on-site users might experience some change, depending on how we decide with local routing.

          +Alternatively, based on the Tokyo 2020 experience, we may consider running the second Lenovo P1 laptop also in "master/primary" mode as a "shadow" where all we need to focus on is initially connecting the TracTrac races and linking them properly to the leaderboard slots. From there on, administration other than adding or removing wind sources, proved to be low effort and close to zero interaction. The official scores are transmitted after confirmation from TracTrac, and so are all start time, finish times, and penalties. This approach could help reduce the time to fail over from the primary to the shadow system in a lot less time than would be required for a re-start of the second Lenovo P1 in master/primary mode.

          +

           ### Open questions

           How exactly has the switch to happen?

				wiki/info/landscape/olympic-setup.md
			
          @@ -149,7 +149,7 @@ The connection IDs will be shown, e.g., ``st-soft-aws_A``. Such a connection can

           On both laptops there is a script ``/usr/local/bin/tunnels`` which establishes SSH tunnels using the ``autossh`` tool. The ``autossh`` processes are forked into the background using the ``-f`` option. It seems important to then pass the port to use for sending heartbeats using the ``-M`` option. If this is omitted, according to my experience only one of several ``autossh`` processes survives.

          -During regular operations we assume that we have an Internet connection that allows us to reach our jump host ``tokyo-ssh.sapsailing.com`` through SSH, establishing various port forwards. We also expect TracTrac to have their primary server available. Furthermore, we assume both our laptops to be in service. ``sap-p1-1`` then runs the master server instance, ``sap-p1-2`` runs a local replica. The master on ``sap-p1-1`` replicates the central security service at ``security-service.sapsailing.com`` using the RabbitMQ installation on ``rabbit.internal.sapsailing.com`` in the AWS region eu-west-1. The port forwarding through tokyo-ssh.sapsailing.com (in ap-northeast-1) to the internal RabbitMQ address (in eu-west-1) works through VPC peering. The RabbitMQ instance used for outbound replication, both, into the cloud and for the on-site replica, is rabbit-ap-northeast-1.sapsailing.com. The replica on ``sap-p1-2`` obtains its replication stream from there, and for the HTTP connection for "reverse replication" it uses a direct connection to ``sap-p1-1``. The outside world, in particular all "S-ded-tokyo2020-m" master security groups in all regions supported, access the on-site master through a reverse port forward on our jump host ``tokyo-ssh.sapsailing.com:8888`` which under regular operations points to ``sap-p1-1:8888`` where the master process runs.

          +During regular operations we assume that we have an Internet connection that allows us to reach our jump host ``tokyo-ssh.sapsailing.com`` through SSH, establishing various port forwards. We also expect TracTrac to have their primary server available. Furthermore, we assume both our laptops to be in service. ``sap-p1-1`` then runs the master server instance, ``sap-p1-2`` runs a local replica. The master on ``sap-p1-1`` replicates the central security service at ``security-service.sapsailing.com`` using the RabbitMQ installation on ``rabbit.internal.sapsailing.com`` in the AWS region `eu-west-1`. The port forwarding through `tokyo-ssh.sapsailing.com` (in `ap-northeast-1`) to the internal RabbitMQ address (in eu-west-1) works through VPC peering. The RabbitMQ instance used for outbound replication, both, into the cloud and for the on-site replica, is `rabbit-ap-northeast-1.sapsailing.com`. The replica on ``sap-p1-2`` obtains its replication stream from there, and for the HTTP connection for "reverse replication" it uses a direct connection to ``sap-p1-1``. The outside world, in particular all "S-ded-tokyo2020-m" master security groups in all regions supported, access the on-site master through a reverse port forward on our jump host ``tokyo-ssh.sapsailing.com:8888`` which under regular operations points to ``sap-p1-1:8888`` where the master process runs.

           On both laptops we establish a port forward from ``localhost:22443`` to ``sapsailing.com:443``. Together with the alias in ``/etc/hosts`` that aliases ``www.sapsailing.com`` to ``localhost``, requests to ``www.sapsailing.com:22443`` will end up on the archive server.

...	...	@@ -3402,7 +3402,7 @@ public class SailingServiceImpl extends ResultCachingProxiedRemoteServiceServlet
3402	3402	for (Entry<Class<? extends OperationWithResult<?, ?>>, Integer> e : statistics.entrySet()) {
3403	3403	replicationCountByOperationClassName.put(e.getKey().getName(), e.getValue());
3404	3404	}
3405		- replicaDTOs.add(new ReplicaDTO(replicaDescriptor.getIpAddress().getHostName(),
	3405	+ replicaDTOs.add(new ReplicaDTO(replicaDescriptor.getIpAddress().getHostAddress(),
3406	3406	replicaDescriptor.getRegistrationTime().asDate(), replicaDescriptor.getUuid().toString(),
3407	3407	replicaDescriptor.getReplicableIdsAsStrings(), replicaDescriptor.getAdditionalInformation(),
3408	3408	replicationCountByOperationClassName,

...	...	@@ -1099,7 +1099,7 @@ public class LandscapeServiceImpl implements LandscapeService {
1099	1099	// old replica was on a shared instance; in this case we'll over-provision, but it won't be long.
1100	1100	replicaConfigurationBuilder
1101	1101	.setInboundReplicationConfiguration(InboundReplicationConfiguration.builder()
1102		- .setMasterHostname(master.getHost().getPrivateAddress().getHostName())
	1102	+ .setMasterHostname(master.getHost().getPrivateAddress().getHostAddress())
1103	1103	.setMasterHttpPort(master.getPort())
1104	1104	.setCredentials(new BearerTokenReplicationCredentials(replicationBearerToken))
1105	1105	.build());

...	...	@@ -53,6 +53,11 @@
53	53	otherwise.
54	54	</li>
55	55	<li>Sorting of replica-set table by name is now case-insensitive.</li>
	56	+ <li>Bug fix: when working cross-region with the Landscape panel, temporary upgrade replicas were identified
	57	+ trying to obtain their host name from their IP address. When this is attempted, however, for an IP address
	58	+ identifying a host in one region and the host name is determined from within another region then the
	59	+ internal DNS name chosen is that of the other region and therefore incorrect. Instead, now the IP address's
	60	+ numeric representation is used instead.</li>
56	61	</ul>
57	62	<h2 class="articleSubheadline">February 2023</h2>
58	63	<ul class="bulletList">

...	...	@@ -24,6 +24,8 @@ SSH tunnels won't need to change.
24	24
25	25	The local replica has to be safely shut down, on-site users might experience some change, depending on how we decide with local routing.
26	26
	27	+Alternatively, based on the Tokyo 2020 experience, we may consider running the second Lenovo P1 laptop also in "master/primary" mode as a "shadow" where all we need to focus on is initially connecting the TracTrac races and linking them properly to the leaderboard slots. From there on, administration other than adding or removing wind sources, proved to be low effort and close to zero interaction. The official scores are transmitted after confirmation from TracTrac, and so are all start time, finish times, and penalties. This approach could help reduce the time to fail over from the primary to the shadow system in a lot less time than would be required for a re-start of the second Lenovo P1 in master/primary mode.
	28	+
27	29	### Open questions
28	30
29	31	How exactly has the switch to happen?

...	...	@@ -149,7 +149,7 @@ The connection IDs will be shown, e.g., ``st-soft-aws_A``. Such a connection can
149	149
150	150	On both laptops there is a script ``/usr/local/bin/tunnels`` which establishes SSH tunnels using the ``autossh`` tool. The ``autossh`` processes are forked into the background using the ``-f`` option. It seems important to then pass the port to use for sending heartbeats using the ``-M`` option. If this is omitted, according to my experience only one of several ``autossh`` processes survives.
151	151
152		-During regular operations we assume that we have an Internet connection that allows us to reach our jump host ``tokyo-ssh.sapsailing.com`` through SSH, establishing various port forwards. We also expect TracTrac to have their primary server available. Furthermore, we assume both our laptops to be in service. ``sap-p1-1`` then runs the master server instance, ``sap-p1-2`` runs a local replica. The master on ``sap-p1-1`` replicates the central security service at ``security-service.sapsailing.com`` using the RabbitMQ installation on ``rabbit.internal.sapsailing.com`` in the AWS region eu-west-1. The port forwarding through tokyo-ssh.sapsailing.com (in ap-northeast-1) to the internal RabbitMQ address (in eu-west-1) works through VPC peering. The RabbitMQ instance used for outbound replication, both, into the cloud and for the on-site replica, is rabbit-ap-northeast-1.sapsailing.com. The replica on ``sap-p1-2`` obtains its replication stream from there, and for the HTTP connection for "reverse replication" it uses a direct connection to ``sap-p1-1``. The outside world, in particular all "S-ded-tokyo2020-m" master security groups in all regions supported, access the on-site master through a reverse port forward on our jump host ``tokyo-ssh.sapsailing.com:8888`` which under regular operations points to ``sap-p1-1:8888`` where the master process runs.
	152	+During regular operations we assume that we have an Internet connection that allows us to reach our jump host ``tokyo-ssh.sapsailing.com`` through SSH, establishing various port forwards. We also expect TracTrac to have their primary server available. Furthermore, we assume both our laptops to be in service. ``sap-p1-1`` then runs the master server instance, ``sap-p1-2`` runs a local replica. The master on ``sap-p1-1`` replicates the central security service at ``security-service.sapsailing.com`` using the RabbitMQ installation on ``rabbit.internal.sapsailing.com`` in the AWS region `eu-west-1`. The port forwarding through `tokyo-ssh.sapsailing.com` (in `ap-northeast-1`) to the internal RabbitMQ address (in eu-west-1) works through VPC peering. The RabbitMQ instance used for outbound replication, both, into the cloud and for the on-site replica, is `rabbit-ap-northeast-1.sapsailing.com`. The replica on ``sap-p1-2`` obtains its replication stream from there, and for the HTTP connection for "reverse replication" it uses a direct connection to ``sap-p1-1``. The outside world, in particular all "S-ded-tokyo2020-m" master security groups in all regions supported, access the on-site master through a reverse port forward on our jump host ``tokyo-ssh.sapsailing.com:8888`` which under regular operations points to ``sap-p1-1:8888`` where the master process runs.
153	153
154	154	On both laptops we establish a port forward from ``localhost:22443`` to ``sapsailing.com:443``. Together with the alias in ``/etc/hosts`` that aliases ``www.sapsailing.com`` to ``localhost``, requests to ``www.sapsailing.com:22443`` will end up on the archive server.
155	155