@@ -103,12 +103,15 @@ In this example case, the following commands are required:
./gen-cert.sh fredclient 172.26.1.3
```
If you want to add additional IP addresses (e.g., a server listens on several interfaces), modify the script for additional `IP.X` entries in the `[alt_names]` section of the CSR.
If you want the certificate to be valid for a hostname, add `DNS.1`, etc.
#### Network
If you run this example in Docker, you must first create a simple network for the individual services to talk to each other:
@@ -502,6 +505,7 @@ Some last words, keep pull requests small (not 100 files changed etc :D), so the
### Code Quality and Testing
In order to keep our code clean and working, we provide a number of test suites and support a number of code quality tools.
Please keep in mind that most tests require a working Docker installation.
#### Static Analysis
...
...
@@ -545,13 +549,13 @@ This is part of a TDD approach where tests can be defined first and the software
The "3 node test" starts a FReD deployment of three FReD nodes and runs a client against the FReD cluster that validates different functionalities.
It can be found in `./tests/3NodeTest`.
It uses Docker compose and can thus easily be started with `make 3n-all`.
It uses Docker compose and can thus easily be started with `go test .`.
The deployment comprises a single `etcd` Docker container as a NaSe, a simple trigger node, two FReD nodes that each comprise only a single machine (node _B_ and _C_) with a storage server, and a distributed FReD node _A_ that comprises three individual FReD machines behind a `fredproxy` sharing a single storage server.
All machines are connected over a Docker network.
The test client runs a number of operations against the FReD deployment and outputs a list of errors.
The complete code for the test client can be found in `./tests/3NodeTest/cmd/main/main.go`.
The complete code for the test client can be found in `./tests/3NodeTest/3node_test.go`.
When the debug log output of the individual nodes is not enough to debug an issue, it is also possible to connect a `dlv` debugger directly to FReD node _B_ to set breakpoints or step through code.
This is currently configured to use the included debugger in the GoLang IDE.
// in this case no same key should be in in different maps
keys:=make(map[uint64]string)
fori:=0;i<concurrent;i++{
forkey,val:=rangeexpected[i]{
if_,ok:=keys[key];ok{
logNodeFailure(nodes[0],fmt.Sprintf("only one client can write to key %d",key),fmt.Sprintf("several clients were able to write to same id for %d",key))
continue
}
keys[key]=val
}
}
forkey,val:=rangekeys{
k:=strconv.FormatUint(key,10)
v,_:=nodes[0].GetItem(keygroup,k,false)
iflen(v)!=1{
logNodeFailure(nodes[0],fmt.Sprintf("expected one value for %d",key),fmt.Sprintf("got no %d return values",len(v)))
continue
}
ifv[0]!=val{
logNodeFailure(nodes[0],fmt.Sprintf("value %s for %d",val,key),fmt.Sprintf("got wrong value %s",v[0]))
}
}
}
func(t*ConcurrencyImmutableSuite)Name()string{
return"ConcurrencyImmutable"
}
func(t*ConcurrencyImmutableSuite)RunTests(){
run:=0
// Test 1: create immutable keygroup, have two goroutines append data