Improve "local-cluster.sh" script to bind hostnames defined in "server.yaml"

[wuchong]

Search before asking

• I searched in the issues and found nothing similar.

Motivation

Currently, the local-cluster.sh script hardcodes TabletServer addresses to localhost:0, ignoring the bind.listeners configuration in server.yaml (which defaults to FLUSS://localhost:9123 but can be customized to an externally accessible IP and port).

This inconsistency causes a usability issue: while the Coordinator can be reached from external machines (thanks to bind.listeners), TabletServers remain bound to localhost and are therefore inaccessible externally.

Solution

To improve usability and consistency, TabletServers should use the same hostname (or IP) specified in bind.listeners, while still using port 0 to avoid conflicts with the Coordinator’s fixed port. This ensures the entire local cluster can be uniformly accessed from remote clients when needed.

Anything else?

No response

Willingness to contribute

• I'm willing to submit a PR!

[gyang94]

Thinking:
The main problem is that we can't only modify the "port" in "bind.listeners". Now we either specify the whole new bind.listeners string, or use the old {host}:{port} in the config file to update addresses. We can not only set the new host or port individually.

Proposed solution:
Introduce a new parameter to specify the new ports for listeners. e.g.
-Dbind.listeners.port.override=FLUSS:0,CLIENT:1000
Then in the Endpoint.loadBindEndpoints() function, if this parameters is set, override the parsed Endpoint object with new port.
This parameter can only be as a dynamic config, not a formal config set in server.config.

What do you think? @wuchong

[wuchong]

@gyang94 The issue is that, in local-cluster.sh, which needs to start two processes (Coordinator and TabletServer) on the same host. However, we only have a single bind.listeners configuration.

Even if we introduce something like bind.listeners.port.override, it’s still a shared setting, using it for both processes would cause port conflicts.

That’s why local-cluster.sh currently assigns a random port (0) to the TabletServer: to avoid collision with the Coordinator’s fixed port while reusing the same hostname/IP from bind.listeners.

[gyang94]

@wuchong yes, that is why I think about that it is only a dynamic config, not set it to config file.
Currently in local-cluster.sh , to solve the issue, we set a -Dbind.listeners parameter in the command of starting tablet-server, which overrides the whole listener address(host + port). But we only want to override the port for tablet-server to 0.
With the new parameter, we can also only set bind.listeners.port.override in the command for tablet-server (not in coordinator server), to only override tablet server's port, and keep the host be the same as config files.

With new parameter, I suppose the local-cluster.sh would be like the following. This setting won't be shared to coordinator.

"$FLUSS_BIN_DIR"/coordinator-server.sh start

"${FLUSS_BIN_DIR}"/tablet-server.sh start -Dbind.listeners.port.override=FLUSS:0

[wuchong]

@gyang94 I understand your point. However, introducing a new config like bind.listeners.port.override would unnecessarily bloat the configuration space and create confusion with the existing bind.listeners setting.

This issue is specific to local-cluster.sh. There’s no broader need for such a configuration. It’s better to handle it in the local-cluster.sh script, rather than exposing complexity to all users.

Moreover, bind.listeners.port.override wouldn’t cleanly solve the problem: if a user configures multiple listeners like
bind.listeners=INTERNAL://10.0.0.23:9123,EXTERNAL://10.0.0.23:9124,
hard-coding -Dbind.listeners.port.override=FLUSS:0 would fail because the TabletServer does not use the same listener name.

I think the solution is very simple:

1. Parse the bind.listeners value from server.yaml,
2. Replace the port in each listener URI with 0,
3. Pass the updated value via -Dbind.listeners=... when launching the TabletServer.

This keeps the logic contained, avoids config sprawl, and works for any listener setup.