Go to file
JT Olio 5f6607935b
captplanet (#159)
* captplanet

I kind of went overboard this weekend.

The major goal of this changeset is to provide an environment
for local development where all of the various services can
be easily run together. Developing on Storj v3 should be as
easy as running a setup command and a run command!

To do this, this changeset introduces a new tool called
captplanet, which combines the powers of the Overlay Cache,
the PointerDB, the PieceStore, Kademlia, the Minio Gateway,
etc.

Running 40 farmers and a heavy client inside the same process
forced a rethinking of the "services" that we had. To
avoid confusion by reusing prior terms, this changeset
introduces two new types: Providers and Responsibilities.
I wanted to avoid as many merge conflicts as possible, so
I left the existing Services and code for now, but if people
like this route we can clean up the duplication.

A Responsibility is a collection of gRPC methods and
corresponding state. The following systems are examples of
Responsibilities:
 * Kademlia
 * OverlayCache
 * PointerDB
 * StatDB
 * PieceStore
 * etc.

A Provider is a collection of Responsibilities that
share an Identity, such as:
 * The heavy client
 * The farmer
 * The gateway

An Identity is a public/private key pair, a node id, etc.
Farmers all need different Identities, so captplanet
needs to support running multiple concurrent Providers
with different Identities.

Each Responsibility and Provider should allow for configuration
of multiple copies on its own so creating Responsibilities and
Providers use a new workflow.

To make a Responsibility, one should create a "config"
struct, such as:

```
type Config struct {
  RepairThreshold int `help:"If redundancy falls below this number of
pieces, repair is triggered" default:"30"`
  SuccessThreshold int `help:"If redundancy is above this number then
no additional uploads are needed" default:"40"`
}
```

To use "config" structs, this changeset introduces another
new library called 'cfgstruct', which allows for the configuration
of arbitrary structs through flagsets, and thus through cobra and
viper.

cfgstruct relies on Go's "struct tags" feature to document
help information and default values. Config structs can be
configured via cfgstruct.Bind for binding the struct to a flagset.

Because this configuration system makes setup and configuration
easier *in general*, additional commands are provided that allow
for easy standup of separate Providers. Please make sure to
check out:
 * cmd/captplanet/farmer/main.go (a new farmer binary)
 * cmd/captplanet/hc/main.go (a new heavy client binary)
 * cmd/captplanet/gw/main.go (a new minio gateway binary)

Usage:

```
$ go install -v storj.io/storj/cmd/captplanet
$ captplanet setup
$ captplanet run
```

Configuration is placed by default in `~/.storj/capt/`

Other changes:

 * introduces new config structs for currently existing
   Responsibilities that conform to the new Responsibility
   interface. Please see the `pkg/*/config.go` files for
   examples.

 * integrates the PointerDB API key with other global
   configuration via flags, instead of through environment
   variables through viper like it's been doing. (ultimately
   this should also change to use the PointerDB config
   struct but this is an okay shortterm solution).

 * changes the Overlay cache to use a URL for database
   configuration instead of separate redis and bolt config
   settings.

 * stubs out some peer identity skeleton code (but not the
   meat).

 * Fixes the SegmentStore to use the overlay client and
   pointerdb clients instead of gRPC client code directly

 * Leaves a very clear spot where we need to tie the object to
   stream to segment store together. There's sort of a "golden
   spike" opportunity to connect all the train tracks together
   at the bottom of pkg/miniogw/config.go, labeled with a
   bunch of TODOs.

Future stuff:

 * I now prefer this design over the original
   pkg/process.Service thing I had been pushing before (sorry!)

 * The experience of trying to have multiple farmers
   configurable concurrently led me to prefer config structs
   over global flags (I finally came around) or using viper
   directly. I think global flags are okay sometimes but in
   general going forward we should try and get all relevant
   config into config structs.

 * If you all like this direction, I think we can go delete my
   old Service interfaces and a bunch of flags and clean up a
   bunch of stuff.

 * If you don't like this direction, it's no sweat at all, and
   despite how much code there is here I'm not very tied to any
   of this! Considering a lot of this was written between midnight
   and 6 am, it might not be any good!

* bind tests
2018-07-24 10:08:28 -06:00
cmd captplanet (#159) 2018-07-24 10:08:28 -06:00
docs Add error handling section 2018-04-11 07:43:23 -05:00
examples captplanet (#159) 2018-07-24 10:08:28 -06:00
internal Mutex/nsclient- WIP (#104) 2018-07-19 15:57:22 -07:00
logo wip on structure 2018-04-06 12:32:34 -04:00
pkg captplanet (#159) 2018-07-24 10:08:28 -06:00
pointerdb/auth captplanet (#159) 2018-07-24 10:08:28 -06:00
protos Mutex/nsclient- WIP (#104) 2018-07-19 15:57:22 -07:00
scripts Automatically build, tag and push docker images on merge to master (#103) 2018-06-21 15:36:39 -04:00
static Cache (#67) 2018-06-05 17:06:37 -04:00
storage adds netstate pagination (#95) 2018-06-29 16:06:25 -04:00
.clabot adding Kiev team to CLA (#149) 2018-07-16 09:49:40 -04:00
.gitignore Admin node (#131) 2018-07-09 16:43:32 -06:00
.travis.yml Config updates (#141) 2018-07-18 18:09:38 -06:00
go.mod pkg/kademlia tests and restructuring (#97) 2018-06-22 09:33:57 -04:00
Gopkg.lock Admin node (#131) 2018-07-09 16:43:32 -06:00
Gopkg.toml dep init (#56) 2018-05-29 20:28:46 -06:00
index.html Cache (#67) 2018-06-05 17:06:37 -04:00
Jenkinsfile Add dockerfile and yaml for setting up piecestore servers (#102) 2018-07-19 15:42:50 -04:00
LICENSE license code with agplv3 (#126) 2018-07-05 10:24:26 -04:00
Makefile Add dockerfile and yaml for setting up piecestore servers (#102) 2018-07-19 15:42:50 -04:00
README.md update install instructions (#130) 2018-07-19 15:48:51 -04:00

Storj

Go Report Card Go Doc

Coverage Status


Storj is a platform, token, and suite of decentralized applications that allows you to store data in a secure and decentralized manner. Your files are encrypted, shredded into little pieces called 'shards' and stored in a global decentralized network of computers. Only you have access and the ability to retrieve all shards from the network, decrypt them, and finally re-combine all file pieces into your original file.


To start using Storj

See our documentation at Storj docs.

To start developing Storj

The community site hosts all information about building storj from source, how to contribute code and documentation, who to contact about what, etc.

Install required packages

First of all install git, golang and redis-server and add environment variables.

Debian based (like Ubuntu)

apt-get install git golang redis-server
echo 'export GOPATH="$HOME/go"' >> $HOME/.bashrc
echo 'export PATH="$PATH:${GOPATH//://bin:}/bin"' >> $HOME/.bashrc
source $HOME/.bashrc

Mac OSX

brew install git go redis
if test -e $HOME/.bash_profile
then
	echo 'export GOPATH="$HOME/go"' >> $HOME/.bash_profile
	echo 'export PATH="$PATH:${GOPATH//://bin:}/bin"' >> $HOME/.bash_profile
	source $HOME/.bash_profile
else
	echo 'export GOPATH="$HOME/go"' >> $HOME/.profile
	echo 'export PATH="$PATH:${GOPATH//://bin:}/bin"' >> $HOME/.profile
	source $HOME/.profile
fi

Install storj

Clone the storj repository. You may want to clone your own fork and branch.

git clone https://github.com/storj/storj $GOPATH/src/storj.io/storj

Install all dependencies

go get can be used to install all dependencies. The execution will take some time. You can add -v if you want to get more feedback.

go get -t storj.io/storj/...

Fix error message cannot use "github.com/minio/cli" See https://github.com/minio/minio/issues/5974 for more details.

go get -t github.com/minio/cli && rm -rf $GOPATH/src/github.com/minio/minio/vendor/github.com/minio/cli
go get -t storj.io/storj/...

Run unit tests

go clean -testcache
go test storj.io/storj/...

You can execute only a single test package. For example: go test storj.io/storj/pkg/kademlia. Add -v for more informations about the executed unit tests.

Start farmer

piecestore-farmer --help

To be continued.

You have a working Docker environment.

$ git clone https://github.com/storj/storj
$ cd storj
$ make docker

For the full story, head over to the [developer's documentation].

Support

If you need support, start with the [troubleshooting guide], and work your way through the process that we've outlined.

That said, if you have any questions or suggestions please reach out to us on rocketchat or twitter.