Refactor/enhancement requested by @catj-cockroach and @andreimatei.
Currently, we use the same rpc.Context to support RPC traffic between nodes, and between CLI RPC clients and nodes.
This is a problem because the construction of a rpc.Context instance requires a lot of details for servers, which are commonly not available in CLI client code. So when instantiating rpc.Context for a CLI client, we need to fill in fields in ways that are hard to understand:
- why does a client need to fill in a tenant ID?
- why does a client need to know about the client CA for TLS?
- why does a client need to know the cluster ID? and node ID container?
All these questions are really inconvenient and an artifact of the fact we're using the same Go type for two unrelated purposes.
Instead we should have two different types: ServerContext and ClientContext with separate constructors.
The logic common to the two could be shared by a struct inherited from both.
Jira issue: CRDB-11830
Refactor/enhancement requested by @catj-cockroach and @andreimatei.
Currently, we use the same
rpc.Contextto support RPC traffic between nodes, and between CLI RPC clients and nodes.This is a problem because the construction of a
rpc.Contextinstance requires a lot of details for servers, which are commonly not available in CLI client code. So when instantiatingrpc.Contextfor a CLI client, we need to fill in fields in ways that are hard to understand:All these questions are really inconvenient and an artifact of the fact we're using the same Go type for two unrelated purposes.
Instead we should have two different types:
ServerContextandClientContextwith separate constructors.The logic common to the two could be shared by a struct inherited from both.
Jira issue: CRDB-11830