Expose request coordinator

[wprzytula]

This draft is the first attempt to implement #1030. For now, only address is exposed; host ID is not, as it's not accessible in Connection (yet?).

Fixes: #1030

Pre-review checklist

• I have split my patch into logically separate commits.
• All commit messages clearly explain what they change and why.
• I added relevant tests for new features and bug fixes.
• All commits compile, pass static checks and pass test.
• PR description sums up the changes and reasons why they should be introduced.
• I have provided docstrings for the public items that I want to introduce.
• I have adjusted the documentation in ./docs/source/.
• I added appropriate Fixes: annotations to PR description.

[github-actions]

cargo semver-checks found no API-breaking changes in this PR.
Checked commit: c2860f5

[Lorak-mmk]

Why did you introduce new struct (Coordinator) instead of using Node?

[wprzytula]

Why did you introduce new struct (Coordinator) instead of using Node?

1. I did not realise that we do have access to Node in all places where we need to create Coordinator -- this fortunately seems to be true.
2. Coordinator is not a struct. It's just a type alias that is used for convenience. I imagined it could be a pair (Uuid, SocketAddr) in the final version of this PR.

[muzarski]

Why did you introduce new struct (Coordinator) instead of using Node?

Just Node is not enough for cpp-rust-driver purposes. In cpp-driver, the coordinator is the target (i.e. node + shard) identified by SocketAddr.

[Lorak-mmk]

Why did you introduce new struct (Coordinator) instead of using Node?

Just Node is not enough for cpp-rust-driver purposes. In cpp-driver, the coordinator is the target (i.e. node + shard) identified by SocketAddr.

Is there really an API in cpp-driver to retrieve a shard that the request was sent to?

[muzarski]

Why did you introduce new struct (Coordinator) instead of using Node?

Just Node is not enough for cpp-rust-driver purposes. In cpp-driver, the coordinator is the target (i.e. node + shard) identified by SocketAddr.

Is there really an API in cpp-driver to retrieve a shard that the request was sent to?

No, I might have phrased it wrong. Now that I think of it, I did, because there are no shards in Cassandra. What I meant is just that the request coordinator is identified via ip + port (SocketAddr).

[Lorak-mmk]

What I meant is just that the request coordinator is identified via ip + port (SocketAddr).

Than I don't understand why Node is not enough. It has addr field which contains SocketAddr inside: https://docs.rs/scylla/latest/scylla/cluster/enum.NodeAddr.html

[Lorak-mmk]

We can of course consider wrapping Node (or whatever else we need) in a new Coordinator struct if we may want to add new stuff there (maybe a Option?).

[muzarski]

What I meant is just that the request coordinator is identified via ip + port (SocketAddr).

Than I don't understand why Node is not enough. It has addr field which contains SocketAddr inside: https://docs.rs/scylla/latest/scylla/cluster/enum.NodeAddr.html

But the port in this SocketAddr is not always the port of the connection we routed the request to. AFAIU, this port is set to self.control_connection_endpoint.address().port() obtained here: https://github.com/scylladb/scylla-rust-driver/blob/v1.0.0/scylla/src/cluster/metadata.rs#L608. This port is later propagated for other peers as well (is it even correct???). Notice that the queried rpc_address from system.local/peers is an ip address without any port information.

[wprzytula]

: https://github.com/scylladb/scylla-rust-driver/blob/v1.0.0/scylla/src/cluster/metadata.rs#L608. This port is later propagated for other peers as well (is it even correct???).

Thanks for spotting the bug!

[wprzytula]

This port is later propagated for other peers as well (is it even correct???).

I took a blame walk and this is what I found:

[Lorak-mmk]

: https://github.com/scylladb/scylla-rust-driver/blob/v1.0.0/scylla/src/cluster/metadata.rs#L608. This port is later propagated for other peers as well (is it even correct???).

Thanks for spotting the bug!

Is it a bug?

[wprzytula]

: https://github.com/scylladb/scylla-rust-driver/blob/v1.0.0/scylla/src/cluster/metadata.rs#L608. This port is later propagated for other peers as well (is it even correct???).

Thanks for spotting the bug!

Is it a bug?

Is it not? Is the assumption that all nodes in the cluster expose the same port correct?

[Lorak-mmk]

Is it not? Is the assumption that all nodes in the cluster expose the same port correct?

I don't know. If it is not, how can we discover other ports?

[wprzytula]

Is it not? Is the assumption that all nodes in the cluster expose the same port correct?

I don't know. If it is not, how can we discover other ports?

OK, so in an internal discussion we established that all nodes shall follow the same configuration, including the native_transport_port. Thus, this is not a bug.

[wprzytula]

Why did you introduce new struct (Coordinator) instead of using Node?

Node is not clonable. Arc<Node> is clonable quite cheaply, but not as cheaply as custom structs filled with a bunch of Copy types are. Therefore, I still believe a tuple (be it a named tuple or a struct) is a better fit here.