This adds a new cluster command: ipfs-cluster-follow.
This command allows initializing and running follower peers as configured by a
remote-source configuration. The command can list configured peers
and obtain information for each of them.
Peers are launched with the rest API listening on a local unix socket. The
command can be run to list the items in the cluster pinset using this
endpoint. Alternatively, if no socket is present, the peer will be assumed to
be offline and the pin list will be directly read from the datastore.
Cluster peers launched with this command (and their configurations) are
compatible with ipfs-cluster-ctl and ipfs-cluster-service. We purposely do not
support most configuration options here. Using ipfs-cluster-ctl or launching
the peers using ipfs-cluster-service is always an option when the usecase
deviates from that supported by ipfs-cluster-follow.
Examples:
$ ipfs-cluster-follow -> list configured peers
$ ipfs-cluster-follow --help
$ ipfs-cluster-follow <clusterName> init <url>
$ ipfs-cluster-follow <clusterName> info
$ ipfs-cluster-follow <clusterName> run
$ ipfs-cluster-follow <clusterName> list
config manager: Improve source-fetch error handling
* Allow detection of source-download errors by adding IsSourceDownloadError method.
* Treat non-success response codes as a failure to fetch the source.
* Set the Source url before errors happens so it can be consulted even in that case.
This introduces the possiblity of running Cluster with multiple informer components. The first one in the list is the used for "allocations". This is just groundwork for working with several informers in the future.
This adds a PeerAddresses entry to the main cluster configuration.
The peer will ingest and potentially connect to those peer addresses during
the start (similarly to the ones in the peerstore).
This allows to provide "bootstrap" (as in "peers we connect to") addresses
directly in the configuration, which is useful when distributing a single
configuration template that will allow a cluster peer to know where to connect
on the first boot.
On using `/debug/pprof` as index endpoint, profiles contained by it
would point to wrong url. For example, link for `allocs` would be
`/debug/allocs` (results in 404), whereas it should actually be
`/debug/pprof/allocs`.
Use a trailing slash to get correct links. `/debug/pprof` will
automatically be redirected to `/debug/pprof/`
This lowers the activation threshold for an observed addressed
to 1 and increases the OwnObservedAddressTTL to infinite.
This should let cluster peers (particularly in small clusters)
advertise their known external addresses asap so that other peers
can include them in their peerstores (and save them on shutdown).
By default this only happens when an external address has received 4
connections in the last 40 minutes. In NATed environments this may
result in cluster peers advertising right away their NAT-translated address/ports
which may not be dialable, but in other cases that address seems to be
indeed dialable (docker).
