Merge pull request #10848 from spzala/raftthesis10831

raftdoc: fix raft thesis link

docs/server-learner.rst

@@ -78,7 +78,7 @@ As seen above, a simple misconfiguration can fail the whole cluster into an inop
 Raft Learner
 ============
 
-In order to mitigate such availability gaps in the previous section, `Raft §4.2.1 <https://ramcloud.stanford.edu/~ongaro/thesis.pdf>`_ introduces a new node state “Learner”, which joins the cluster as a **non-voting member** until it catches up to leader’s logs.
+In order to mitigate such availability gaps in the previous section, `Raft §4.2.1 <https://github.com/ongardie/dissertation/blob/master/stanford.pdf>`_ introduces a new node state “Learner”, which joins the cluster as a **non-voting member** until it catches up to leader’s logs.
 
 Features in v3.4
 ----------------

raft/README.md

@@ -190,7 +190,7 @@ may be reused. Node IDs must be non-zero.
 
 ## Implementation notes
 
-This implementation is up to date with the final Raft thesis (https://ramcloud.stanford.edu/~ongaro/thesis.pdf), although this implementation of the membership change protocol differs somewhat from that described in chapter 4. The key invariant that membership changes happen one node at a time is preserved, but in our implementation the membership change takes effect when its entry is applied, not when it is added to the log (so the entry is committed under the old membership instead of the new). This is equivalent in terms of safety, since the old and new configurations are guaranteed to overlap.
+This implementation is up to date with the final Raft thesis (https://github.com/ongardie/dissertation/blob/master/stanford.pdf), although this implementation of the membership change protocol differs somewhat from that described in chapter 4. The key invariant that membership changes happen one node at a time is preserved, but in our implementation the membership change takes effect when its entry is applied, not when it is added to the log (so the entry is committed under the old membership instead of the new). This is equivalent in terms of safety, since the old and new configurations are guaranteed to overlap.
 
 To ensure there is no attempt to commit two membership changes at once by matching log positions (which would be unsafe since they should have different quorum requirements), any proposed membership change is simply disallowed while any uncommitted change appears in the leader's log.
 

raft/doc.go

@@ -172,7 +172,7 @@ may be reused. Node IDs must be non-zero.
 Implementation notes
 
 This implementation is up to date with the final Raft thesis
-(https://ramcloud.stanford.edu/~ongaro/thesis.pdf), although our
+(https://github.com/ongardie/dissertation/blob/master/stanford.pdf), although our
 implementation of the membership change protocol differs somewhat from
 that described in chapter 4. The key invariant that membership changes
 happen one node at a time is preserved, but in our implementation the