d3d1f960f5
This uses go-libp2p-kad-dht as routing provider for the Cluster Peers. This means that: * A cluster peer can discover other Cluster peers even if they are not in their peerstore file. * We remove a bunch of code sending and receiving peers multiaddresses when a new peer was added to the Cluster. * PeerAdd now takes an ID and not a multiaddress. We do not need to ask the new peer which is our external multiaddress nor broadcast the new multiaddress to everyone. This will fix problems when bootstrapping a new peer to the Cluster while not all the other peers are online. * Adding a new peer does not mean to open connections to all peers anymore. The number of connections will be made according to the DHT parameters (this is good to have for future work) The that detecting a peer addition in the watchPeers() function does no longer mean that we have connected to it or that we know its multiaddresses. Therefore it's no point to save the peerstore in these events anymore. Here a question opens, should we save the peerstore at all, and should we save multiaddresses only for cluster peers, or for everyone known? Currently, the peerstore is only updated on clean shutdown, and it is updated with all the multiaddresses known, and not limited to peer IDs in the cluster, (because, why not). License: MIT Signed-off-by: Hector Sanjuan <code@hector.link> |
||
---|---|---|
.github | ||
.gx | ||
.snapcraft | ||
allocator | ||
api | ||
ci | ||
config | ||
consensus/raft | ||
docker | ||
informer | ||
ipfs-cluster-ctl | ||
ipfs-cluster-service | ||
ipfsconn/ipfshttp | ||
monitor | ||
pintracker | ||
pstoremgr | ||
rpcutil | ||
sharness | ||
snap | ||
state | ||
test | ||
.codeclimate.yml | ||
.dockerignore | ||
.gitignore | ||
.travis.yml | ||
allocate.go | ||
CHANGELOG.md | ||
cluster_config_test.go | ||
cluster_config.go | ||
cluster_test.go | ||
cluster.go | ||
clusterhost.go | ||
config_test.go | ||
connect_graph.go | ||
CONTRIBUTING.md | ||
Dockerfile | ||
Dockerfile-bundle | ||
Dockerfile-test | ||
ipfscluster_test.go | ||
ipfscluster.go | ||
LICENSE | ||
logging.go | ||
Makefile | ||
package.json | ||
peer_manager_test.go | ||
pnet_test.go | ||
README.md | ||
release.sh | ||
rpc_api.go | ||
util.go | ||
version.go |
IPFS Cluster
Pinset orchestration for IPFS.
IPFS Cluster allows to allocate, replicate and track Pins across a cluster of IPFS daemons.
It provides:
- A cluster peer application:
ipfs-cluster-service
, to be run along withgo-ipfs
. - A client CLI application:
ipfs-cluster-ctl
, which allows easily interacting with the peer's HTTP API.
Table of Contents
Documentation
Please visit https://cluster.ipfs.io/documentation/ to access user documentation, guides and any other resources, including detailed download and usage instructions.
News & Roadmap
We regularly post project updates to https://cluster.ipfs.io/news/ .
The most up-to-date Roadmap is available at https://cluster.ipfs.io/roadmap/ .
Install
Instructions for different installation methods (including from source) are available at https://cluster.ipfs.io/documentation/download .
Usage
Extensive usage information is provided at https://cluster.ipfs.io/documentation/ , including:
Contribute
PRs accepted. As part of the IPFS project, we have some contribution guidelines.
Small note: If editing the README, please conform to the standard-readme specification.
License
MIT © Protocol Labs, Inc.