add API to list voters - Githubissues

rabbitmq / ra

A Raft implementation for Erlang and Elixir that strives to be efficient and make it easier to use multiple Raft clusters in a single system.

Other

798 stars 93 forks source link

add API to list voters #411

Closed illotum closed 5 months ago

illotum commented 5 months ago

Proposed Changes

This is a small addition, high-level API to list voters of a Ra cluster. To be used wherever an active quorum list is needed instead of ra:members.

Types of Changes

[ ] Bug fix (non-breaking change which fixes issue #NNNN)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation (correction or otherwise)
[ ] Cosmetics (whitespace, appearance)

Checklist

[x] I have read the CONTRIBUTING.md document
[x] I have signed the CA (see https://cla.pivotal.io/sign/rabbitmq)
[x] All tests pass locally with my changes
[x] I have added tests that prove my fix is effective or that my feature works
[x] I have added necessary documentation (if appropriate)
[ ] Any dependent changes have been merged and published in related repositories

michaelklishin commented 5 months ago

@illotum our team would like to ask for another API extension. This one is fine for where it will be used in RabbitMQ, so I guess we can keep it.

The function we'd like to see is a version of ra:members/1 that would return a map with a more detailed view of cluster members.

ra:members_with_details/1 and ra:members_ext/1 are two named proposed. WDYT?

kjnilsson commented 5 months ago

On second thought I think ra:members_info/1 would be a good name, effectively returning what's in the cluster key of the ra_state() map. The leader doesn't update it's own ra_peer_state() so that needs to be filled in on the fly.

illotum commented 5 months ago

For sure! I usually lean towards minimal changes, but the extended API covers all my needs and more.

kjnilsson commented 5 months ago

For sure! I usually lean towards minimal changes, but the extended API covers all my needs and more.

I think with all the peer info we can probably make better external decision on stuff like member changes without further probing. I have on a couple of occasions wished I could get this information in an easier way. ra:voters/1 is very specific the ra module API is growing quite large and having a more generic function avoids us having to add yet another function in the future.

illotum commented 5 months ago

Following on the rabbitmq-server#10394 thread, lets revert this merge then and I'll go ahead with a proper member_info.

michaelklishin commented 5 months ago

Done.