Status

Current state:  Under Discussion 

Discussion thread: TBD

JIRA: TBD

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

In the admin client (Incremental)AlterConfig API, we implicitly support a feature to reload key/trust store by sending an (Incremental)AlterConfig request directly to the target broker with the exact same store path. This special logic will no longer work once all the AlterConfig requests get forwarded to the active controller, and the target broker will not do a security store reload since the config change ZK notification contains the same key/trust store path as its local copy. 

We have attempted a hacky solution by augmenting the security store path from single slash to double slash, like "/foo/bar" to "//foo//bar", in the hope of triggering an equivalent path reloading. This approach does solve the existing problem, but it is error-prone and does not meet a good maintainability standard. For example, it does not take care of the back slash path in Windows platform, also could potentially lead to path explosion if not implemented correctly as "///////foo///////bar". We certainly don't want to maintain such a hacky feature or extra effort to make it understandable to developers.

Furthermore, the key/trust store reloading is a completely separate feature from AlterConfigs. It does not change any persistent broker config values in either ZK or metadata quorum. It should be sent directly to the target broker for security store reload, not the active controller, which adds up additional network traffic overhead. We should have a separate RPC for this use case in the post KIP-500 broker, as well as maintaining the legacy AlterConfig approach in the older admin clients.

Public Interfaces

A new request type called `AlterBrokerProperty` shall be added to be a broker-targeted RPC. 

{
  "apiKey": N,
  "type": "request",
  "name": "AlterBrokerPropertyRequest",
  "validVersions": "0",
  "flexibleVersions": "0+",
  "fields": [
    { "name": "BrokerProperties", "type": "[]BrokerProperty",
      "versions": "0+", "fields": [
      { "name": "Key", "type": "string", "versions": "0+",
        "about": "The property key name." },
	  { "name": "Value", "type": "bytes", "versions": "0+",
        "about": "The property value." },
      ]
      }
    ]
    }
  ]
}

{
  "apiKey": N,
  "type": "request",
  "name": "AlterBrokerPropertyResponse",
  "validVersions": "0",
  "flexibleVersions": "0+",
  "fields": [
    { "name": "BrokerProperties", "type": "[]BrokerProperty",
      "versions": "0+", "fields": [
      { "name": "Key", "type": "string", "versions": "0+",
        "about": "The property key name." },
	  { "name": "ErrorCode", "type": "int16", "versions": "0+",
        "about": "The property alteration error code." },
      { "name": "ErrorMessage", "type": "string", "nullableVersions": "0+", "versions": "0+",
        "about": "The property alteration error message, or null if there was no error." },
      ]
    }
    ]
}

Proposed Changes

Compatibility, Deprecation, and Migration Plan

To summarize, we already take care of every possible combinations of broker/client versions, plus the API being used.

Rejected Alternatives

If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.