d70ab59004
* refactor multi node test suite Refactor the multinode test suite into the marketplace test suite. - Arbitrary number of nodes can be started with each test: clients, providers, validators - Hardhat can also be started locally with each test, usually for the purpose of saving and inspecting its log file. - Log files for all nodes can be persisted on disk, with configuration at the test-level - Log files, if persisted (as specified in the test), will be persisted to a CI artifact - Node config is specified at the test-level instead of the suite-level - Node/Hardhat process starting/stopping is now async, and runs much faster - Per-node config includes: - simulating proof failures - logging to file - log level - log topics - storage quota - debug (print logs to stdout) - Tests find next available ports when starting nodes, as closing ports on Windows can lag - Hardhat is no longer required to be running prior to starting the integration tests (as long as Hardhat is configured to run in the tests). - If Hardhat is already running, a snapshot will be taken and reverted before and after each test, respectively. - If Hardhat is not already running and configured to run at the test-level, a Hardhat process will be spawned and torn down before and after each test, respectively. * additional logging for debug purposes * address PR feedback - fix spelling - revert change from catching ProviderError to SignerError -- this should be handled more consistently in the Market abstraction, and will be handled in another PR. - remove method label from raiseAssert - remove unused import * Use API instead of command exec to test for free port Use chronos `createStreamServer` API to test for free port by binding localhost address and port. Use `ServerFlags.ReuseAddr` to enable reuse of same IP/Port on multiple test runs. * clean up * remove upraises annotations from tests * Update tests to work with updated erasure coding slot sizes * update dataset size, nodes, tolerance to match valid ec params Integration tests now have valid dataset sizes (blocks), tolerances, and number of nodes, to work with valid ec params. These values are validated when requested storage. Print the rest api failure message (via doAssert) when a rest api call fails (eg the rest api may validate some ec params). All integration tests pass when the async `clock.now` changes are reverted. * dont use async clock for now * fix workflow * move integration logs uplod to reusable --------- Co-authored-by: Dmitriy Ryajov <dryajov@gmail.com> |
||
---|---|---|
.github | ||
codex | ||
docker | ||
docs | ||
metrics | ||
tests | ||
vendor | ||
.dockerignore | ||
.editorconfig | ||
.gitignore | ||
.gitmodules | ||
BUILDING.md | ||
Makefile | ||
README.md | ||
atlas.lock | ||
build.nims | ||
codecov.yml | ||
codex.nim | ||
codex.nimble | ||
config.nims | ||
env.sh | ||
nimble.lock | ||
openapi.yaml |
README.md
Codex Decentralized Durability Engine
The Codex project aims to create a decentralized durability engine that allows persisting data in p2p networks. In other words, it allows storing files and data with predictable durability guarantees for later retrieval.
WARNING: This project is under active development and is considered pre-alpha.
Build and Run
For detailed instructions on preparing to build nim-codex see Building Codex.
To build the project, clone it and run:
make update && make
The executable will be placed under the build
directory under the project root.
Run the client with:
build/codex
Configuration
It is possible to configure a Codex node in several ways:
- CLI options
- Env. variable
- Config
The order of priority is the same as above: Cli arguments > Env variables > Config file values.
Environment variables
In order to set a configuration option using environment variables, first find the desired CLI option and then transform it in the following way:
- prepend it with
CODEX_
- make it uppercase
- replace
-
with_
For example, to configure --log-level
, use CODEX_LOG_LEVEL
as the environment variable name.
Configuration file
A TOML configuration file can also be used to set configuration values. Configuration option names and corresponding values are placed in the file, separated by =
. Configuration option names can be obtained from the codex --help
command, and should not include the --
prefix. For example, a node's log level (--log-level
) can be configured using TOML as follows:
log-level = "trace"
The Codex node can then read the configuration from this file using the --config-file
CLI parameter, like codex --config-file=/path/to/your/config.toml
.
CLI Options
build/codex --help
Usage:
codex [OPTIONS]... command
The following options are available:
--config-file Loads the configuration from a TOML file [=none].
--log-level Sets the log level [=info].
--metrics Enable the metrics server [=false].
--metrics-address Listening address of the metrics server [=127.0.0.1].
--metrics-port Listening HTTP port of the metrics server [=8008].
-d, --data-dir The directory where codex will store configuration and data.
-i, --listen-addrs Multi Addresses to listen on [=/ip4/0.0.0.0/tcp/0].
-a, --nat IP Addresses to announce behind a NAT [=127.0.0.1].
-e, --disc-ip Discovery listen address [=0.0.0.0].
-u, --disc-port Discovery (UDP) port [=8090].
--net-privkey Source of network (secp256k1) private key file path or name [=key].
-b, --bootstrap-node Specifies one or more bootstrap nodes to use when connecting to the network.
--max-peers The maximum number of peers to connect to [=160].
--agent-string Node agent string which is used as identifier in network [=Codex].
--api-bindaddr The REST API bind address [=127.0.0.1].
-p, --api-port The REST Api port [=8080].
--repo-kind Backend for main repo store (fs, sqlite) [=fs].
-q, --storage-quota The size of the total storage quota dedicated to the node [=8589934592].
-t, --block-ttl Default block timeout in seconds - 0 disables the ttl [=$DefaultBlockTtl].
--block-mi Time interval in seconds - determines frequency of block maintenance cycle: how
often blocks are checked for expiration and cleanup
[=$DefaultBlockMaintenanceInterval].
--block-mn Number of blocks to check every maintenance cycle [=1000].
-c, --cache-size The size of the block cache, 0 disables the cache - might help on slow hardrives
[=0].
--persistence Enables persistence mechanism, requires an Ethereum node [=false].
--eth-provider The URL of the JSON-RPC API of the Ethereum node [=ws://localhost:8545].
--eth-account The Ethereum account that is used for storage contracts [=EthAddress.none].
--eth-private-key File containing Ethereum private key for storage contracts [=string.none].
--marketplace-address Address of deployed Marketplace contract [=EthAddress.none].
--validator Enables validator, requires an Ethereum node [=false].
--validator-max-slots Maximum number of slots that the validator monitors [=1000].
Available sub-commands:
codex initNode
Logging
Codex uses Chronicles logging library, which allows great flexibility in working with logs. Chronicles has the concept of topics, which categorize log entries into semantic groups.
Using the log-level
parameter, you can set the top-level log level like --log-level="trace"
, but more importantly,
you can set log levels for specific topics like --log-level="info; trace: marketplace,node; error: blockexchange"
,
which sets the top-level log level to info
and then for topics marketplace
and node
sets the level to trace
and so on.
Example: running two Codex clients
To get acquainted with Codex, consider running the manual two-client test described HERE.
API
The client exposes a REST API that can be used to interact with the clients. Overview of the API can be found on api.codex.storage.