THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- What impact (if any) will there be on existing users? Users who use Kafka clusters with Zookeeper clients older than 3.5.x won't be able to communicate with a Zookeeper cluster using 3.8.1. As mentioned in the accompanying JIRA ticket Apache Kafka has been using Zookeeper since version 2.4, everything above and including this version should be stable. It is acceptable to break compatibility with Apache Kafka versions prior to 2.4 as they are considered beyond their end of life and are not maintained (source: Time Based Release Plan#WhatIsOurEOLPolicy).
Notable changes in Zookeeper 3.7.0 related to security
- previously there could be only one SASL SuperUser. With this change multiple SuperUsers could be specified via a configuration.Jira server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key ZOOKEEPER-3959
- quotas which were not previously enforced are now enforced.Jira server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key ZOOKEEPER-3301
- Kerberos authentication did not work over SSL, but has now been fixed.Jira server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key ZOOKEEPER-3482
- user enforced authentication was only available for SASL before this change.Jira server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key ZOOKEEPER-3561
Notable changes in Zookeeper 3.8.0 related to security
- instead of storing password as plaintext use password protected files.Jira server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key ZOOKEEPER-4396 - If we are changing behavior how will we phase out the older behavior? It should gradually be phased out as users update their Kafka versions
- If we need special migration tools, describe them here. N/A
- When will we remove the existing behavior? N/A
...