THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Partially Change FindCoordinator Request Routing
One edge case we also would would also like to fix is for the FindCoordinator protocol. It has a special internal topic creation logic when the cluster receives the request for the first time as transaction log topic and consumer offset topic are lazily initialized. Currently the target broker shall just utilize its own ZK client to create topic, which is disallowed in the bridge release. For this scenario, non-controller broker shall just forward a CreateTopicRequest to the controller instead and let controller take care of the rest, while waiting for the response in the mean time.
Public Interfaces
Protocol Bump
We are going to bump all mentioned APIs above by one version, and new admin client was expected to only talk to the controller. For example we bump the AlterConfig API to v2.
...
AlterConfig to v2
IncrementalAlterConfig to v2
CreateAcls to v3
DeleteAcls to v3
AlterClientQuotas to v1
CreateDelegationToken to v3
RenewDelegationToken to v3
ExpireDelegationToken to v3
The FindCoordinator routing change is purely inter-broker, and the CreateTopicRequest is already handled by controller only, so no change on that side.
New Tag for Principal Name
| Code Block |
|---|
{
"type": "header",
"name": "RequestHeader",
// Version 0 of the RequestHeader is only used by v0 of ControlledShutdownRequest.
//
// Version 1 is the first version with ClientId.
//
// Version 2 is the first flexible version.
"validVersions": "0-2",
"flexibleVersions": "2+",
"fields": [
{ "name": "RequestApiKey", "type": "int16", "versions": "0+",
"about": "The API key of this request." },
{ "name": "RequestApiVersion", "type": "int16", "versions": "0+",
"about": "The API version of this request." },
{ "name": "CorrelationId", "type": "int32", "versions": "0+",
"about": "The correlation ID of this request." },
// The ClientId string must be serialized with the old-style two-byte length prefix.
// The reason is that older brokers must be able to read the request header for any
// ApiVersionsRequest, even if it is from a newer version.
// Since the client is sending the ApiVersionsRequest in order to discover what
// versions are supported, the client does not know the best version to use.
{ "name": "ClientId", "type": "string", "versions": "1+", "nullableVersions": "1+", "ignorable": true,
"flexibleVersions": "none", "about": "The client ID string." },
{ "name": "ProxyPrincipalName", "type": "string", "tag": 0, "taggedVersions": "2+", "ignorable": true,
"about": "Optional value of the principal name when the request is redirected by a broker." }, // new optional field
]
} |
Compatibility, Deprecation, and Migration Plan
...