lbadd icon indicating copy to clipboard operation
lbadd copied to clipboard

raft: consensus protocol design doc

Open SUMUKHA-PK opened this issue 4 years ago • 7 comments

The first step towards having a consensus protocol running. This'll serve as a spec to be followed for implementation. Updates to this doc will be done when needed to accommodate issues.

Closes #21

SUMUKHA-PK avatar Mar 29 '20 14:03 SUMUKHA-PK

I like it! Looks good so far

tsatke avatar Mar 30 '20 09:03 tsatke

Moved.

SUMUKHA-PK avatar Apr 10 '20 05:04 SUMUKHA-PK

@TimSatke @Abby3017 Your review happened on the older version, I was still writing the doc. Please do have a look now.

SUMUKHA-PK avatar May 06 '20 18:05 SUMUKHA-PK

Also important, but optional for this PR, specify the protobuf messages that need to be used. @SUMUKHA-PK you can do this in here if you like, otherwise, we can get in touch, so that I know what requirements are there, and what needs to be communicated. A protocol draft would be nice however (what messages are sent (election, appendentries, initial handshake, goodbye, requests))

tsatke avatar May 07 '20 17:05 tsatke

Looks like a lot of work here.

So I'd better get into this before I even think of implementing.

SUMUKHA-PK avatar May 07 '20 17:05 SUMUKHA-PK

What about membership change i.e if node added or deleted ?

@Abby3017

Currently, doesn't fall into the domain of what we want to implement. It's kind of an extended issue, we'll tackle that if and when needed.

SUMUKHA-PK avatar May 08 '20 04:05 SUMUKHA-PK

Please also check for whitespace errors in the lower part of the document. Other than that, this is a design document, but instead of designing the system, it is basically just a checklist what needs to be done. Please add an architecture. This means:

* include, which components will be implemented

* how will they interact with each other

* how will they fit into the existing system

* what will the APIs look like
  Maybe even draft some Go interface types that show the intended usage of the `raft` package.

Following is how each issue is tackled:

  • The main modules represent the components that will be implemented.
  • A separate module interaction section is added.
  • They'll fit in as a separate module on internal dir; mentioned in the beginning.

As far as the API goes, I think it'll need more time. I wish to begin an implementation and keep adding small patches to this because I think that'd be better.

Let me know if I misinterpreted something or anything else needs to be added.

SUMUKHA-PK avatar May 08 '20 04:05 SUMUKHA-PK