Thanks for the reply. Comments below.
On Wed, Apr 24, 2019 at 6:07 PM Colin McCabe <cmcc...@apache.org> wrote:
> Hi Jose,
>
> Thanks for the KIP, looks valuable.
>
> If I use a PreferredLeaderElection RPC to specifically request an unclean
> leader election, will this take effect even if unclean leader elections are
> disabled on the topic involved? I assume that the answer is yes, but it
> would be good to clarify this in the KIP.
>
Yes. One of the motivation for this change is to allow the user to attempt
unclean leader election without having to change the topic configuration. I
will update the motivation and design section.
What ACLs will be required to perform this action? WRITE on the topic
> resource? Or ALTER on KafkaCluster? Or perhaps ALTER on the topic would
> be most appropriate, since we probably don't want ordinary producers
> triggering unclean leader elections.
>
I am not sure. Let me investigate what the current RPC requires and get
back to you. This is not a new RPC. We are instead updating an existing RPC
that already performs authorization. The RPC has API key 32.
What's the rationale for using an int8 rather than just having a boolean
> that is either true or false for "unclean"? We only have two values now,
> and it seems like we could modify the RPC schema in the future if needed.
> Or is the intention to add more flags later?
>
There are two reason:
1. The controller supports 4 (5 technically) different election
algorithms. We are only exposing "preferred" and "unclean" through the
admin client because we only have use cases for those two election types.
It is possible that in the future we may want to support more algorithms.
This would allow us to make that change easier.
2. I believe that an enum is more descriptive than a boolean flag as it
is not a matter of "unclean" vs "clean" or "preferred" vs "non-preferred".
1. Preferred means that the controller will attempt to elect only the
fist replica describe in the partition assignment if it is
online and it is
in-sync.
2. Unclean means that the controller will attempt to elect the first
in-sync and alive replica given the order of the partition assignment. If
this is not satisfied it will attempt to elect the first replica in the
assignment that is alive.
