[
https://issues.apache.org/jira/browse/KUDU-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Lipcon resolved KUDU-94.
-----------------------------
Resolution: Invalid
Fix Version/s: n/a
I dont think this is relevant anymore.
> Cleanup duplicated info about replica state/role
> ------------------------------------------------
>
> Key: KUDU-94
> URL: https://issues.apache.org/jira/browse/KUDU-94
> Project: Kudu
> Issue Type: Improvement
> Components: consensus, master
> Affects Versions: M3
> Reporter: David Alves
> Fix For: n/a
>
>
> Right now we're keeping replica state/roles/info in multiple places which is
> going to be prone to errors.
> From gerrit:
> Todd Lipcon Jan 28 10:12 AM
> hrm... what do we do if this conflicts with the role we think the given peer
> is supposed to have in the current configuration?
>
> David Alves Jan 28 10:26 AM
> tldr; for now probably just change it to whatever role the peer thinks it
> has. later probably refactor having duplicated information in multiple forms.
> long version:
> Making peers return the whole QuorumPB, storing those on the master and
> forwarding those to the client IMO is still the way to go. A QuorumPB
> represents a valid configuration that was accepted by the quorum so, while a
> peer might think it is LEADER, it might not be until the configuration that
> makes him so has gone through the quorum. Hence a QuorumPB is a snapshot of a
> valid quorum config and should be used whenever roles of peers are relevant.
> Still I started making this change and it's a bit of work, so we should
> probably just add a JIRA for it and move on.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
