add log level

Signed-off-by: Connor <zbk602423539@gmail.com>

Makefile

@@ -26,7 +26,7 @@ dev: default test
 test:
 	@echo "Running tests in native mode."
 	@export TZ='Asia/Shanghai'; \
-	$(GOTEST) -cover $(PACKAGES)
+	LOG_LEVEL=fatal $(GOTEST) -cover $(PACKAGES)
 
 CURDIR := $(shell pwd)
 export PATH := $(CURDIR)/bin/:$(PATH)
@@ -51,46 +51,46 @@ format:
 	@gofmt -s -w `find . -name '*.go' -type f ! -path '*/_tools/*' -print`
 
 project1:
-	go test -count=1 ./kv/server -run 1 
+	$(GOTEST) ./kv/server -run 1 
 
 project2: project2a project2b project2c
 
 project2a:
-	go test -count=1 ./raft -run 2A
+	$(GOTEST) ./raft -run 2A
 
 project2aa:
-	go test -count=1 ./raft -run 2AA
+	$(GOTEST) ./raft -run 2AA
 
 project2ab:
-	go test -count=1 ./raft -run 2AB
+	$(GOTEST) ./raft -run 2AB
 
 project2ac:
-	go test -count=1 ./raft -run 2AC
+	$(GOTEST) ./raft -run 2AC
 
 project2b:
-	go test -count=1 ./kv/test_raftstore -run 2B
+	$(GOTEST) ./kv/test_raftstore -run 2B
 
 project2c:
-	go test -count=1 ./raft ./kv/test_raftstore -run 2C
+	$(GOTEST) ./raft ./kv/test_raftstore -run 2C
 
 project3: project3a project3b project3c
 
 project3a:
-	go test -count=1 ./raft -run 3A
+	$(GOTEST) ./raft -run 3A
 
 project3b:
-	go test -count=1 ./raft -run 3B
+	$(GOTEST) ./raft -run 3B
 
 project3c:
-	go test -count=1 ./scheduler/... -run 3C
+	$(GOTEST) ./scheduler/... -run 3C
 
 project4: project4a project4b project4c
 
 project4a:
-	go test -count=1 ./kv/transaction/... -run 4A
+	$(GOTEST) ./kv/transaction/... -run 4A
 
 project4b:
-	go test -count=1 ./kv/transaction/... -run 4B
+	$(GOTEST) ./kv/transaction/... -run 4B
 
 project4c:
-	go test -count=1 ./kv/transaction/... -run 4C
+	$(GOTEST) ./kv/transaction/... -run 4C

README.md

@@ -37,7 +37,7 @@ Now you can run `make` to check that everything is working as expected. You shou
 
 ### Overview of the code
 
-![overview](courses/imgs/overview.png)
+![overview](doc/imgs/overview.png)
 
 Same as the architect TiDB + TiKV + PD that separates the storage and computation, TinyKV only focuses on the storage layer of a distributed database system. If you are also interested in SQL layer, see [TinySQL](https://github.com/pingcap-incubator/tinysql). Besides that, there is a component called TinyScheduler as a center control of the whole TinyKV cluster, which collects information from the heartbeats of TinyKV. After that, the TinyScheduler can generate some scheduling tasks and distribute them to the TinyKV instances. All of them are communicated by RPC.
 
@@ -47,6 +47,7 @@ The whole project is organized into the following directories:
 - `proto`: all communication between nodes and processes uses Protocol Buffers over gRPC. This package contains the protocol definitions used by TinyKV, and generated Go code for using them.
 - `raft`: implementation of the Raft distributed consensus algorithm, used in TinyKV.
 - `scheduler`: implementation of the TinyScheduler which is responsible for managing TinyKV nodes and for generating timestamps.
+- `log`: log utility to output log base	on level.
 
 ### Course material
 

doc/project2-RaftKV.md

@@ -1,6 +1,6 @@
 # Project2 RaftKV
 
-Raft is a consensus algorithm that is designed to be easy to understand. You can read material about the Raft itself at [the Raft site](https://raft.github.io/), an interactive visualization of the Raft, and other resources, including [the extended Raft paper]( https://raft.github.io/raft.pdf).
+Raft is a consensus algorithm that is designed to be easy to understand. You can read material about the Raft itself at [the Raft site](https://raft.github.io/), an interactive visualization of the Raft, and other resources, including [the extended Raft paper](https://raft.github.io/raft.pdf).
 
 In this project you will implement a high available kv server based on raft,  which needs you not only to implement the Raft algorithm but also use it practically, and bring you more challenges like managing raft’s persisted state with `badger`, add flow control for snapshot message, etc.
 
@@ -199,7 +199,6 @@ In this stage, you may consider these errors, and others will be processed in pr
 > - You can apply the committed Raft log entries in an asynchronous way just like TiKV does. It’s not necessary, though a big challenge to improve performance.
 > - Record the callback of the command when proposing, and return the callback after applying.
 > - For the snap command response, should set badger Txn to callback explicitly.
-> - You can change the log level in `kv/config/config.go` to control whether to print some logs, which will be useful when debugging.
 
 ## Part C
 

go.mod

@@ -34,4 +34,4 @@ require (
 
 go 1.13
 
-replace github.com/pingcap/tidb => github.com/pingcap-incubator/tinysql v0.0.0-20200429065743-414e03ef38bd
+replace github.com/pingcap/tidb => github.com/pingcap-incubator/tinysql v0.0.0-20200429190545-ab844a9e29fe

go.sum

@@ -205,8 +205,8 @@ github.com/pelletier/go-toml v1.3.0/go.mod h1:PN7xzY2wHTK0K9p34ErDQMlFxa51Fk0OUr
 github.com/petar/GoLLRB v0.0.0-20190514000832-33fb24c13b99 h1:KcEvVBAvyHkUdFAygKAzwB6LAcZ6LS32WHmRD2VyXMI=
 github.com/petar/GoLLRB v0.0.0-20190514000832-33fb24c13b99/go.mod h1:HUpKUBZnpzkdx0kD/+Yfuft+uD3zHGtXF/XJB14TUr4=
 github.com/pingcap-incubator/tinykv v0.0.0-20200320061650-f660f803e910/go.mod h1:YBDZKrKXGtZ8JnIwiiugENs8ykQiMNKOdaTC5lnEGVc=
-github.com/pingcap-incubator/tinysql v0.0.0-20200429065743-414e03ef38bd h1:mU/oD21p1lvolThE7AW+2s/LJ2YDdMtcmAnO927YoZU=
-github.com/pingcap-incubator/tinysql v0.0.0-20200429065743-414e03ef38bd/go.mod h1:r381uAExaY7K6lDM0lSpbWtdSbw1eDdLADMO7ZrvWV8=
+github.com/pingcap-incubator/tinysql v0.0.0-20200429190545-ab844a9e29fe h1:2826WhLU/2CtgfMgfhZCX2fNUhVByQeH3nD26GZ0a0s=
+github.com/pingcap-incubator/tinysql v0.0.0-20200429190545-ab844a9e29fe/go.mod h1:r381uAExaY7K6lDM0lSpbWtdSbw1eDdLADMO7ZrvWV8=
 github.com/pingcap/check v0.0.0-20190102082844-67f458068fc8 h1:USx2/E1bX46VG32FIw034Au6seQ2fY9NEILmNh/UlQg=
 github.com/pingcap/check v0.0.0-20190102082844-67f458068fc8/go.mod h1:B1+S9LNcuMyLH/4HMTViQOJevkGiik3wW2AN9zb2fNQ=
 github.com/pingcap/check v0.0.0-20191107115940-caf2b9e6ccf4/go.mod h1:PYMCGwN0JHjoqGr3HrZoD+b8Tgx8bKnArhSq8YVzUMc=

kv/config/config.go

@@ -83,7 +83,6 @@ func NewDefaultConfig() *Config {
 
 func NewTestConfig() *Config {
 	return &Config{
-		LogLevel:                 "fatal",
 		Raft:                     true,
 		RaftBaseTickInterval:     50 * time.Millisecond,
 		RaftHeartbeatTicks:       2,

log/log.go

@@ -1,4 +1,10 @@
-//high level log wrapper, so it can output different log based on level
+// High level log wrapper, so it can output different log based on level.
+//
+// There are five levels in total: FATAL, ERROR, WARNING, INFO, DEBUG.
+// The default log output level is INFO, you can change it by:
+// - call log.SetLevel()
+// - set environment variable `LOG_LEVEL`
+
 package log
 
 import (
@@ -264,5 +270,11 @@ func New() *Logger {
 }
 
 func NewLogger(w io.Writer, prefix string) *Logger {
-	return &Logger{_log: log.New(w, prefix, LstdFlags), level: LOG_LEVEL_INFO, highlighting: true}
+	var level LogLevel
+	if l := os.Getenv("LOG_LEVEL"); len(l) != 0 {
+		level = StringToLogLevel(os.Getenv("LOG_LEVEL"))
+	} else {
+		level = LOG_LEVEL_INFO
+	}
+	return &Logger{_log: log.New(w, prefix, LstdFlags), level: level, highlighting: true}
 }

raft/raft_paper_test.go

@@ -14,10 +14,9 @@
 
 /*
 This file contains tests which verify that the scenarios described
-in the raft paper (https://ramcloud.stanford.edu/raft.pdf) are
-handled by the raft implementation correctly. Each test focuses on
-several sentences written in the paper. This could help us to prevent
-most implementation bugs.
+in the raft paper (https://raft.github.io/raft.pdf) are handled by the
+raft implementation correctly. Each test focuses on several sentences
+written in the paper.
 
 Each test is composed of three parts: init, test and check.
 Init part uses simple and understandable way to simulate the init state.