the native ProposeSync support

[chen-zhuohan]

In both the node.Propose and the raft example, an unreliable way to submit requests is used. In etcd raft, Propose will return when msg append into msgsAfterAppend or msgs.(May be I'm wrong?)

And in raft example, v send to channel then return:

func (h *httpKVAPI) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    key := r.RequestURI
    defer r.Body.Close()
    switch r.Method {
    case http.MethodPut:
        v, err := io.ReadAll(r.Body)
        ...
        h.store.Propose(key, string(v)) 
        w.WriteHeader(http.StatusNoContent)
        return
   ...

func (s *kvstore) Propose(k string, v string) {
    var buf strings.Builder
    if err := gob.NewEncoder(&buf).Encode(kv{k, v}); err != nil {
        log.Fatal(err)
    }
    s.proposeC <- buf.String()
}

I know that this is leaving Wait to the user to implement on their own, where they can choose their own timing to end Wait or even not Wait. But I guess most of the person that use raft want more reliability, so I have two proposals

1. put the wait interface and its default implementation from etcd into draft, and add new methods such as ProposeSyncApplied (wait for entry applied), ProposeSync (wait for entry commited, but not yet applied), and so on (or use option to distinguish between these behaviors). This requires adding a UUID to each Entry, and also allows the user to specify this UUID to be compatible with etcd's current RequestV2.ID.

2. Improve the raft example, the raft example should have a high reliability, after the user is familiar enough with the raft, adjust the behavior of the program to sacrifice reliability for performance. This can be done with Implement a self-contained raft example #2 (PS: I think the raft example can be simpler, there is no need to implement a persistent store and a real network layer, but there is a demonstration of the use of each method of the node)

I would like to know what you guys suggest and what is planned for etcd-raft in the future ~ I would also like to update some documentation and other contributions for etcd-raft, but I saw the milestone for etcd-raft 4.0 and I would like to know what is planned for 4.0 and when it will be available!

[peacedog123]

Newbie to etcd and etcd-raft, I have the same concern, I think read-after-write consistency is more understandable to beginners.

[pav-kv]

Option 1 seems like a no-go. Not all raft applications need a UUID in the Entry, and some applications (e.g. CRDB) implement their own identification mechanism (for similar purposes: detect when the entry comes as committed and/or applied).

Currently this info is available to the application layer already: the Ready() calls return the committed entries, then the application applies them, and notifies raft about it. At this point, the user code can implement their custom ID filtering logic (the ID would be contained in the Entry.Data field with all the other entry data).