Sylvain Bellemare 50b0b3cef2 Rebase/feat/586/integrate tx model (#641)
* Adjust imports to bigchaindb_common

* Adjust get_spent function signature

* Adjust block serialization

* Fix BigchainApi Test

* Fix TestTransactionValidation tests

* Fix TestBlockValidation tests

* WIP: TestMultipleInputs

* Adjust tests to tx-model interface changes

- Fix old tests
- Fix tests in TestMultipleInputs class

* Remove fulfillment message tests

* Fix TransactionMalleability tests

* Remove Cryptoconditions tests

* Remove create_transaction

* Remove signing logic

* Remove consensus plugin

* Fix block_creation pipeline

* Fix election pipeline

* Replace some util functions with bdb_common ones

- timestamp ==> gen_timestamp
- serialize.

* Implement Block model

* Simplify function signatures for vote functions

Change parameter interface for the following functions:

- has_previous_vote
- verify_vote_signature
- block_election_status

so that they take a block's id and voters instead of a fake block.

* Integrate Block and Transaction model

* Fix leftover tests and cleanup conftest

* Add bigchaindb-common to install_requires

* Delete transactions after block is written (#609)

* delete transactions after block is written

* cleanup transaction_exists

* check for duplicate transactions

* delete invalid tx from backlog

* test duplicate transaction

* Remove dead code

* Test processes.py

* Test invalid tx in on server

* Fix tests for core.py

* Fix models tests

* Test commands main fn

* Add final coverage to vote pipeline

* Add more tests to voting pipeline

* Remove consensus plugin docs and misc

* Post rebase fixes

* Fix rebase mess

* Remove extra blank line

* Improve docstring

* Remove comment

handled in bigchaindb/cryptoconditions#27;
see https://github.com/bigchaindb/cryptoconditions/issues/27

* Fix block serialization in block creation

* Add signed_ prefix to transfer_tx

* Improve docs

* Add library documentation page on pipelines

* PR feedback for models.py

* Impr. readability of get_last_voted_block

* Use dict comprehension

* Add docker-compose file to build and serve docs

locally for development purposes

* Change private_key for signing_key

* Improve docstrings

* Remove consensus docs

* Document new consensus module

* Create different transactions for the block

* Cleanup variable names in block.py

* Create different transactions for the block

* Cleanup variable names in block.py
2016-09-29 10:29:41 +02:00

180 lines
7.6 KiB
Markdown

# BigchainDB Configuration Settings
**Note: At the time of writing, BigchainDB Server code and BigchainDB Python driver code are mixed together, so the following settings are the settings used by BigchainDB Server and also by clients written using the Python driver code. Soon, the code will be separated into server, driver and shared modules, so that BigchainDB Server and BigchainDB clients will have different configuration settings.**
The value of each configuration setting is determined according to the following rules:
* If it's set by an environment variable, then use that value
* Otherwise, if it's set in a local config file, then use that value
* Otherwise, use the default value
For convenience, here's a list of all the relevant environment variables (documented below):
`BIGCHAINDB_KEYPAIR_PUBLIC`<br>
`BIGCHAINDB_KEYPAIR_PRIVATE`<br>
`BIGCHAINDB_KEYRING`<br>
`BIGCHAINDB_DATABASE_HOST`<br>
`BIGCHAINDB_DATABASE_PORT`<br>
`BIGCHAINDB_DATABASE_NAME`<br>
`BIGCHAINDB_SERVER_BIND`<br>
`BIGCHAINDB_SERVER_WORKERS`<br>
`BIGCHAINDB_SERVER_THREADS`<br>
`BIGCHAINDB_API_ENDPOINT`<br>
`BIGCHAINDB_STATSD_HOST`<br>
`BIGCHAINDB_STATSD_PORT`<br>
`BIGCHAINDB_STATSD_RATE`<br>
`BIGCHAINDB_CONFIG_PATH`<br>
The local config file is `$HOME/.bigchaindb` by default (a file which might not even exist), but you can tell BigchainDB to use a different file by using the `-c` command-line option, e.g. `bigchaindb -c path/to/config_file.json start`
or using the `BIGCHAINDB_CONFIG_PATH` environment variable, e.g. `BIGHAINDB_CONFIG_PATH=.my_bigchaindb_config bigchaindb start`.
Note that the `-c` command line option will always take precedence if both the `BIGCHAINDB_CONFIG_PATH` and the `-c` command line option are used.
You can read the current default values in the file [bigchaindb/\_\_init\_\_.py](https://github.com/bigchaindb/bigchaindb/blob/master/bigchaindb/__init__.py). (The link is to the latest version.)
Running `bigchaindb -y configure` will generate a local config file in `$HOME/.bigchaindb` with all the default values, with two exceptions: It will generate a valid private/public keypair, rather than using the default keypair (`None` and `None`).
## keypair.public & keypair.private
The [cryptographic keypair](../appendices/cryptography.html) used by the node. The public key is how the node idenifies itself to the world. The private key is used to generate cryptographic signatures. Anyone with the public key can verify that the signature was generated by whoever had the corresponding private key.
**Example using environment variables**
```text
export BIGCHAINDB_KEYPAIR_PUBLIC=8wHUvvraRo5yEoJAt66UTZaFq9YZ9tFFwcauKPDtjkGw
export BIGCHAINDB_KEYPAIR_PRIVATE=5C5Cknco7YxBRP9AgB1cbUVTL4FAcooxErLygw1DeG2D
```
**Example config file snippet**
```js
"keypair": {
"public": "8wHUvvraRo5yEoJAt66UTZaFq9YZ9tFFwcauKPDtjkGw",
"private": "5C5Cknco7YxBRP9AgB1cbUVTL4FAcooxErLygw1DeG2D"
}
```
Internally (i.e. in the Python code), both keys have a default value of `None`, but that's not a valid key. Therefore you can't rely on the defaults for the keypair. If you want to run BigchainDB, you must provide a valid keypair, either in the environment variables or in the local config file. You can generate a local config file with a valid keypair (and default everything else) using `bigchaindb -y configure`.
## keyring
A list of the public keys of all the nodes in the cluster, excluding the public key of this node.
**Example using an environment variable**
```text
export BIGCHAINDB_KEYRING=BnCsre9MPBeQK8QZBFznU2dJJ2GwtvnSMdemCmod2XPB:4cYQHoQrvPiut3Sjs8fVR1BMZZpJjMTC4bsMTt9V71aQ
```
Note how the keys in the list are separated by colons.
**Example config file snippet**
```js
"keyring": ["BnCsre9MPBeQK8QZBFznU2dJJ2GwtvnSMdemCmod2XPB",
"4cYQHoQrvPiut3Sjs8fVR1BMZZpJjMTC4bsMTt9V71aQ"]
```
**Default value (from a config file)**
```js
"keyring": []
```
## database.host, database.port & database.name
The RethinkDB database hostname, port and name.
**Example using environment variables**
```text
export BIGCHAINDB_DATABASE_HOST=localhost
export BIGCHAINDB_DATABASE_PORT=28015
export BIGCHAINDB_DATABASE_NAME=bigchain
```
**Example config file snippet**
```js
"database": {
"host": "localhost",
"port": 28015,
"name": "bigchain"
}
```
**Default values (a snippet from `bigchaindb/__init__.py`)**
```python
'database': {
'host': os.environ.get('BIGCHAINDB_DATABASE_HOST', 'localhost'),
'port': 28015,
'name': 'bigchain',
}
```
## server.bind, server.workers & server.threads
These settings are for the [Gunicorn HTTP server](http://gunicorn.org/), which is used to serve the [HTTP client-server API](../drivers-clients/http-client-server-api.html).
`server.bind` is where to bind the Gunicorn HTTP server socket. It's a string. It can be any valid value for [Gunicorn's bind setting](http://docs.gunicorn.org/en/stable/settings.html#bind). If you want to allow IPv4 connections from anyone, on port 9984, use '0.0.0.0:9984'. In a production setting, we recommend you use Gunicorn behind a reverse proxy server. If Gunicorn and the reverse proxy are running on the same machine, then use 'localhost:PORT' where PORT is _not_ 9984 (because the reverse proxy needs to listen on port 9984). Maybe use PORT=9983 in that case because we know 9983 isn't used. If Gunicorn and the reverse proxy are running on different machines, then use 'A.B.C.D:9984' where A.B.C.D is the IP address of the reverse proxy. There's [more information about deploying behind a reverse proxy in the Gunicorn documentation](http://docs.gunicorn.org/en/stable/deploy.html). (They call it a proxy.)
`server.workers` is [the number of worker processes](http://docs.gunicorn.org/en/stable/settings.html#workers) for handling requests. If `None` (the default), the value will be (cpu_count * 2 + 1). `server.threads` is [the number of threads-per-worker](http://docs.gunicorn.org/en/stable/settings.html#threads) for handling requests. If `None` (the default), the value will be (cpu_count * 2 + 1). The HTTP server will be able to handle `server.workers` * `server.threads` requests simultaneously.
**Example using environment variables**
```text
export BIGCHAINDB_SERVER_BIND=0.0.0.0:9984
export BIGCHAINDB_SERVER_WORKERS=5
export BIGCHAINDB_SERVER_THREADS=5
```
**Example config file snippet**
```js
"server": {
"bind": "0.0.0.0:9984",
"workers": 5,
"threads": 5
}
```
**Default values (from a config file)**
```js
"server": {
"bind": "localhost:9984",
"workers": null,
"threads": null
}
```
## api_endpoint
`api_endpoint` is the URL where a BigchainDB client can get access to the HTTP client-server API.
**Example using an environment variable**
```text
export BIGCHAINDB_API_ENDPOINT="http://localhost:9984/api/v1"
```
**Example config file snippet**
```js
"api_endpoint": "http://webserver.blocks587.net:9984/api/v1"
```
**Default value (from a config file)**
```js
"api_endpoint": "http://localhost:9984/api/v1"
```
## statsd.host, statsd.port & statsd.rate
These settings are used to configure where, and how often, [StatsD](https://github.com/etsy/statsd) should send data for [cluster monitoring](../clusters-feds/monitoring.html) purposes. `statsd.host` is the hostname of the monitoring server, where StatsD should send its data. `stats.port` is the port. `statsd.rate` is the fraction of transaction operations that should be sampled. It's a float between 0.0 and 1.0.
**Example using environment variables**
```text
export BIGCHAINDB_STATSD_HOST="http://monitor.monitors-r-us.io"
export BIGCHAINDB_STATSD_PORT=8125
export BIGCHAINDB_STATSD_RATE=0.01
```
**Example config file snippet: the default**
```js
"statsd": {"host": "localhost", "port": 8125, "rate": 0.01}
```