tillrohrmann commented on a change in pull request #11284:
[FLINK-15911][runtime] Make Flink work with NAT.
URL: https://github.com/apache/flink/pull/11284#discussion_r395544062
##########
File path:
flink-runtime/src/main/java/org/apache/flink/runtime/taskexecutor/TaskManagerRunner.java
##########
@@ -351,21 +351,21 @@ public static TaskExecutor startTaskManager(
LOG.info("Starting TaskManager with ResourceID: {}",
resourceID);
- InetAddress remoteAddress =
InetAddress.getByName(rpcService.getAddress());
+ InetAddress externalAddress =
InetAddress.getByName(rpcService.getAddress());
Review comment:
I thought that this is actually the problem we are trying to solve with this
PR. Assume the `TM` is running in a Docker container which has an external name
which is not resolvable from within the container. If all other Flink
components can resolve this name, then it would work if the `TM` itself would
not try to resolve the address.
At the moment we have the requirement that all `TM` components can resolve
their own and the addresses of the other `TMs`. I think this requirement is too
strict. What we actually need is that for a given `TM` `t` all other `TMs` `t'`
can resolve the address of `t`.
Of course, this means that if the user deploys multiple `TMs` into the same
network where they cannot resolve each others external names, then Flink would
not work. But this is ok because it violates the requirement that other `TMs`
need to be able to resolve a `TM's` address. It is then the user's
responsibility to configure the cluster accordingly.
Moreover, one could still enforce the current model by configuring the
`bind-host` to the external address. If this is the case, then a `TM` would
only start if it can resolve its own address.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
