Move patched raft package to internal

Author: Justin Fudally

go.mod

@@ -3,8 +3,10 @@ module github.com/github/freno
 go 1.13
 
 require (
+	github.com/armon/go-metrics v0.0.0-20190430140413-ec5e00d3c878
 	github.com/bradfitz/gomemcache v0.0.0-20190913173617-a41fca850d0b
 	github.com/go-sql-driver/mysql v1.5.0 // indirect
+	github.com/hashicorp/go-msgpack v0.5.5
 	github.com/hashicorp/raft v1.1.2
 	github.com/hashicorp/raft-boltdb v0.0.0-20191021154308-4207f1bf0617
 	github.com/julienschmidt/httprouter v1.3.0

internal/raft/.gitignore

@@ -0,0 +1,23 @@
+# Compiled Object files, Static and Dynamic libs (Shared Objects)
+*.o
+*.a
+*.so
+
+# Folders
+_obj
+_test
+
+# Architecture specific extensions/prefixes
+*.[568vq]
+[568vq].out
+
+*.cgo1.go
+*.cgo2.c
+_cgo_defun.c
+_cgo_gotypes.go
+_cgo_export.*
+
+_testmain.go
+
+*.exe
+*.test

internal/raft/.travis.yml

@@ -0,0 +1,16 @@
+language: go
+
+go:
+    - 1.4
+    - 1.5
+    - 1.6
+    - tip
+
+install: make deps
+script:
+    - make integ
+
+notifications:
+    flowdock:
+        secure: fZrcf9rlh2IrQrlch1sHkn3YI7SKvjGnAl/zyV5D6NROe1Bbr6d3QRMuCXWWdhJHzjKmXk5rIzbqJhUc0PNF7YjxGNKSzqWMQ56KcvN1k8DzlqxpqkcA3Jbs6fXCWo2fssRtZ7hj/wOP1f5n6cc7kzHDt9dgaYJ6nO2fqNPJiTc=
+

internal/raft/LICENSE

@@ -0,0 +1,17 @@
+DEPS = $(go list -f '{{range .TestImports}}{{.}} {{end}}' ./...)
+
+test:
+	go test -timeout=30s ./...
+
+integ: test
+	INTEG_TESTS=yes go test -timeout=3s -run=Integ ./...
+
+deps:
+	go get -d -v ./...
+	echo $(DEPS) | xargs -n1 go get -d
+
+cov:
+	INTEG_TESTS=yes gocov test github.com/hashicorp/raft | gocov-html > /tmp/coverage.html
+	open /tmp/coverage.html
+
+.PHONY: test cov integ deps

internal/raft/Makefile

@@ -0,0 +1,89 @@
+raft [![Build Status](https://travis-ci.org/hashicorp/raft.png)](https://travis-ci.org/hashicorp/raft)
+====
+
+raft is a [Go](http://www.golang.org) library that manages a replicated
+log and can be used with an FSM to manage replicated state machines. It
+is a library for providing [consensus](http://en.wikipedia.org/wiki/Consensus_(computer_science)).
+
+The use cases for such a library are far-reaching as replicated state
+machines are a key component of many distributed systems. They enable
+building Consistent, Partition Tolerant (CP) systems, with limited
+fault tolerance as well.
+
+## Building
+
+If you wish to build raft you'll need Go version 1.2+ installed.
+
+Please check your installation with:
+
+```
+go version
+```
+
+## Documentation
+
+For complete documentation, see the associated [Godoc](http://godoc.org/github.com/hashicorp/raft).
+
+To prevent complications with cgo, the primary backend `MDBStore` is in a separate repository,
+called [raft-mdb](http://github.com/hashicorp/raft-mdb). That is the recommended implementation
+for the `LogStore` and `StableStore`.
+
+A pure Go backend using [BoltDB](https://github.com/boltdb/bolt) is also available called
+[raft-boltdb](https://github.com/hashicorp/raft-boltdb). It can also be used as a `LogStore`
+and `StableStore`.
+
+## Protocol
+
+raft is based on ["Raft: In Search of an Understandable Consensus Algorithm"](https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf)
+
+A high level overview of the Raft protocol is described below, but for details please read the full
+[Raft paper](https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf)
+followed by the raft source. Any questions about the raft protocol should be sent to the
+[raft-dev mailing list](https://groups.google.com/forum/#!forum/raft-dev).
+
+### Protocol Description
+
+Raft nodes are always in one of three states: follower, candidate or leader. All
+nodes initially start out as a follower. In this state, nodes can accept log entries
+from a leader and cast votes. If no entries are received for some time, nodes
+self-promote to the candidate state. In the candidate state nodes request votes from
+their peers. If a candidate receives a quorum of votes, then it is promoted to a leader.
+The leader must accept new log entries and replicate to all the other followers.
+In addition, if stale reads are not acceptable, all queries must also be performed on
+the leader.
+
+Once a cluster has a leader, it is able to accept new log entries. A client can
+request that a leader append a new log entry, which is an opaque binary blob to
+Raft. The leader then writes the entry to durable storage and attempts to replicate
+to a quorum of followers. Once the log entry is considered *committed*, it can be
+*applied* to a finite state machine. The finite state machine is application specific,
+and is implemented using an interface.
+
+An obvious question relates to the unbounded nature of a replicated log. Raft provides
+a mechanism by which the current state is snapshotted, and the log is compacted. Because
+of the FSM abstraction, restoring the state of the FSM must result in the same state
+as a replay of old logs. This allows Raft to capture the FSM state at a point in time,
+and then remove all the logs that were used to reach that state. This is performed automatically
+without user intervention, and prevents unbounded disk usage as well as minimizing
+time spent replaying logs.
+
+Lastly, there is the issue of updating the peer set when new servers are joining
+or existing servers are leaving. As long as a quorum of nodes is available, this
+is not an issue as Raft provides mechanisms to dynamically update the peer set.
+If a quorum of nodes is unavailable, then this becomes a very challenging issue.
+For example, suppose there are only 2 peers, A and B. The quorum size is also
+2, meaning both nodes must agree to commit a log entry. If either A or B fails,
+it is now impossible to reach quorum. This means the cluster is unable to add,
+or remove a node, or commit any additional log entries. This results in *unavailability*.
+At this point, manual intervention would be required to remove either A or B,
+and to restart the remaining node in bootstrap mode.
+
+A Raft cluster of 3 nodes can tolerate a single node failure, while a cluster
+of 5 can tolerate 2 node failures. The recommended configuration is to either
+run 3 or 5 raft servers. This maximizes availability without
+greatly sacrificing performance.
+
+In terms of performance, Raft is comparable to Paxos. Assuming stable leadership,
+committing a log entry requires a single round trip to half of the cluster.
+Thus performance is bound by disk I/O and network latency.
+

internal/raft/README.md

@@ -0,0 +1,171 @@
+package raftbench
+
+// raftbench provides common benchmarking functions which can be used by
+// anything which implements the raft.LogStore and raft.StableStore interfaces.
+// All functions accept these interfaces and perform benchmarking. This
+// makes comparing backend performance easier by sharing the tests.
+
+import (
+	"github.com/hashicorp/raft"
+	"testing"
+)
+
+func FirstIndex(b *testing.B, store raft.LogStore) {
+	// Create some fake data
+	var logs []*raft.Log
+	for i := 1; i < 10; i++ {
+		logs = append(logs, &raft.Log{Index: uint64(i), Data: []byte("data")})
+	}
+	if err := store.StoreLogs(logs); err != nil {
+		b.Fatalf("err: %s", err)
+	}
+	b.ResetTimer()
+
+	// Run FirstIndex a number of times
+	for n := 0; n < b.N; n++ {
+		store.FirstIndex()
+	}
+}
+
+func LastIndex(b *testing.B, store raft.LogStore) {
+	// Create some fake data
+	var logs []*raft.Log
+	for i := 1; i < 10; i++ {
+		logs = append(logs, &raft.Log{Index: uint64(i), Data: []byte("data")})
+	}
+	if err := store.StoreLogs(logs); err != nil {
+		b.Fatalf("err: %s", err)
+	}
+	b.ResetTimer()
+
+	// Run LastIndex a number of times
+	for n := 0; n < b.N; n++ {
+		store.LastIndex()
+	}
+}
+
+func GetLog(b *testing.B, store raft.LogStore) {
+	// Create some fake data
+	var logs []*raft.Log
+	for i := 1; i < 10; i++ {
+		logs = append(logs, &raft.Log{Index: uint64(i), Data: []byte("data")})
+	}
+	if err := store.StoreLogs(logs); err != nil {
+		b.Fatalf("err: %s", err)
+	}
+	b.ResetTimer()
+
+	// Run GetLog a number of times
+	for n := 0; n < b.N; n++ {
+		if err := store.GetLog(5, new(raft.Log)); err != nil {
+			b.Fatalf("err: %s", err)
+		}
+	}
+}
+
+func StoreLog(b *testing.B, store raft.LogStore) {
+	// Run StoreLog a number of times
+	for n := 0; n < b.N; n++ {
+		log := &raft.Log{Index: uint64(n), Data: []byte("data")}
+		if err := store.StoreLog(log); err != nil {
+			b.Fatalf("err: %s", err)
+		}
+	}
+}
+
+func StoreLogs(b *testing.B, store raft.LogStore) {
+	// Run StoreLogs a number of times. We want to set multiple logs each
+	// run, so we create 3 logs with incrementing indexes for each iteration.
+	for n := 0; n < b.N; n++ {
+		b.StopTimer()
+		offset := 3 * (n + 1)
+		logs := []*raft.Log{
+			&raft.Log{Index: uint64(offset - 2), Data: []byte("data")},
+			&raft.Log{Index: uint64(offset - 1), Data: []byte("data")},
+			&raft.Log{Index: uint64(offset), Data: []byte("data")},
+		}
+		b.StartTimer()
+
+		if err := store.StoreLogs(logs); err != nil {
+			b.Fatalf("err: %s", err)
+		}
+	}
+}
+
+func DeleteRange(b *testing.B, store raft.LogStore) {
+	// Create some fake data. In this case, we create 3 new log entries for each
+	// test case, and separate them by index in multiples of 10. This allows
+	// some room so that we can test deleting ranges with "extra" logs to
+	// to ensure we stop going to the database once our max index is hit.
+	var logs []*raft.Log
+	for n := 0; n < b.N; n++ {
+		offset := 10 * n
+		for i := offset; i < offset+3; i++ {
+			logs = append(logs, &raft.Log{Index: uint64(i), Data: []byte("data")})
+		}
+	}
+	if err := store.StoreLogs(logs); err != nil {
+		b.Fatalf("err: %s", err)
+	}
+	b.ResetTimer()
+
+	// Delete a range of the data
+	for n := 0; n < b.N; n++ {
+		offset := 10 * n
+		if err := store.DeleteRange(uint64(offset), uint64(offset+9)); err != nil {
+			b.Fatalf("err: %s", err)
+		}
+	}
+}
+
+func Set(b *testing.B, store raft.StableStore) {
+	// Run Set a number of times
+	for n := 0; n < b.N; n++ {
+		if err := store.Set([]byte{byte(n)}, []byte("val")); err != nil {
+			b.Fatalf("err: %s", err)
+		}
+	}
+}
+
+func Get(b *testing.B, store raft.StableStore) {
+	// Create some fake data
+	for i := 1; i < 10; i++ {
+		if err := store.Set([]byte{byte(i)}, []byte("val")); err != nil {
+			b.Fatalf("err: %s", err)
+		}
+	}
+	b.ResetTimer()
+
+	// Run Get a number of times
+	for n := 0; n < b.N; n++ {
+		if _, err := store.Get([]byte{0x05}); err != nil {
+			b.Fatalf("err: %s", err)
+		}
+	}
+}
+
+func SetUint64(b *testing.B, store raft.StableStore) {
+	// Run SetUint64 a number of times
+	for n := 0; n < b.N; n++ {
+		if err := store.SetUint64([]byte{byte(n)}, uint64(n)); err != nil {
+			b.Fatalf("err: %s", err)
+		}
+	}
+}
+
+func GetUint64(b *testing.B, store raft.StableStore) {
+	// Create some fake data
+	for i := 0; i < 10; i++ {
+		if err := store.SetUint64([]byte{byte(i)}, uint64(i)); err != nil {
+			b.Fatalf("err: %s", err)
+		}
+	}
+	b.ResetTimer()
+
+	// Run GetUint64 a number of times
+	for n := 0; n < b.N; n++ {
+		if _, err := store.Get([]byte{0x05}); err != nil {
+			b.Fatalf("err: %s", err)
+		}
+	}
+}