* fixed chardet version to 3.0.4
Signed-off-by: Jürgen Eckel <juergen@riddleandcode.com>
* defined working version of jinga2
Signed-off-by: Jürgen Eckel <juergen@riddleandcode.com>
* removed obsolete doc building commands
Signed-off-by: Jürgen Eckel <juergen@riddleandcode.com>
* defined werkzeug version explicitly
Signed-off-by: Jürgen Eckel <juergen@riddleandcode.com>
* Dependencies update
Signed-off-by: David Dashyan <mail@davie.li>
* Dockerfile-dev: update python version + remove system pynacl
Signed-off-by: David Dashyan <mail@davie.li>
* Set dummy_transaction fixture scope to "session"
Signed-off-by: David Dashyan <mail@davie.li>
* Add 3.7 and 3.8 python tests
* setup.py: fix version typo
* Flask security update
The Pallets Project Flask before 1.0 is affected by: unexpected memory
usage. The impact is: denial of service.
The attack vector is: crafted encoded JSON data. The fixed version is:
1. NOTE: this may overlap CVE-2018-1000656.
Signed-off-by: David Dashyan <mail@davie.li>
* Make send_naughty_tx error regex more robust
Signed-off-by: David Dashyan <mail@davie.li>
* Reorganized docs
* Fixed internal links in basic usage
* fixed the docker-compose command and volume for docs
* fixed docs tests
* fix travis docs test
* tox ini file
* fixed readme localhost links
* edited tox and test docs to previous state
* Fix tests errors related to docs reorganization
Signed-off-by: David Dashyan <mail@davie.li>
* Added ansible script installation option
Signed-off-by: Lana Ivina <lana@ipdb.io>
* Added ansible script to network setup guide
Signed-off-by: Lana Ivina <lana@ipdb.io>
* Hid the non-working button for now.
Signed-off: Lana Ivina <lana@ipdb.io>
* Try now button
Co-authored-by: David Dashyan <mail@davie.li>
Problem statement:
BigchainDB v2.0.0b9 has been around for quite a while. Recently we have updated
Tendermint supported version to v0.31.5 which has incompatible blockchain.
Despite the fact that we have defined instructions on chain migration, no one
expected to migrate to incompatible chain within patch version range. So there
is a demand for Tendermint v0.22.8 compatibility among BigchainDB users.
Work has been done:
bigchaindb-abci package was upgraded to support multiple API versions.
New configuration field stating tendermint version was added.
Signed-off-by: David Dashyan <mail@davie.li>
From version 3.6+ mongodb by default binds only to localhost (127.0.0.1) IP. That can be checked with "netstat -tulpn | grep LISTEN" command in container. It will return "127.0.0.1:27017 | 0.0.0.0:* | LISTEN | 15/mongod" for mongod. That causes inability to connect to running mongo from host machine. Proposed change allows mongo to bind to container network interface, thus allowing connections from host machine.
* added last_tx switch to the TX get query to only get the latest TX for a given asset.
* extended test case to contain last_tx field
* Add last_tx option in query module
* Fix natural descending cursor sort argument
Since version 3.10, Alpine linux has removed mongodb from the available packages.
Using v3.9 it's still possible to build the all-in-one configuration using the provided Dockerfile.
Signed-off-by: Giuseppe Raveduto <giuseppe.raveduto@eng.it>
To account for sporadic failures on bigchaindb server and container stop, it would be beneficial to include in docker-compose the ability for the containers to restart on failure or docker daemon restart. Issue #2624
in the intro page about the Simple Deployment Template:
- removed the note about the BigchainDB Testnet for now
- changed the link to the docs about contributing to BigchainDB from Markdown to RST
* Updated changelog for 2.0.0b7
* Change 2.0.0b3 to b7 in network-setup.md
* Updated k8s yamls for 2.0.0b7 release
* Updated version.py for 2.0.0b7 release
1. Save pre-commit state in the beginning of end block.
2. Provide an interface for custom elections to rollback on crash recovery.
3. Simplify pre-commit management.
4. Add crash recovery for updert-validator and chain migration elecitons.
* Copy-edited the log rotation page (docs)
* Fix and add some hyperlinks re/ logging.
* Add back the section/link to log-rotation.html
* Correct the location of BigchainDB logs. Omit mention of bigchaindb-benchmark.log
* Revive notes re BigchainDB Server log rotation
* Problem: Outputs API doesn't respond with correct unspent/spent outputs
Solution: Fix fastquery such that embedded document is queried properly
* Problem: key order agnostic queries not implemented
Solution: get_spent queries embedded documents which respect key order. This is
not expected by the application hence the query should be altered to query any
kind of key order
* Problem: Mongo query for get_spent too complicated
Solution: Simplify query using $elemMatch
* Problem: No test for checking mixed spent outputs
Solution: Add test for `get_spending_transactions` to check that correct
matching is done when querying documents with multiple inputs
* Problem: tranasction ids not assert when getting spent outputs
Solution: assert tranasction ids
* Separate pending and effective validator updates.
- Pending validator updates do not prevent elections from concluding.
- ValidatorElection overrides has_conclude to not conclude when there is a pending update for the matching height.
- Effective validator updates deem past elections inconclusive.
* Problem: Looking for election block is inefficient.
Solution: Record placed elections, update the records upon election conclusion.
* Clarify the conclusion order in Election.process_blocks.
* Insert election records in bulk.
Otherwise, one can significantly slow nodes down by posting a whole bunch of unique elections.
* Change get_election to use find_one.
* Calculate total votes without making extra query.
* Fix the pending valset check.
* Fix election test setup.
- Do not conclude migration election if there is a migration in progress.
- Rewrite election tests to not use mocks and assert many different things.
- Record concluded elections in the `election` collection.
* Problem: HTTP info endpoints don't include "blocks"
Solution: Add "blocks" to the response to the HTTP info endpoints
* Removed "blocks" endpoints from "Advanced Usage"
because they are really not that advanced
* Problem: We need a way to synchronize a halt to block production to allow for upgrades across breaking changes.
* Solution: Created `MigrationElection`.
* Problem: Need documentation for `migration` elections.
* Solution: Updated the docs.
* Problem: `MigrationElection` needs 'new' CLI method.
* Solution: Updated the definition of `election` to include the new `migration` type.
* Problem: The way `end_block` checks for concluded elections assumes there is only one type of election (so we can't conclude an `upsert-validator` and a `chain-migration` at the same height).
* Solution: Re-engineered the code in `Elections` to conclude multiple elections in the same block. If more than one election change the validator set, only one of them is applied.
* Problem: Tendermint change to store validator changes at height h+2 will break `Election.get_status`.
* Solution: Reworked `get_validator_change` to look at only the latest block height or less.
- Hard-wire the supported Tendermint version(s) right in the code of BigchainDB Server. Check the version of Tendermint and disconnect if Tendermint version is an unsupported one.
- Expose a CLI command bigchaindb tendermint-version to display the supported Tendermint versions.
- PR also takes care the long list of warnings we get when we run tests.
- Updated deprecated pymongo methods
- Do not call pytest fixtures directly.
- Also added the doc for the new cli command
Solution: parallelize the validation of transactions. This patch adds a
new flag for the `start` command, namely
`--experimental-parallel-validation`, that can be used to enable this
experimental feature.
Solution: Stop getting events from the Tendermint events API. Get the
event right before returning from the COMMIT phase of Tendermint, and
publish it to the events queue.
* Problem: `ValidatorElection` and `MigrationElection` need to inherit from a common `Election` class
Solution: Factored the common logic out of `ValidatorElection` and moved it to `Election` parent class
* Problem: Adding base58 as a requirement seems to break the build...
Solution: Reverting the changes
* Problem: Responding to a suggestion for improved method naming
Solution: Refactored `get_result_by_election_id` to `get_election_result_by_id`
* Problem: No need to store different types of elections in their own tables
Solution: Remove `DB_TABLE` property from `Election` class
* Revert "Problem: No need to store different types of elections in their own tables"
This reverts commit db45374d3c690429d18a25bcc319f8056c016500.
* Problem: Missed a method in `Bigchain` class when updating the naming for an election method
Solution: Finished the refactoring
* Problem: Need a table to store data for all elections
Solution: Created the `elections` table with secondary_index `election_id`
* Problem: `Election` class needs to be updated to store concluded elections in the `elections` table
Solution: Updated the class to use the new table
* Problem: `UpsertValidatorVote` can be generalized to just be `Vote`
Solution: Renamed, refactored and moved the `Vote` class to tie in with the more general `Election` base class
* Problem: Error in docstring return signature
Solution: Fixed the docstring
* Problem: Hardcoded reference to the `VOTE_TYPE` in `Election` base class
Solution: Pointed the reference to the class variable
* Problem: Schema still refers to `ValidatorElectionVote` instead of `Vote`
Solution: Renamed `TX_SCHEMA_VALIDATOR_ELECTION_VOTE` as `TX_SCHEMA_VOTE`
* Problem: `Election` class variable `ELECTION_TYPE` is overly specific
Solution: Renamed `ELECTION_TYPE` to `OPERATION`
* Problem: Command line options for `upsert-validator` can be generalized to manage any type of election
Solution: Refactored the CLI to manage generalized elections
* Problem: Default for `show_election` not implemented for `Election` class
Solution: Create a default method that work if all fields in the 'asset[data]' can be displayed without additional formatting
* Problem: Multiple small issues with style etc.
Solution: Addressed comments from PR
* Problem: `Election` class variable to `VOTE_TYPE` unnecessary
Solution: Removed the variable and hardcoded everything to use the `Vote` class
* Problem: Minor style issues with PR
Solution: Addressing comments
* Problem: Changes to format for validator keys broke some tests
Solution: Aligned the tests to reflect the changed key format
* Problem: `election show` command displaying the base56 public key
Solution: Cast any public key to base64
* Problem: `election_parser` help message still refers to upsert-validator
Solution: Updated the help message
* Log rotation for tendermint and BigchainDB using Monit
* Change file size from 100KB used for testing to 200 MB for test envs
* Add docs for log rotation
* remove --consensus.create_empty_blocks from monit start
Because already taken care of in the config file
* do not run bigchaindb with debug flag instead use config file
* Address comments I
- Rephrase log rotation to imply monit is not default
- Add statement to explain where bigchaindb log files are created
- Fix HTML comment
- Add log rotation to index
* Address comments II
* Problem: `ValidatorElection` and `MigrationElection` need to inherit from a common `Election` class.
Solution: Factored the common logic out of `ValidatorElection` and moved it to `Election` parent class.
* Problem: No need to store different types of elections in their own tables
Solution: Remove `DB_TABLE` property from `Election` class.
Solution: Created the `elections` table with secondary_index `election_id`.
* Problem: `UpsertValidatorVote` can be generalized to just be `Vote`
Solution: Renamed, refactored and moved the `Vote` class to tie in with the more general `Election` base class.
* Problem: `election_id` is not unique if two elections have the same properties.
Solution: Added a random `uuid4` seed to enforce uniqueness.
Solution: Change the docs to recommend installing a specific Tendermint version.
Also update our release process so we change that version number before a release, if necessary.
* Problem: we have unused and outdated fixtures
Solution: clean up fixtures and tests accordingly
* Problem: there are still unused fixtures
Solution: remove Merlin keys
* Problem: There are unnecessary markers
Solution: remove the tendermint marker for tests
* Problem: The commit mode behaves incorrectly.
Solution: Parse the Tendermint response properly. The functionality was disabled in https://github.com/bigchaindb/bigchaindb/pull/2235/files#diff-c6511560546a7dc577e7e647b5bfdaceL68 and was not fixed since then.
* Add a test case for the sync mode.
* Do not strictly expect deliver_tx in the response.
* Fix post_mock in web/test_transactions.py.
* Check for the error field first.
Solution: Document when the transactions posted in the async and sync modes can be lost. Describe how they are stored. Mention that BigchainDB does not store or expose rejected transactions.
The information on that page was either wrong or redundant, so I either deleted it or linked to where to find the same information in the docs about contributing to BigchainDB.
* Problem: No good way to check for val set absence.
Solution: Make get_validator_set/get_validators return None/[] when there are no validators yet.
* Problem: Incompatible ABCI chain upgrades.
Solution: Record known chains and sync through InitChain. Triggering the migration and adjusting other ABCI endpoints will follow.
Solution: Election ID has to be unique but not every validator set record has it. MongoDB does not support partial indexes, does not even allow for multiple Nones. This is a temporary fix since we are introducing an `election` collection to store election IDs in #2498.
* Problem: cyrptoconditions dependency updated because of vulnerability CVE-2018-10903
* update cc to ~=0.7.2
* Fix test using b58encode
* Fixing some more tests failing because of base58 update
Solution: Remove un-necessary code. Deployment of MongoDB with or without replicaSet should be the responsibility of MongoDB admin which can and cannot be a BigchainDB node operator. As far as BigchainDB is concerned replicaset, if provided in bigchaindb configs, should be used to establish connection with MongoDB.
* Problem: We need to store the `election_id` as part of the `validator_update` so we can efficiently check which election was resposible for the change
Solution: Added the parameter to `store_validator_set` and aligned the tests
* Problem: Logic for `upsert-validator show` is convoluted
Solution: Rewrote the function to be much simpler
* Problem: Need a uniqueness constraint for election_id wrt validator changes
Solution: Added a new key to the db schema
Solution: BigchainDB by default writes logs in the same directory it is
run. The `looponfail` feature provided by pytest waits for changes in
the current directory, so it is continuously triggered. This patch tells
pytest to only watch the `bigchaindb` and `tests` directories.
Solution: if a TRANSFER transaction is validated after a CREATE
transaction, the system crashes with `AttributeError: 'NoneType' object
has no attribute 'txid'`.
This happens because querying `get_spent` checks the attributes `txid`
and `output` of `input.fulfills` for every transaction in the current
buffer (`current_transactions`). For a CREATE, `input.fulfills` is None,
so the check would fail.
The solution is to check if `input.fulfills` is defined. If not, then
the current transaction cannot spend any output, so we can safely skip
it.
Solution: Transfer vote to the election public key; generalize implemenation to handle election txn type
* Problem: Upsert valdiator 'new' doesn't accept public in base64 format
Solution: Tendermint stores all keys in base64 format so it would suitable to
abandon base58 encoding in favour of base64 encoding
* Problem: Not test for invalid execution of upsert-validator 'new'
Solution: Write tests to when invalid power or private key path has been supplied
* Problem: Exceptions are not informational when executing upsert-validator
Solution: generate error logs or print statement indicating success
Solution: have a more general approach to process transaction types. If
a transaction does *not* contain `asset.id`, then the `id` of the
`asset` is the `id` of the transaction.
* Problem: `run_upsert_validator_approve` was getting the voting power in a convoluted way
Solution: Changed it to get the voting power from the election outputs
* Problem: `run_upsert_validator_approve` casts votes for *all* voters, not just the user calling the command
Solution: Filter vote txs by the users public key
* Problem: Docs needed a more specific description of how to input the path to the private-key file
Solution: Changed the wording a bit
* Problem: several tests are skipped
Solution: activate or remove tests
* Problem: store_transaction is deprecated
Solution: replace it with store_bulk_transaction
* Problem: we don't test the transaction split
Solution: undelete `test_store_transaction`
* Problem: failing tests
Solution: merge master and change deprecated store_transaction
* Problem: tests in test_bigchain_api are not activated
Solution: remove or active tests
* Problem: TransactionNotInValidBlock was removed
Solution: remove TransactionNotInValidBlock from tests
* Problem: Config settings docs missing some configs & inconsistent
Solution: Document some undocumented config settings and make the config settings docs page more consistent
* Problem: No docs about how config setting env var name determined
Solution: Explain and show the relationship between the config-file name and the environment variable name of config settings
* Problem: Source files contain no license info
Solution: Add comments with SPDX license info to source files
* Python 3 files don't need # -*- coding: utf-8 -*-
* Problem: core.py contains an unused class, `Bigchain`
Solution: Remove core.py. Refactor BigchainDB Class to remove inheritance from Bigchain.
* Fixed flake8 complaint about too many blank lines
* Attempting to fix Sphinx docs. This may result in some redundant commits, as I don't know what I'm doing, and I can't experiment without running the CI...
Sorry in advance!
* Updating from master changed BigchainDB.process_post_response to a private method, so I had to align with that.
* Fixed a couple stale references to bigchaindb.Bigchain in docstrings
* Missed a reference to `Bigchain` in a patch call...
* Problem: Tests in class `TestBigChainAPI` from `tests/db/test_bigchain_api.py` were disabled
Solution: Fixed the tests that still made sense, and deleted the rest.
* Problem: Flake8 style complaints
Solution: Made things prettier
* Problem: Debugging comments were slightly NSFW
Solution: Deleted the debugging comments
* Problem: Stale use of `pytest.mark.genesis` decorator on these tests
Solution: Removed the decorator
* Problem: CriticalDoubleInclusion exception was no longer used anywhere in the code
Solution: Deleted it
* Problem: Unused exception `GenesisBlockAlreadyExistsError`
Solution: Deleted it
* Problem: I removed a test that covered writing to the DB and checking that everything is stored faithfully
Solution: Replaced it and got it working again
Solution: In the docs page listing the Community-Driven Libraries and Tools, make it clear that they might not work with the latest version of BigchainDB. Make it a warning rather than a note.
* Problem: Need a method to initiate a new upsert-validator election
Solution: Added subcommand `new` to `upsert_validator`
* Problem: Changes to upsert-validator needed to be reflected in the docs
Solution: Wrote a section for `upsert-validator new`
- Make the title of the asset search section consistent with the example (and consistent with the metadata search title and example).
- Add a note that one can use `asset?search` or `asset/?search`, and the same for metadata.
* Problem: all blocks are valid
Solution: remove the status from transactions
* Problem: changed the return type of get_transaction_filtered
Solution: return tx class instead of dict
Solution: Random failure of test
`tests/test_events.py::test_event_handler_raises_when_called_after_start` seem
to be because of `get_nowait` which returns way to quickly even when the queue
has data. Increasing timeout seems to fix the issue.
Solution: Modify the file `HOW_TO_HANDLE_PULL_REQUESTS.md` to point its readers to the new document about how to handle external pull requests: [BEP-16](https://github.com/bigchaindb/BEPs/tree/master/16).
* Problem: core.py contains an unused class, `Bigchain`
Solution: Remove core.py. Refactor BigchainDB Class to remove inheritance from Bigchain.
* Problem: core.py contains an unused class, `Bigchain`
Solution: Remove core.py. Refactor BigchainDB Class to remove inheritance from Bigchain.
* Fixed flake8 complaint about too many blank lines
* Attempting to fix Sphinx docs. This may result in some redundant commits, as I don't know what I'm doing, and I can't experiment without running the CI...
Sorry in advance!
* Attempting to fix Sphinx docs. This may result in some redundant commits, as I don't know what I'm doing, and I can't experiment without running the CI...
Sorry in advance!
* Updating from master changed BigchainDB.process_post_response to a private method, so I had to align with that.
* Fixed a couple stale references to bigchaindb.Bigchain in docstrings
* Missed a reference to `Bigchain` in a patch call...
* Problem: some tests are not activated
Solution: activate and remove or fix tests
* Problem: accidentally un-skipped test_get_blocks_status_containing_tx during merge
Solution: Replaced the skip
* Problem: Validator set not tracked by BigchainDB
Solution: BigchainDB depends on tendermint's RPC API to get the validator set
which is not avaiable during replay so the validators set should be tracked
inside BigchainDB
* Problem: Unclear code and documentation
Solution: Fix decode_validator and docs strings
* Problem: Doc strings missing
Solution: Add doc string for store_validato_set
* Problem: Docs should say more about how to handle privacy & private data
Solution: Write a new docs page about that
* Problem: Server docs say little re/ prod. node security & privacy
Solution: Create a new docs page, "Production Node Security & Privacy"
* Address initial comments from @gautamdhameja
* Problem: Node operator cannot vote on a ValidatorElection
Solution: Implement validator election voting spec
* Problem: Incorrent code comments
Solution: Update comments with correct context
* Problem: Delegated vote not casted back to election
Solution: Update test to cast votes back to election id and assert their validity
* Last PR before the release of BigchainDB 2.0 Beta 5
* Fix editing error
* Change development status back to 4 - beta
* Rephrase some fixes I
* Rephrase some fixes II
* Problem: Stateful validation doesn't raise double spend exception
Solution: Transaction.validate should raise exception DoubleSpend if the given
transaction is already a part of the database
* Problem: Double spend exception message not accurate
Solution: The exception message should state that the double spend is because of
spending the same input more than once in the transaction
Solution: It might be related on how aiohttp 2.x handles `send_str`.
AFAIK the call `send_str` was not "fully async". In aiohttp 3.x they
[changed it][1]:
> send_str(), send_bytes(), send_json(), ping() and pong() are genuine
async functions now. (#2475)
So this patch adds support for aiohttp 3.x, and uses the `send_str`
coroutine.
[1]: https://github.com/aio-libs/aiohttp/blob/master/HISTORY.rst#deprecations-and-removals-1
* Problem: core.py contains an unused class, `Bigchain`
Solution: Remove core.py. Refactor BigchainDB Class to remove inheritance from Bigchain.
* Problem: core.py contains an unused class, `Bigchain`
Solution: Remove core.py. Refactor BigchainDB Class to remove inheritance from Bigchain.
* Fixed flake8 complaint about too many blank lines
* Attempting to fix Sphinx docs. This may result in some redundant commits, as I don't know what I'm doing, and I can't experiment without running the CI...
Sorry in advance!
* Attempting to fix Sphinx docs. This may result in some redundant commits, as I don't know what I'm doing, and I can't experiment without running the CI...
Sorry in advance!
* Updating from master changed BigchainDB.process_post_response to a private method, so I had to align with that.
* Fixed a couple stale references to bigchaindb.Bigchain in docstrings
* Missed a reference to `Bigchain` in a patch call...
* Problem: BigchainDB class should be part of project root
Solution: Removed the /tendermint directory and moved its contents to project root
* Problem: Flake8 complained that imports were not at the top of the file
Solution: Had to play around with the order of imports to avoid cyclic dependencies, but its working and style compliant now
* Problem: Stale reference to /tendermint directory in the index
Solution: Removed the references to /tendermint
* Problem: Flake8 complaining of unused import in __init__.py
Solution: The import is there so I can import App directly from bigchaindb, rather than from bigchaindb.core (which I think improves code readability. I added a # noqa to silence Flake8.
* Problem: Stale references to `bigchaindb.tendermint.BigchainDB` in the rst files cause Sphinx to fail
Solution: Updated the autodoc files to use `bigchaindb.BigchainDB` instead
* Problem: Stale reference to the `tendermint` directory in an @patch in a disabled test
Solution: Updated the @patch for completeness
* Problem: BigchainDB class should be part of project root
Solution: Removed the /tendermint directory and moved its contents to project root
* Problem: Flake8 complained that imports were not at the top of the file
Solution: Had to play around with the order of imports to avoid cyclic dependencies, but its working and style compliant now
* Problem: Stale reference to /tendermint directory in the index
Solution: Removed the references to /tendermint
* Problem: Flake8 complaining of unused import in __init__.py
Solution: The import is there so I can import App directly from bigchaindb, rather than from bigchaindb.core (which I think improves code readability. I added a # noqa to silence Flake8.
* Problem: Stale references to `bigchaindb.tendermint.BigchainDB` in the rst files cause Sphinx to fail
Solution: Updated the autodoc files to use `bigchaindb.BigchainDB` instead
* Problem: Stale reference to the `tendermint` directory in an @patch in a disabled test
Solution: Updated the @patch for completeness
Solution: when a transaction is stored, the system splits it in three
components, data, metadata, and the other fields of the transaction.
When the system retrieves a transaction, it needs to make three
different queries to reconstruct the original transaction. If a
transaction does not exist, the system does three queries anyway, even
if just one query is enough. This patch fixes this by doing the
additional queries if and only if the transaction exists.
* Fixed 2 PEP257 compliance errors
* Upgrade Tendermint to 0.19.7 except for Docker image, which is still at 0.19.2
* Problem: Docs say Crypto Conditions are part of ILP
Solution: Edit the docs so they no longer say that
* Problem: The write-a-bep page/process is daunting
Solution: Make the BEP writing process easier and more approachable
* Problem: BEP should be written uppercase
Solution: Change bigchaindb/BEPs label names to use uppercase "BEP"
* Updated CHANGELOG.md for the 2.0b2 release
* Update bigchaindb docker image names for k8s for the 2.0b2 release
* Update version.py for the 2.0b2 release
* In CHANGELOG.md, added note re port 46657->26657
* Update to tendermint version 0.22.3 for dev/test deployment docs and scripts
* Update version and parameters for 0.22.3
- Sync docker-compose
- Power should be a "string" not a int,uint
* Problem: core.py contains an unused class, `Bigchain`
Solution: Remove core.py. Refactor BigchainDB Class to remove inheritance from Bigchain.
* Problem: core.py contains an unused class, `Bigchain`
Solution: Remove core.py. Refactor BigchainDB Class to remove inheritance from Bigchain.
* Fixed flake8 complaint about too many blank lines
* Attempting to fix Sphinx docs. This may result in some redundant commits, as I don't know what I'm doing, and I can't experiment without running the CI...
Sorry in advance!
* Attempting to fix Sphinx docs. This may result in some redundant commits, as I don't know what I'm doing, and I can't experiment without running the CI...
Sorry in advance!
* Updating from master changed BigchainDB.process_post_response to a private method, so I had to align with that.
* Fixed a couple stale references to bigchaindb.Bigchain in docstrings
* Missed a reference to `Bigchain` in a patch call...
* Merge with master and re-do some changes
* Problem: we don't have any tests for malicious strings
Solution: Use a parameterized test that fuzzes over a library of potentially hazardous strings
* Needed to update the Dockerfile to install blns
* Removed unnecessary import from Dockerfile-dev
* Made the conditions under which the test expects an error more explicit
* Improved reporting in case of a bad status code
* Removed some over-zealous assertions.
* Removed `sent_transaction` from assertation error response
* *Problem: blns was removed as a dependency while fixing a merge conflict
Solution: added it back to the Dockerfile
* *Problem: made a typo when adding blns to the Dockerfile
Solution: fixed the typo
* Problem: 2 implementations of fastquery exist.
Solution: Remove the old deprecated implementation. Update the tests.
* Problem: There are still 3 outdated fastquery tests.
Solution: Fix the tests.
* Problem: Tendermint configuration not present in BigchainDB config
* Handle tendermint configurations properly
- Update docs
* Nitpick
* Missed some conflicts
* Make changes in tendermint/lib.py instead of deprecated core.py
- Also remove redundant info from docs about default values
* Fix docsserver automethod
* Problem: docs are not building anymore
Solution: add wget to the requirements for docs
* Problem: The Block class is deprecated
Solution: remove the block class and all occurrences
* Problem: voting code is not used anymore
Solution: remove all voting related code
* Problem: Some voting functionality is still present.
Solution: Remove it. Update some of the related tests.
* Problem: some skipped tests are now running
Solution: remove pytest mark to not run them
* Problem: fastquery is not related to votes
Solution: remove it in another PR
Solution: Remove the current pub/sub based logging infra as this model is no longer necessary. This can now be replaced by a simple system level logging config.
* Problem: BigchainDB config has stale/deprecated parameters
- Remove `keyring` and `keypair` from config
- Update tests
- Add `tendermint` config
* Fix flake8
* Update some naming conventions and redundant changes
* Remove redundant routine `fast_query`
* Remove deprecated parameters and descriptions
* remove some more unwanted code
* Problem: Two flake8 errors made Travis fail
Solution: Fix the two flake8 errors
* Address comments
- Remove reference of nodes_except_me and me_private and me
as attributes of BigchainDB instances
- Update and re-add test(s)
- Do not introduce `tendermint` in configuration instead handle that
in a separate PR along with docs
* Address comments
- Remove tests that are already covered with 2.0
- Remove tests that are no longer relevant
- Add TODO for more cleanup
* Remove tendermint config from configure command
* Copyedit simple-network-setup completeness & grammar
* Problem: Member doesn't know their BigchainDB Root URL
Solution: Add a section to tell the Member their BigchainDB Root URL
* Problem: Operator doesn't know how to reset their node
Solution: Add a section with commands an operator can use to reset their node
* Problem: Repeated previous sentence w/o changing it
Solution: Repeat previous sentence but change 'BigchainDB' to 'Tendermint' and delete the parenthetical sentence about MongoDB
* Address the comments by @vrde
* Fixed 2 PEP257 compliance errors
* Upgrade Tendermint to 0.19.7 except for Docker image, which is still at 0.19.2
* Problem: backlog_reassign_delay is defunct but still listed
Solution: remove all mentions of & calls for backlog_reassign_delay
* Fixed 2 PEP257 compliance errors
* Upgrade Tendermint to 0.19.7 except for Docker image, which is still at 0.19.2
* In the Appendices, update page re/ The Bigchain Class
* Update CHANGELOG.md for 2.0 Beta 1 release
* Changed 2.0.0b1 release date to 2018-06-01
* k8s: Updated bigchaindb docker image tag to 2.0.0-beta1
* Updated version.py for the 2.0 Beta 1 release
* Updated dev status to '4 - Beta' in setup.py for the 2.0 Beta 1 release
Solution: Remove the "team bot" from the `codecov.yml` file.
I installed Codecov on all "bigchaindb" (GitHub organization) repos today, so we can remove the "team bot", according to [the Codecov docs](https://docs.codecov.io/docs/team-bot), i.e.
> The best way to integrate with Codecov is to Install Codecov's GitHub Integration.
> Once installed, you are done! You do not need to set a Team Bot because Codecov will use the integration to post statuses and comments.
* Problem: API returns 404 for existing empty blocks
Solution: Empty blocks are not store in MongoDB because Tendermint does
not notify BigchainDB about them. In case a user requests a block that
is not in our MongoDB, we check if the requested height is less than or
equal to latest_block_height. If that's the case, we return an empty
block. If the requested height is greater than latest_block_height, then
we return 404.
* Address Lev's comment
* address Lev and Vansh comment
* Problem: No automated way to set up a dev/test network
* Problem: docs not updated for stack, ansible and docker based dev environments
* Problem: Using apt triggers java runtime installation on MacOS
- Update pre_tasks in ansible
- Update bigchaindb-stop playbook to handle pre_tasks
* Update Tendermint version to 0.19.3 from 0.19.2
* Update tendermint version to 0.19.3 everywhere else
* Problem: Sphinx warns about duplicate section labels
Solution: Don't use sphinx.ext.autosectionlabel
* Problem: Sphinx complains that run-node-with-docker not in any TOC
Solution: Add run-node-with-docker to a TOC (i.e. to an index.rst file)
* Tendermint has not tagged `0.19.3` container
* Problem: Internal hyperlinks to new pages not working
Solution: Add .html to the ends of the filename strings
* Problem: Invalid script imports
* Problem: Invalid comparison for supported OS version
* Addressing comments I
* Problem: No way to configure dev/forked repo for developers
* Problem: Docs not updated with STACK_REPO parameter
* Addressing comments II
* Problem: RethinkDB, change feed, old mongo, admin interface are not supported any longer.
Solution: Remove unsupported functionality. Bring the MongoDB backend implementation completely to the localmongodb package. Fix the test setup.
* Problem: Nothing depends on multipipes any longer.
Solution: Remove multipipes from setup.py.
* Problem: The how-to-run-tests doc uses --database-backend.
Solution: Do not include the --database-backend option into the documented pytest usage.
* Problem: The backends docs are outdated.
Solution: Document MongoDB as the default and only backend for BigchainDB.
* Problem: The inputs fixtures uses old blocks API.
Solution: Change the inputs fixtures to use the new blocks API.
* Problem: rethinkdb package is not used anymore.
Solution: Remove the rethinkdb dependency from setup.py.
* Problem: The abci-marked tests use outdated Mongo conn.
Solution: Replace MongoDBConnection with LocalMongoDBConnection for them.
The release process had some "Post-Release Steps" but I haven't been doing them lately. What were they?
The idea was to change the version number so that someone working on the `master` branch would see a version number reflecting what the `master` branch is. For example, if version 0.9.0 was just released, then the `master` branch would be changed to have the version number 0.10.0.dev, to indicate that it's the in-development version of 0.10.0.
My thinking now is that if someone is developing new code, then they don't need the version number to help them remember what they're doing. Moreover, if someone purposefully changes the docs to view the `master` branch docs, then they probably know what that means, and they don't need help from a version number.
* Problem: BigchainDB does not support newer MongoDB
Solution: Update driver to the last version, that is compatible with all
versions of MongoDB
* Update to MongoDB 3.6
* Updated CHANGELOG.md for version 2.0 Alpha 5
* Updated image tags in k8s files for 2.0 Alpha 5
* Updated version.py for 2.0 Alpha 5
* Problem: Missing alpha5 image update for test network containers
* Problem: CHANGELOG not updated with 2284
* Problem: Liveness probe frequency change not the important
* Problem: acceptance-test suite is not documented
Solution: add README.md in the root of the acceptance tests, unify
`Makefile` and commands, remove more cached files when `make clean` is
ran.
* Problem: documentation does not mention Makefile
Solution: update docs with our new and shiny commands
* Initial CHANGELOG.md edits for the 2.0 Alpha 4 release
* Added PR #2275 to CHANGELOG.md for the 2.0 Alpha 4 release
* Update k8s image tags for the 2.0 Alpha 4 release
* Update version.py for the 2.0 Alpha 4 release
* Problem: Amount error is not tested on the HTTP level.
Solution: A failed web test to reproduce the problem.
* Problem: Invalid transaction posted to Tendermint
Solution: Pass the exception to HTTP POST handler function
* Problem: DoubleSpend and CriticalDoubleSpend not differentiated
Solution: Handle these exceptions differently in `get_spent`
* Problem: No test for checking exception DoubleSpend and CriticalDoubleSpend
Solution: Add necessary tests
* Problem: find doesn't raise IndexError
Solution: Remove exception handling for IndexError
* Initial CHANGELOG.md updates for 2.0 Alpha 3
* More updates to CHANGELOG.md for 2.0 Alpha 3
* Added note in CHANGELOG.md about the bigchaindb-abci package we're using for now
* Updated Docker image tags to bigchaindb/bigchaindb:2.0.0-alpha3
* Updated version.py for BigchainDB 2.0 Alpha 3
* Problem: Upsert validator not migrated to Tendermint 0.19.0
Solution: Migrate the same to Tendermint 0.19.0
* Problem: There are no tests for public key encoding/decoding
Solution: Add necessary tests
Solution
As per Tendermint 0.16.0 , --p2p.seeds is now --p2p.persistent_peers. Update bigchaindb/tendermint container to use that configuration. Also disable --p2p.pex, we currently don't want the peer exchange.
Solution
Since BigchainDB and Tendermint are so tightly coupled we need to introduce a process supervisor to make them act like a single microservice, so that if BigchainDB crashes, Tendermint does as well and both are restarted and Tendermint requests a connection towards the proxy app.
In Kubernetes, they can be exposed as part of a one POD.
For BigchainDB as a system service/process, we need to introduce a process supervisor such as systemd.
This PR only solves the former.
Changes
Upgrade deployment from Tendermint v0.12.0 to v0.19.0
Update some documentation
Fix nginx-http entrypoint issues.
Update generate-configs.sh script to handle config generation without https-certificates.
Update Dockerfile to process dependency links introduced by abci
Integrate BigchainDB and Tendermint as a single microservice.
This required making BigchainDB to be exposed as a statefulset.
Introduce new liveness probe checks.
Issues Resolved
Partially fixes#2232
* remove max_tries while connecting to tendermint ws
Signed-off-by: Shahbaz Nazir <shahbaz@bigchaindb.com>
* leave healthcheck as is for now
Signed-off-by: Shahbaz Nazir <shahbaz@bigchaindb.com>
* Problem: No docs explaining use of MongoDB for querying
Solution: Start a new root docs page explaining how a node operator can use the full power of MongoDB's query engine, and can expose as much of that as they like to end users.
* Finished first draft of new docs page 'Querying BigchainDB'
Solution: Create a `LICENSE` file in this repo, containing the Apache v2 license, so that GitHub can detect the code license in this repo.
Please leave the `LICENSES.md` file. It also specifies the license on the documentation, and notes that some code is NOT licensed Apache v2 (i.e. the code we got from Runscope and modified).
This pull request was inspired by https://github.com/bigchaindb/bigchaindb-driver/pull/406 by @codegeschrei
* Initial update to CHANGELOG.md for the 2.0 Alpha 2 release
* Add Known Issues section to 2.0 Alpha 2 changelog
* Update Docker image tag to bigchaindb/bigchaindb:2.0.0-alpha2
* Update version.py for 2.0.0 Alpha 2
I changed the license from AGPL v3 to Apache v2 in January. See pull request #2020
Somehow, the license got changed back to AGPL without us noticing. It was noticed by @dscook who asked us about it on Gitter, see https://gitter.im/bigchaindb/bigchaindb?at=5ad0cfc66d7e07082bef276b
This pull request changes the license back to Apache v2, which is what it should have been ever since January.
* Problem: docker image tag wrong in dev-setup/bigchaindb.yaml
Solution: change the docker image tag to 2.0.0-alpha in that file
* Problem: version.py needed updating for 2.0 Alpha
Solution: Updated the contents of bigchaindb/version.py for the release of 2.0.0 Alpha
* Update CHANGELOG.md for the 2.0 release
* Problem: BigchainDB 2.0 Alpha name & tag wrong in CHANGELOG.md
Solution: Name="BigchainDB 2.0 Alpha" tag="v2.0.0a1"
* Problem: Blogpost link missing & no Known Issues
Solution: Hyperlink the blog post with the missing link and
document the Known Issues.
* Problem: The 2.0 Alpha release date in CHANGELOG.md was wrong
Solution: Changed the release date of 2.0 Alpha to April 3, 2018 in CHANGELOG.md
* Problem: Some docs still say to run MongoDB w/ replica set
Solution: Update the relevant docs
* Problem: A docs mention of upsert-validator wasn't linked to BEP-3.
Solution: Link that docs mention to BEP-3 on GitHub.
Solution: update the documentation to reflect this. I've also removed
the documentation about the event plugin API. That part needs to be
refactored to work properly with BigchainDB 2.0. We can reintroduce it
later.
* Problem: Multi-threading not configured
Solution: Auto-generate multi-threading config with default threads and workers set to 1
* Problem: Documentation not updated for multi-threading
Solution: Updated necessary docs
* Problem: it's difficult to run/test/compile docs
Solution: we already have a nice Makefile, but it's outdated. The idea
is to revamp it and make it easy to use.
* Problem: Makefile is not documented
Solution: Add basic instructions on how to use it in the main README.md
* Problem: can't connect to localhost:9984
Solution: make docker expose 9984 by default, so everyone can connect to
localhost:9984.
* Problem: make clean is TMI
Solution: add `@` to remove commands so we don't output all the details
about the cleaning
* Problem: make clean is too shy
Solution: print a message saying that cleaning went well.
* Update setup.py for BigchainDB 2.0
I took the license name from this list of valid PyPI licenses:
https://jlesquembre.github.io/autopilot/license_list.html
* Remove 'Programming Language :: Python :: 3.6'
from `setup.py` since we actually use features from Python 3.6.
* Changed dev status back to 3 - Alpha for now
- Standardize docker-compose workflow
- Change docker-compose version to 2.1
- why one might ask? because compose version
3.0 does not support depends on and inherits
like we want to and is more aimed towards migration to using
`docker stack`, for our current strategy `2.1` is a better choice.
- change `bdb` service `bigchaindb` service
- why? Introduced a new proxy service `bdb` which is just a dummy
`busybox` image.
- why? because this ensure via healthcheck of bigchaindb that BigchainDB
has started properly and makes a `curl` to ensure HTTP API server is up
and running.
- why? Because we have had scenarios where BigchainDB is not started
via docker compose and user has to check out the logs to find out what
the problem might be. This ensure that bigchaindb is up and running.
- Does this change deployment workflow? No.
- The only thing change is that if you want to run commands inside a bigchaindb
container e.g. `pytest` now you have to run the following command:
`docker-compose run --rm --no-deps bigchaindb pytest -v --cov=bigchaindb`
as opposed to `docker-compose run --rm --no-deps bdb pytest -v --cov=bigchaindb`
- Remove env variable `BIGCHAINDB_START_TENDERMINT`
- Remove TENDERMINT_INTEGRATION.rst and move to the new docs
- Change mdb -> mongodb because the other services were named with
full name.
- Add example to run specific tests or from a file
- Update config.toml for tendermint to use `bigchaindb` as proxy app
instead of `bdb`
- Remove `network` directory because it is deprecated
- Add comment about why PYTHONBUFFERED is used
* Problem: Docs for BEP#3 implementation not updated
Solutions: Update docs for #2070 and #2106
* Problem: 'Validator update' docs language not clear
Solution: Re-write the documentation which explains when validators are updated
* Problem: Typos and BEP reference missing
Solution: Fix typos and add BEP reference
* Fix for access token authorization for GET calls
- Naming inconsistency for cluster-fqdn causing issues
- Change cluster-frontend-port to node-frontend-port
* Change hardcoded 9984 to configurable
* Testing tendermint docker compose for travis
* Typo tendermint*
* Re-do migrate cli changes
* don't skip event stream test
* Fix flake8 and unskip a test skipped during dev
* Revert styling changes made from editor
* skip a failing test case which was already disabled
* Remove reference to 'keypair' in commands
We manually add all the required configurations and secretes in config-map.yaml and secret.yaml. There is a need for a wrapper script which takes these generated mongodb certs and also process https certificates and populates config-map.yaml and secret.yaml
- Update docs for azure cluster deployment template
- Update entrypoint for MongoDB to handle user configuration
more efficiently
- remove `use admin` in js file, that is an invalid format
- Currently, we had to manually log into the MongoDB container
and create users, this change will configure the relevant users
from a single script `configure_mdb.sh`
- Improvements can be done but keeping it minimal for the workshop
Problem
The current production deployment template uses 3scale to ensure that POST requests to the network (from anyone) only get through if they come from a client with an account (app_id and app_key).
A private network wants to launch so that all HTTP requests (POST and GET) sent to the nodes in the network get be dropped unless they come from a small set of known (and unchanging) clients/sources. They don't need 3scale. They will want a modified version of the production deployment template.
Solution
Generate a special HTTP header and share it with all the known clients/sources.
Have a single NGINX in each node which checks for that HTTP header value. If it's present, let the request pass through to the network. (HTTP headers are encrypted if HTTPS is used.)
Are there other simpler or better options?
- Remove commands that were not required.
- export-my-pubkey
- set-shards
- set-replicas
- add-replicas
- remove-replicas
- Update bigchaindb --help, usage description
- Re-enable tests
- Update docker-compose.travis.yml and Dockerfile for travis
because some env variables are not needed
- No need to deprecate commands that are not needed because
tendermint integrated BigchainDB does not overlap with
BigchainDB(v1.x)
- Update some sets
- Add more commands and usage.
- Update imagePullPolicy from IfNotPresent to Always
for all unstable images we are using in k8s template,
because those images are updated regularly, we will
keep it unstable until the official release.
- Use Tendermint v0.13 as base docker image, since our current
integration is based out of v0.13
Description
Currently we manually configure ports in deployment and service files for k8s deployment e.g here. Instead these ports should be constant since these are always the same for each deployment
Issues This PR Fixes
Fixes#2077
- Created three new JSON Schema files for the v2.0 transaction schema, based on the v1.0 files. The only change is the allowed value of version (from "^1\\.0$" to "^2\\.0$").
- I didn't delete the v1.0 JSON Schema files because we might want those some day (to validate old transactions).
- Updated the __init__.py in the directory with the JSON Schema files so that it now uses the version 2.0 JSON Schema files.
- Updated all relevant tests. I only found one, in tests/validation/test_transaction_structure.py
- Updated VERSION in common/transaction.py
- Checked to make sure the example HTTP API docs show "version" with value "2.0". They do.
- Updated the docs page about "The Transaction Model". It just points to the IPDB Transaction Spec.
- If someone submits a transaction with "version" having value "1.0" then the error message comes from the JSON Schema checker.
* Replace double quotes with single quotes (flake8)
* Test event subscriber to tendermint via ws
* Problem: Tendermint is not part of stack for CI
Solution: Add Tendermint to stack for CI. For simplicity's sake
docker-compose is being used.
Solution: Only track config.toml and generate the other files such as
genesis.json and priv_validator.json in the container via `tendermint
init`
Related issue: #1997
- We need to pin this dependency because version 1.0.0 of yarl
does not expose `unquote` and if we do not pin it, the latest
version >=1.*.* is downloaded and `aiohttp` expects it.
- This can also be fixed on `aiohttp`, but meanwhile :)
- Separate deployments, services, statefulsets etc
`yaml` files for tendermint based deployment.
- Separate Dockerfiles for mongodb, nginx for
tendermint integrated BigchainDB.
- Template doc for BigchainDB + Tendermint single node
- Template doc for BigchainDB + Tendermint network
- Remove autosectionlabel extension from docs/server/source/conf.py
- Removed this extension because this does not allow two different
documents to have same headings, because it auto-indexes
- Fix and explicitly label headings and references.
In mongodb docker image STORAGE_ENGINE_CACHE_SIZE
will always be set to '' (two quotation marks)
and verification will fail. So it's impossible to
run image without --storage-engine-cache-size set.
This change removes double quotes while assigning
default value to STORAGE_ENGINE_CACHE_SIZE.
- BigchainDB does not use --init flag anymore
- Either we use `bigchaindb init` explicitly or `bigchaindb start --no-init`
other wise `bigchaindb start` implicitly does an init
- Metadata search was recently added and works seamlessly
- The endpoint was not reflected in the info view i.e.
when someone queries at root / or api/v1 endpoints.
- Handle unit tests for the change as well.
* Add standard template for creating PRs
Adding a standard template for creating
Pull requests for improved code QA and delegating
dependencies whenever applicable
Signed-off-by: Shahbaz Nazir <shahbaz@bigchaindb.com>
* Update developer docs with PR instructions
Signed-off-by: Shahbaz Nazir <shahbaz@bigchaindb.com>
* Addressing review comments for PR template
Signed-off-by: Shahbaz Nazir <shahbaz@bigchaindb.com>
Skip Referer check on preflight request (OPTIONS) and set Referrer-Policy to origin-when-cross-origin in response to OPTIONS request. Once Referrer-Policy is set on the subsequent POST request referrer is set by the browser to expected value.
* Remove testing for rethinkdb, mongodb, and Py3.5
* Add first tests
* Add validation
* Add command to start the ABCI Server
* Reuse existing MongoDB Connection class
* Use DuplicateTransaction
* Test only tendermint
* Update travis scripts
* Fix pep8 errors
* Update Makefile
In the Quickstart page of the docs, the BigchainDB Root URL (http://127.0.0.1:9984/) was being formatted as text (with a $ in front) rather than as an URL. I changed it to format like a clickable (linked) URL.
MongoDB cloud manager UI has been updated and they have changed Group ID to Project ID and merged Settings -> Group Settings into one consolidated panel Settings
This PR updates the k8s docs accordingly
- Currently, MongoDB container crashed because of resource constaints i.e.
out of memory exception. This change updates the resources and provides
data on how the configure/calculate them(if not following the guide).
- Also, add the ability to specify the storage engine(WiredTiger) cache
size for MongoDB, this configuration also helps with keeping the resources
constrained for MongoDB containers.
- Minor changes in some other documents as well.
- turned off server tokens so the server does not leak nginx information
on errors and header
- Added header to turn off cross site scripting
- use stable release of nginx instead of mainline
- limit available methods
- update response code
- All files moved to k8s/nginx-3scale with directory structure consistent
with k8s/nginx-http(s)
- Top level LICENCES.md updated
- Renaming entry point script to nginx_openresty_entrypoint.bash
- support public_network for vagrant box
- using python3-5 for centos based installations
- Revisiting docs.
- More changes will be incorporated in another PR.
- Parameterize MongoDB host mount path for docker deployments
- Change consists of two deployment models:
- Using Vagrant(single node, with/without docker)
- Using Ansible(single node, with/without docker)
- Updated quickstart documentation.
- Some WIP comments, which will be addressed later. Depending on the
requirements.
Currently, the requests from public websites (like
`bigchaindb.com/getstarted` and tutorials.bigchaindb.com/crab) cannot have the
app_id and app_key required to access IPDB in the web page.
We pass such requests through a web proxy that adds the required headers
to any POST requests from `*.bigchaindb.com`.
- If a mandatory variable is not specified, it will exit with the relevant
code and error message.
- For more verbosity, we will also echo the values for all the mandatory
variables.
- Documentation support to add a new BDB node to an existing
replica set, using x.509 certificates and SSL/TSL connections, across
geographically dispersed clusters.
- Fix some documentation issues and add more references i.e.
specifically about signing of MongoDB member certificates.
- Minor fixes for nginx-https-dep.yaml(invalid configMap var)
- Reconfigure nginx keep_alive between MongoDB front and backend ports.
- Editor removed whitespaces
- Creating a common secret for CA, since all the members of the replica set
and the clients need to have a common CA, moving all the relevant configuration
to a common secret.
- Modifying Dockerfiles for some components, once changes are approved
we will publish the new images.
- No documentation changes required.
- The guide is incorrect and expects and error message in the
nginx with https+3scale integration section:
$ curl -X GET https://<cluster-fqdn>
The above command should not return an error since this workflow is supported.
Updating this to the relevant command that will return the expected response
for sanity checking.
$ curl -X GET http://<cluster-fqdn>:27017
-- Fixed typos in the guide
-- Fixed some syntax errors in commandline instructions
-- Fixed strucuture of sample jsons
-- Fixed bugs in nginx-https-dep file, it was trying to access
an invalid variable in the configmap.
-- Improved some docs to give more clarity for the user.
Atleast all the issues I faced. :)
At point D, you start the mongo shell which is listening on port 27017 for incoming connections from BDB.
At point E, you don't mention to open a new terminal because you want to keep the mongo shell alive (or run it in background with addition of '&', however I prefer to see the mongo output). Being stupid me, I shut down the terminal which resulted in not being able to start BDB.
Beside that, I added a verification step to make sure that BDB server is running correctly.
* Remove support for whitelist
* Rename nginx to nginx-api
* Remove websocket support from nginx-api
* Change nginx to nginx-api service
The nginx-api service will proxy requests to the BigchainDB HTTP API.
* Rename ngx-instance-0 to ngx-api-instance-0 in nginx_3scale
* Update nginx-api service base docker image and README
* Add nginx-ws service to support Websocket
* Add config files for simple dev setup
* WS support with split NGINX
* NGINX module as single entrypoint into the cluster.
* Tested HTTP and WS with latest configs
* Openresty as separate service
* Remove upstream api port as configuration parameter
* Changes while testing
* Adding READMEs for nginx-http and nginx-https modules
* Documentation update
* Change 'Openresty' to 'OpenResty'.
- Quick start setup was broken because of a race condition with
using cryptoconditions in setup_requires and install_requires and
for a fresh Ubuntu 16.04 setup initialization of BigchainDB node
the python package installation fails due to package conflicts.
- Rest of the details are captured in the github issue #1657
- MongoDB StatefulSet hitting memory limit, so k8s restarts it.
We have had multiple instances of restarts lately.
- Changing it to 3.5 GB, data and reasoning to back it up
is mentioned in the ticket #1655
Update MongoDB container tag to `3.0`.
Doc change to reflect bdb-config.bdb-user parameter usage.
Fix typo in configuration.md.
Add BIGCHAINDB_DATABASE_SSL parameter to bigchaindb-dep.yaml for
Kubernetes deployments.
Refer the the `bdb-user` parameter from ConfigMap in
bigchaindb-dep.yaml.
Consolidate all BigchainDB parameter values under the
`bdb-config` ConfigMap.
Remove `bdb-user` from secrets.yaml.
* Use ConfigMap values in bigchaindb-dep.yaml
* Removed comments from top of bigchaindb-dep.yaml
Because they didn't add much information and they also contained a dated Docker Hub version tag.
* implement output.condition.details marshalling and remove signature field
* rename outputs[].condition.details.subfulfillments to subconditions
* simpler threshold depth overlow handling
* pass public_key as kwarg
* change ccv1 condition uri in docs
* import base58 at top in test_transaction
* tx version break step with server version
* fix regular expression for tx version
* restore docstring for Transaction version parameter
* add test for correct transaction version
* Changes to support auth on the infrastructure
* Auth over TLS/SSL support in BigchainDB, MongoDB, Monitoring Agent, Backup Agent
* Update certificates: Different OUs specified now
* Code formatting
- Make flake happy!
* Raise proper authentication failed error
* Documentation changes for auth
* Support auth in k8s deployment
* Commit certs for monitoring and backup agents
* Configuration to allow Cloud Manager Backup Agent to backup data
* Update docs and remove authentication error
- If spent=None return all outputs
- If spent=True return only spent outputs
- If spent=False return only unspent outputs
- Updated documentation
- Add the ability to return only spent outputs in core
- Added and update tests
* Add SSL support for MongoDB connections
* Tests for TLS connectivity and other fixes
* Add test for ssl parameters
* Add test for AuthenticationError
* Cleanup branch
* Split env vars as per @r-marques suggestion
* Remove SSL_ENABLED and use BIGCHAINDB_DATABASE_SSL instead
* Changes as per comments from @r-marques
* Remove redundant tests
* Test for ConfigurationError
* Add assets text search endpoint
* Filter out assets from invalid transactions.
- Added the limit argument to limit the returned results
- Created and updated tests
* Added documentation for the assets endpoint.
- Added some docstrings
* Removed unnecessary fixtures
* Support for secure TLS communication in MongoDB, MongoDB Monitoring
Agent and MongoDB Backup Agent
- Move from Golang to Bash for entrypoint program
- Update image tag to 2.0 for Backup and Monitoring Agents and to
3.4.4 for MongoDB
- Add documentation
* changed title & rewrote Step 1 of workflow.rst
* copy-edited ca-installation.rst
* copy-edited & modified structure of workflow.rst
* moved repeated Easy-RSA install & config docs to new page
* edited the sentences describing the Easy-RSA dirs
* copy-edited the page about generating server certificate
* copy-edited the page about generating client certificate
* renamed page to 'How to Set Up a Self-Signed Certificate Authority'
* copy-edited page about how to revoke a certificate
* Comments on how to uniquely name all instances in the cluster
* Added comments about the other questions when setting up a CA
* Added note about one Agent Api Key per Cloud Manager backup
* docs: clarified instructions for generating server CSR
* docs: added back 'from your PKI infrastructure'
* docs: fixed step & added step re/ FQDNs & certs in workflow.rst
* docs: added note re/ the Distinguished Name
* Update docs for env vars setup
* docs: added tip: how to get help with the easyrsa command
I changed the classifier `'Development Status :: 3 - Alpha'` to `'Development Status :: 4 - Beta'` as per the list of classifiers here: https://pypi.python.org/pypi?%3Aaction=list_classifiers
This is in preparation for the version 1.0 release but I think it's probably fine to have it in master now.
* Add more tools to the toolbox container
* Add mongodb monitoring agent
* Add a bigchaindb/mongodb-monitoring-agent container that includes the
monitoring agent.
* It makes use of an api key provided by MongoDB Cloud Manager. This is
included in the configuration/config-map.yaml file.
* Changes to mongodb StatefulSet configuration
Changes to bump up mongodb version to v3.4.3.
Add configuration settings for mongodb instance name in ConfigMap.
Split the mongodb service to a new configuration file.
* Modify bigchaindb deployment config
* Bugfix to remove keyring field for the first node.
* Split the mongodb service to a new configuration file.
* Add mongodb backup agent
* Add a bigchaindb/mongodb-backup-agent container that includes the
backup agent.
* It makes use of an api key provided by MongoDB Cloud Manager. This is
included in the configuration/config-map.yaml file.
* Changes to nginx deployment config
* Allow 'all' by default for now. This is included in the
configuration/config-map.yaml file.
* Dynamically resolve DNS addresses of our backend services; cache DNS
resolution for 20s.
* Configure DNS based on user provided resolver. This helps in user
deciding to provide 8.8.8.8 or a custom DNS for name resolution. For k8s
deployments, we use the hardcoded k8s DNS IP of 10.0.0.10.
* Changes to nginx-3scale deployment config
* Use the common ConfigMap in configuration/config-map.yaml file.
* Removing prefix `v` from the docker tag for mongodb-monitoring-agent and mongodb containers
* Bumping up version for nginx-3scale container
* Add small helper scripts for docker build and push of mongodb monitoring
and backup agents
* Documentation for setting up the first node with monitoring and backup
agents
From `pip install --help`:
```
-e, --editable <path/url> Install a project in editable mode (i.e.
setuptools "develop mode") from a local project path or a VCS url.
```
* Basing BigchainDB docker image from `python:3.6` in `Dockerfile` and `Dockerfile-dev`.
* Added ENV var for websocket interface
* Optimization to Dockerfile-dev to save build time during dev/test.
Pre-installing the `pynacl` dependeny in separate command so that devs
do not need to wait while testing. The trade-off is that devs will
need to clear (`rmi`) the image to start from scratch.
- Added NGINX deployment to frontend both BDB and MDB.
- Nginx is configured with a whitelist (which is read from a ConfigMap)
to allow only other MDB nodes in the closter to communicate with it.
- Azure LB apparently does not support proxy protocol and hence
whitelisting fails as nginx always observer the LB IP instead of the
real IP in the TCP stream.
- Whitelisting source IPs for MongoDB
- Removing deprecated folder
- Better log format
- Intuitive port number usage
- README and examples
- Addressed a typo in PYTHON_STYLE_GUIDE.md
- Azure LB apparently does not support proxy protocol and hence
whitelisting fails as nginx always observer the LB IP instead of the
real IP in the TCP stream.
- Whitelisting source IPs for MongoDB
- Removing deprecated folder
- Multiple changes:
- Better log format
- Intuitive port number usage
- README and examples
- Addressed a typo in PYTHON_STYLE_GUIDE.md
- Documentation
- add the k8s directory to the ignore list in codecov.yml
* Combining configs
* Combining the persistent volume claims into a single file.
* Combining the storage classes into a single file.
* Updating documentation
* Multiple changes
* Support for ConfigMap
* Custom MongoDB container for BigchainDB
* Update documentation to run a single node on k8s
* Additional documentation
* Documentation to add a node to an existing BigchainDB cluster
* Commit on rolling upgrades
* Fixing minor documentation mistakes
* Documentation updates as per @ttmc's comments
* Block formatting error
* Change in ConfigMap yaml config
* Single node as a StatefulSet in k8s
- uses bigchaindb/bigchaindb:0.9.1
* Updating README
* rdb, mdb as stateful services
* [WIP] bdb as a statefulset
* [WIP] bdb w/ rdb and bdb w/ mdb backends
- does not work as of now
* Split mdb & bdb into separate pods + enhancements
* discovery of the mongodb service by the bdb pod by using dns name.
* using separate storage classes to map 2 different volumes exposed by the
mongo docker container; one for /data/db (dbPath) and the other for
/data/configdb (configDB).
* using the `persistentVolumeReclaimPolicy: Retain` in k8s pvc. However,
this seems to be unsupported in Azure and the disks still show a reclaim
policy of `delete`.
* mongodb container runs the `mongod` process as user `mongodb` and group
`mongodb. The corresponding `uid` and `gid` for the `mongod` process is 999
and 999 respectively. When the constinaer runs on a host with a mounted disk,
the writes fail, when there is no user with uid 999. To avoid this, I use the
docker provided feature of --cap-add=FOWNER in k8s. This bypasses the uid and
gid permission checks during writes and allows writes.
Ref: https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities
* Delete redundant k8s files, add cluster deletion steps.
* Single node as a StatefulSet in k8s
- uses bigchaindb/bigchaindb:0.9.1
* Updating README
* rdb, mdb as stateful services
* [WIP] bdb as a statefulset
* [WIP] bdb w/ rdb and bdb w/ mdb backends
- does not work as of now
* Split mdb & bdb into separate pods + enhancements
* discovery of the mongodb service by the bdb pod by using dns name.
* using separate storage classes to map 2 different volumes exposed by the
mongo docker container; one for /data/db (dbPath) and the other for
/data/configdb (configDB).
* using the `persistentVolumeReclaimPolicy: Retain` in k8s pvc. However,
this seems to be unsupported in Azure and the disks still show a reclaim
policy of `delete`.
* mongodb container runs the `mongod` process as user `mongodb` and group
`mongodb. The corresponding `uid` and `gid` for the `mongod` process is 999
and 999 respectively. When the constinaer runs on a host with a mounted disk,
the writes fail, when there is no user with uid 999. To avoid this, I use the
docker provided feature of --cap-add=FOWNER in k8s. This bypasses the uid and
gid permission checks during writes and allows writes.
Ref: https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities
* Delete redundant k8s files, add cluster deletion steps.
* Documentation: running a single node with distinct mongodb and bigchaindb
pods on k8s
* Updates as per @ttmc's comments
- MacOS does not allow users to mount folders from the host unless it is
specified during build time.
- This is needed as the container on Mac needs to access the .bigchaindb
conf file residing on the host.
* Adding a line to modify the configuration file
* Changing the access URL for rethinkdb
* Typo fix and with clarification
* Changes as per @ttmc's comments
Add param 'rethinkdb' in docs for configure cmd.
With support for both mongo and rethink now, the original command for configuration of bigchaindb:
```
docker run --rm -v "$HOME/bigchaindb_docker:/data" -ti bigchaindb/bigchaindb -y configure
```
needs to be updated to
```
docker run --rm -v "$HOME/bigchaindb_docker:/data" -ti bigchaindb/bigchaindb -y configure rethinkdb
```
for docker to work without breaking.
* Document changes in the configure command.
Document new add/remove replicas commands.
* updated quickstart with mongodb instructions
* Docs on how to setup mongodb dev node with and without docker.
Update replSet option in docker-compose
* Fixed typo.
More explicit on how to run the tests.
* Fixed typo in mongodb docker instructions.
More explicit about requiring mongodb 3.4+
After talking to @r-marques and @libscott:
- A vote's id is currently generated by RethinkDB
- To verify a vote, the signature and the pubkey should be used
- Vote's id will be removed from the "external" vote model in the
future
- Nobody would want to retrieve a vote, but rather a vote by block
In case of the HTTP API, this means that a /votes/vote_id endpoint is
not feasible to implement.
It didn't feel good letting users retrieve also invalid or undecided
blocks in the /blocks/{block_id} endpoint.
Hence, now a block can be evaluated by it's status.
If block_id and status do not match, a 404 Not Found HTTP status code is
returned.
Per default, status is set to valid only.
- owner_afters --> owners_after
- List choices for operation query string
- List choices for fields query string
- Use proper sphinx-way to define type of query string
Inevitably, some resources will not allow to filter by the exact
keyword that is included in a resources body.
Take for example asset and metadata.
They both have a property called 'id', hence requests of a form:
/transactions&fields=x,y&property_name=z
might now be allowed to be resolved as the keyword 'id' in this
case could reference both 'metadata.id' and 'asset.id'.
This problem cannot be structurally resolved with URL paths.
Hence it was decided to emphasize on a few resources that
implement 'id' as a sort-of primary key.
A transaction contains:
- conditions
- fulfillments
- assets
- meta data
While:
- assets; and
- meta data
could be viewed as their own "tables" or resources, conditions
and fulfillments cannot. Why?
Because in comparison they do not contain a primary key, allowing
them to be queried by it.
According to: https://www.ietf.org/rfc/rfc2616.txt a 303 See Other can
be returned to indicate that the resource the user is looking for can be
found under a new path.
In the case of a transaction including the `status == 'valid'`, we
return 303 See Other, as well as a Location header to the /transactions
endpoint.
"The response to the request can be found under a different URI and SHOULD be
retrieved using a GET method on that resource."
According to https://www.ietf.org/rfc/rfc2616.txt a 201 Created status
code MUST only be returned when:
"The origin server MUST create the resource before returning the 201 status
code."
hence, a 202 Accepted's definition is more appropriate:
"The request has been accepted for processing, but the processing has not been
completed.
The entity returned with this response SHOULD include an indication of the
request's current status and either a pointer to a status monitor or some
estimate of when the user can expect the request to be fulfilled."
* Added replicaset name to bigchaindb config
* changed travis replSet to match bigchaindb default
* Updated initialize_replica_set
It now initializes the replica set with the name provided by the
bigchaindb config file.
* initialize_replica_set is now called when creating a mongodb connection.
This way we are sure that a replica set exists when we return a
connection.
* Moved the initialize replica set logic to the connection.
* update the config documentation
* Rename commands.bigchain.input to input_on_stderr to avoid confusion
* Allow input_on_stderr to not take a prompt
* Fix tests broken by renaming of commands.bigchaindb.input
* Remove asset.validate_asset and move its validation checks to other areas
* Move Asset.get_asset_id to Transaction
* Remove Asset and AssetLink models
* Add test against creating TRANSFER transactions with bad asset
* Allow AssetLinks to be used in place of Assets in the Transaction Model and enforce `Transaction.transfer()` to only take an AssetLink
* Remove AssetLink's inheritance from Asset
* Remove id from the Asset model
* Fix get_txids_by_asset_id query for rethinkdb after removing asset's uuid
Because `CREATE` transactions don't have an asset that contains an id
anymore, one way to find all the transactions related to an asset is to
query the database twice: once for the `CREATE` transaction and another
for the `TRANSFER` transactions.
* Add TODO notice for vote test utils to be fixtures
* Update asset model documentation to reflect usage of transaction id
* Fix outdated asset description in transaction schema
* Fix typos pointed out in review by @ttmc
* Reword description of an input in the transaction schema
* Re-add removed comment in transaction model
* Fix small typos in some comments in the transaction model
* Add trailling commas to a multiline dict in the transaction model tests
* Fix small things with server docs changes
* Add description of public keys' association with conditions in transaction concept docs
* Reword description of Transaction.create's and args
* Rename output_uri to output_condition_uri
* Fix hardcoded class name vs. self.__class__
* Rename instances of 'out' with 'output'
* Rename instances of and with to avoid name clash with built-in
* Remove unnecessary renaming of cryptoconditions.Fulfillment import in transaction model
* Remove instances of in transaction model
* Remove usages of fulfillment in cases where input makes more sense
* Reword docstrings for init methods in transaction models
* Rename usages of condition where output is now a better fit
* Add descriptions to TransactionLink's txid and idx in schema
* Minor correction to output idx description in transaction yaml
* Remove unnecessary import of rethinkdb in a test
* Move test_run_query_util as a rethinkdb-specific test
* Move rethinkdb-specific command tests to own file
* Add __init__.py to new test folders
* Move command tests to their own test module
* Move fixtures out of command tests into separate conftest for commands
* Fix some small flake8 issues with rethinkdb's test_run_query_util
* Add pytest ignore hook to filter out test dirs that are not for the requested backend
* Move backend-specific tests in tests/db/ to tests/backend/
* Add README.md to tests/ to describe test structure and pytest customizations
* Add package-level docstrings to backends
* Add README.md explaining the backend architecture
* Small improvements to docstrings in backend modules
* Restructure the backend automodule docs
* Add more docstrings to backend connections
* Add init to base backend Connection class to document expected interface
* Reword the backend/README.md docs
* Use section header for CI testing in style guide document
* Add tox section to style guide document
* Reword style guide's testing section to be more general after introduction of integration tests
The queue/pipeline used in the block creation process is unbounded.
When too many transactions occur, the backlog table fills up quite easily and
bigchaindb just reads all the transaction in the backlog to create a block.
This causes memory usage to grow indefinitely.
Limiting the queue size to 1000 transactions for now as the block creation and
voting happens in batches of 1000. Can be increased later in case block size
is increased.
SPDX-License-Identifier: (Apache-2.0 AND CC-BY-4.0)
Code is Apache-2.0 and docs are CC-BY-4.0
--->
# How to Contribute to the BigchainDB Project
There are many ways you can contribute to the BigchainDB project, some very easy and others more involved.
All of that is documented elsewhere: go to the "[Contributing to BigchainDB" docs on ReadTheDocs](https://docs.bigchaindb.com/projects/contributing/en/latest/index.html).
Note: GitHub automatically links to this file (`.github/CONTRIBUTING.md`) when a contributor creates a new issue or pull request, so you shouldn't delete it. Just use it to point people to full and proper help elsewhere.
- make a bug report? Then read below about what should go in a bug report.
- make a feature request or proposal? Then read [the page about how to make a feature request or proposal](https://docs.bigchaindb.com/projects/contributing/en/latest/ways-can-contribute/make-a-feature-request-or-proposal.html).
- ask a question about BigchainDB? Then [go to Gitter](https://gitter.im/bigchaindb/bigchaindb) (our chat room) and ask it there.
- share your neat idea or realization? Then [go to Gitter](https://gitter.im/bigchaindb/bigchaindb) (our chat room) and share it there.
# What Should Go in a Bug Report
- What computer are you on (hardware)?
- What operating system are you using, including version. e.g. Ubuntu 14.04? Fedora 23?
- What version of BigchainDB software were you using? Is that the latest version?
- What, exactly, did you do to get to the point where you got stuck? Describe all the steps so we can get there too. Show screenshots or copy-and-paste text to GitHub.
- Show what actually happened.
- Say what you tried to do to resolve the problem.
- Provide details to convince us that it matters to you. Is it for a school project, a job, a contract with a deadline, a child who needs it for Christmas?
We will do our best but please understand that we don't have time to help everyone, especially people who don't care to help us help them. "It doesn't work." is not going to get any reaction from us. We need _details_.
Tip: Use Github code block formatting to make code render pretty in GitHub. To do that, put three backticks followed by a string to set the type of code (e.g. `Python`), then the code, and then end with three backticks. There's more information about [inserting code blocks](https://help.github.com/articles/creating-and-highlighting-code-blocks/) in the GitHub help pages.
Make sure the title of this pull request has the form:
**Problem: A short statement of the problem.**
## Solution
A short statement about how this PR solves the **Problem**.
## Issues Resolved
What issues does this PR resolve, if any? Please include lines like the following (i.e. "Resolves #NNNN), so that when this PR gets merged, GitHub will automatically close those issues.
Resolves #NNNN
Resolves #MMMM
## BEPs Implemented
What [BEPs](https://github.com/bigchaindb/beps) does this pull request implement, if any?
SPDX-License-Identifier: (Apache-2.0 AND CC-BY-4.0)
Code is Apache-2.0 and docs are CC-BY-4.0
--->
# Change Log (Release Notes)
All _notable_ changes to this project will be documented in this file (`CHANGELOG.md`).
This project adheres to [Semantic Versioning](http://semver.org/) (or at least we try).
Contributors to this file, please follow the guidelines on [keepachangelog.com](http://keepachangelog.com/).
Note that each version (or "release") is the name of a [Git _tag_](https://git-scm.com/book/en/v2/Git-Basics-Tagging) of a particular commit, so the associated date and time are the date and time of that commit (as reported by GitHub), _not_ the "Uploaded on" date listed on PyPI (which may differ).
This project adheres to [the Python form of Semantic Versioning](https://packaging.python.org/tutorials/distributing-packages/#choosing-a-versioning-scheme) (or at least we try). The BigchainDB public API _was_ defined in this file but that definition was moved and can now be found in [BEP-7](https://github.com/bigchaindb/BEPs/tree/master/7).
Contributors to this file, please follow the guidelines on [keepachangelog.com](http://keepachangelog.com/). Note that each version (or "release") is the name of a [Git _tag_](https://git-scm.com/book/en/v2/Git-Basics-Tagging) of a particular commit, so the associated date and time are the date and time of that commit (as reported by GitHub), _not_ the "Uploaded on" date listed on PyPI (which may differ).
For reference, the possible headings are:
* **Added** for new features.
@ -13,17 +22,702 @@ For reference, the possible headings are:
* **Fixed** for any bug fixes.
* **Security** to invite users to upgrade in case of vulnerabilities.
* **External Contributors** to list contributors outside of BigchainDB GmbH.
* **Known Issues**
* **Notes**
## [2.2.2] - 2020-08-12
### Security
Several dependencies updated including Flask that had vulnerability.
### Fixed
* Updated priv_validator key format in stack script (#2707)
Gevent library API update is incompatible with bigchaindb-abci 1.0.1 version.
Updated bigchaindb-abci.
## [2.2.0] - 2020-02-20
### Added
Support for multiple ABCI versions.
## [2.1.0] - 2019-11-06
### Added
Option for last transaction retrieval added.
## [2.0] - 2019-09-26
### Changed
Migrated from Tendermint 0.22.8 to 0.31.5.
## [2.0 Beta 9] - 2018-11-27
### Changed
Removed support for TLSv1 and TLSv1.1 in all NGINX config files. Kept support for TLSv1.2 and added support for TLSv1.3. [Pull Request #2601](https://github.com/bigchaindb/bigchaindb/pull/2601)
### Fixed
Fixed two issues with schema validation. Pull requests [#2606](https://github.com/bigchaindb/bigchaindb/pull/2606) & [#2607](https://github.com/bigchaindb/bigchaindb/pull/2607)
### External Contributors
[@gamjapark](https://github.com/gamjapark) and team translated all the [BigchainDB root docs](https://docs.bigchaindb.com/en/latest/korean/index.html) into Korean. [Pull Request #2603](https://github.com/bigchaindb/bigchaindb/pull/2603)
## [2.0 Beta 8] - 2018-11-03
### Changed
* Revised the [Simple Deployment Template](http://docs.bigchaindb.com/projects/server/en/latest/simple-deployment-template/index.html) in the docs. Added NGINX to the mix. Pull Requests [#2578](https://github.com/bigchaindb/bigchaindb/pull/2578) and [#2579](https://github.com/bigchaindb/bigchaindb/pull/2579)
* Revised `nginx/nginx.conf` to enable CORS. [Pull Request #2580](https://github.com/bigchaindb/bigchaindb/pull/2580)
### Fixed
* Fixed a typo in the Kubernetes ConfigMap template. [Pull Request #2583](https://github.com/bigchaindb/bigchaindb/pull/2583)
### External Contributors
[@gamjapark](https://github.com/gamjapark) translated the main `README.md` file into Korean. [Pull Request #2592](https://github.com/bigchaindb/bigchaindb/pull/2592)
## [2.0 Beta 7] - 2018-09-28
Tag name: v2.0.0b7
### Added
Completed the implementation of chain-migration elections (BEP-42). Pull requests [#2553](https://github.com/bigchaindb/bigchaindb/pull/2553), [#2556](https://github.com/bigchaindb/bigchaindb/pull/2556), [#2558](https://github.com/bigchaindb/bigchaindb/pull/2558), [#2563](https://github.com/bigchaindb/bigchaindb/pull/2563) and [#2566](https://github.com/bigchaindb/bigchaindb/pull/2566)
### Changed
* Code that used the Python driver's (deprecated) transactions.send() method now uses its transactions.send_commit() method instead. [Pull request #2547](https://github.com/bigchaindb/bigchaindb/pull/2547)
* Code that implied pluggable "consensus" now implies pluggable transaction "validation" (a more accurate word). [Pull request #2561](https://github.com/bigchaindb/bigchaindb/pull/2561)
A bug caused by an incorrect MongoDB query. [Pull request #2567](https://github.com/bigchaindb/bigchaindb/pull/2567)
### Notes
There's now better documentation about logs, log rotation, and the `server.bind` config setting. Pull requests [#2546](https://github.com/bigchaindb/bigchaindb/pull/2546) and [#2575](https://github.com/bigchaindb/bigchaindb/pull/2575)
## [2.0 Beta 6] - 2018-09-17
Tag name: v2.0.0b6
### Added
* [New documentation about privacy and handling private data](https://docs.bigchaindb.com/en/latest/private-data.html). [Pull request #2437](https://github.com/bigchaindb/bigchaindb/pull/2437)
* New documentation about log rotation. Also rotate Tendermint logs if started using Monit. [Pull request #2528](https://github.com/bigchaindb/bigchaindb/pull/2528)
* Began implementing one of the migration strategies outlined in [BEP-42](https://github.com/bigchaindb/BEPs/tree/master/42). That involved creating a more general-purpose election process and commands. Pull requests [#2488](https://github.com/bigchaindb/bigchaindb/pull/2488), [#2495](https://github.com/bigchaindb/bigchaindb/pull/2495), [#2498](https://github.com/bigchaindb/bigchaindb/pull/2498), [#2515](https://github.com/bigchaindb/bigchaindb/pull/2515), [#2535](https://github.com/bigchaindb/bigchaindb/pull/2535)
* Used memoization to avoid doing some validation checks multiple times. [Pull request #2490](https://github.com/bigchaindb/bigchaindb/pull/2490)
* Created an all-in-one Docker image containing BigchainDB Server, Tendermint and MongoDB. It was created for a particular user and is not recommended for production use unless you really know what you're doing. [Pull request #2424](https://github.com/bigchaindb/bigchaindb/pull/2424)
### Changed
* The supported versions of Tendermint are now hard-wired into BigchainDB Server: it checks to see what version the connected Tendermint has, and if it's not compatible, BigchainDB Server exits with an error message. [Pull request #2541](https://github.com/bigchaindb/bigchaindb/pull/2541)
* The docs no longer say to install the highest version of Tendermint: they say to install a specific version. [Pull request #2524](https://github.com/bigchaindb/bigchaindb/pull/2524)
* The setup docs include more recommended settings for `config.toml`. [Pull request #2516](https://github.com/bigchaindb/bigchaindb/pull/2516)
* The process to add, remove or update the voting power of a validator at run time (using the `bigchaindb upsert-validator` subcommands) was completely changed and is now fully working. See [issue #2372](https://github.com/bigchaindb/bigchaindb/issues/2372) and all the pull requests it references. Pull requests [#2439](https://github.com/bigchaindb/bigchaindb/pull/2439) and [#2440](https://github.com/bigchaindb/bigchaindb/pull/2440)
* The license on the documentation was changed from CC-BY-SA-4 to CC-BY-4. [Pull request #2427](https://github.com/bigchaindb/bigchaindb/pull/2427)
* Re-activated and/or updated some unit tests that had been deacivated during the migration to Tendermint. Pull requests [#2390](https://github.com/bigchaindb/bigchaindb/pull/2390), [#2415](https://github.com/bigchaindb/bigchaindb/pull/2415), [#2452](https://github.com/bigchaindb/bigchaindb/pull/24), [#2456](https://github.com/bigchaindb/bigchaindb/pull/2456)
* Updated RapidJSON to a newer, faster version. [Pull request #2470](https://github.com/bigchaindb/bigchaindb/pull/2470)
* The Java driver is now officially supported. [Pull request #2478](https://github.com/bigchaindb/bigchaindb/pull/2478)
* The MongoDB indexes on transaction id and block height were changed to be [unique indexes](https://docs.mongodb.com/manual/core/index-unique/). [Pull request #2492](https://github.com/bigchaindb/bigchaindb/pull/2492)
* Updated the required `cryptoconditions` package to a newer one. [Pull request #2494](https://github.com/bigchaindb/bigchaindb/pull/2494)
* Fixed the Events API so that it only sends valid transactions to subscribers. Also changed how it works internally, so now it is more reliable. [Pull request #2529](https://github.com/bigchaindb/bigchaindb/pull/2529)
* Fixed a bug where MongoDB database initialization would abort if a collection already existed. [Pull request #2520](https://github.com/bigchaindb/bigchaindb/pull/2520)
* Fixed a unit test that was failing randomly. [Pull request #2423](https://github.com/bigchaindb/bigchaindb/pull/2423)
* Fixed the validator curl port. [Pull request #2447](https://github.com/bigchaindb/bigchaindb/pull/2447)
* Fixed an error in the docs about the HTTP POST /transactions endpoint. [Pull request #2481](https://github.com/bigchaindb/bigchaindb/pull/2481)
* Fixed a unit test that could loop forever. [Pull requqest #2486](https://github.com/bigchaindb/bigchaindb/pull/2486)
* Fixed a bug when validating a CREATE + TRANSFER. [Pull request #2487](https://github.com/bigchaindb/bigchaindb/pull/2487)
* Fixed the HTTP response when posting a transaction in commit mode. [Pull request #2510](https://github.com/bigchaindb/bigchaindb/pull/2510)
* Fixed a crash that happened when attempting to restart BigchainDB at Tendermint block height 1. [Pull request#2519](https://github.com/bigchaindb/bigchaindb/pull/2519)
The docs section titled "Production Deployment Template" was renamed to "Kubernetes Deployment Template" and we no longer consider it the go-to deployment template. The "Simple Deployment Template" is simpler, easier to understand, and less expensive (unless you are with an organization that already has a big Kubernetes cluster).
## [2.0 Beta 5] - 2018-08-01
Tag name: v2.0.0b5
### Changed
* Supported version of Tendermint `0.22.3` -> `0.22.8`. [Pull request #2429](https://github.com/bigchaindb/bigchaindb/pull/2429).
### Fixed
* Stateful validation raises a DoubleSpend exception if there is any other transaction that spends the same output(s) even if it has the same transaction ID. [Pull request #2422](https://github.com/bigchaindb/bigchaindb/pull/2422).
## [2.0 Beta 4] - 2018-07-30
Tag name: v2.0.0b4
### Added
- Added scripts for creating a configuration to manage processes with Monit. [Pull request #2410](https://github.com/bigchaindb/bigchaindb/pull/2410).
### Fixed
- Redundant asset and metadata queries were removed. [Pull request #2409](https://github.com/bigchaindb/bigchaindb/pull/2409).
- Signal handling was fixed for BigchainDB processes. [Pull request #2395](https://github.com/bigchaindb/bigchaindb/pull/2395).
- Some of the abruptly closed sockets that used to stay in memory are being cleaned up now. [Pull request 2408](https://github.com/bigchaindb/bigchaindb/pull/2408).
- Fixed the bug when WebSockets powering Events API became unresponsive. [Pull request #2413](https://github.com/bigchaindb/bigchaindb/pull/2413).
### Notes:
* The instructions on how to write a BEP were simplified. [Pull request #2347](https://github.com/bigchaindb/bigchaindb/pull/2347).
* A section about troubleshooting was added to the network setup guide. [Pull request #2398](https://github.com/bigchaindb/bigchaindb/pull/2398).
* Some of the core code was given a better package structure. [Pull request #2401](https://github.com/bigchaindb/bigchaindb/pull/2401).
* Some of the previously disabled unit tests were re-enabled and updated. Pull requests [#2404](https://github.com/bigchaindb/bigchaindb/pull/2404) and [#2402](https://github.com/bigchaindb/bigchaindb/pull/2402).
* Some building blocks for dynamically adding new validators were introduced. [Pull request #2392](https://github.com/bigchaindb/bigchaindb/pull/2392).
## [2.0 Beta 3] - 2018-07-18
Tag name: v2.0.0b3
### Fixed
Fixed a bug in transaction validation. For some more-complex situations, it would say that a valid transaction was invalid. This bug was actually fixed before; it was [issue #1271](https://github.com/bigchaindb/bigchaindb/issues/1271). The unit test for it was turned off while we integrated Tendermint. Then the query implementation code got changed, reintroducing the bug, but the unit test was off so the bug wasn't caught. When we turned the test back on, shortly after releasing Beta 2, it failed, unveiling the bug. [Pull request #2389](https://github.com/bigchaindb/bigchaindb/pull/2389)
## [2.0 Beta 2] - 2018-07-16
Tag name: v2.0.0b2
### Added
* Added new configuration settings `tendermint.host` and `tendermint.port`. [Pull request #2342](https://github.com/bigchaindb/bigchaindb/pull/2342)
* Added tests to ensure that BigchainDB gracefully handles "nasty" strings in keys and values. [Pull request #2334](https://github.com/bigchaindb/bigchaindb/pull/2334)
* Added a new logging handler to capture benchmark stats to a separate file. [Pull request #2349](https://github.com/bigchaindb/bigchaindb/pull/2349)
### Changed
* Changed the names of BigchainDB processes (Python processes) to include 'bigchaindb', so they are easier to spot and find. [Pull request #2354](https://github.com/bigchaindb/bigchaindb/pull/2354)
* Updated all code to support the latest version of Tendermint. Note that the BigchainDB ABCI server now listens to port 26657 instead of 46657. Pull requests [#2375](https://github.com/bigchaindb/bigchaindb/pull/2375) and [#2380](https://github.com/bigchaindb/bigchaindb/pull/2380)
### Removed
Removed all support and code for the old backlog_reassign_delay setting. [Pull request #2332](https://github.com/bigchaindb/bigchaindb/pull/2332)
### Fixed
* Fixed a bug that sometimes arose when using Docker Compose. (Tendermint would freeze.) [Pull request #2341](https://github.com/bigchaindb/bigchaindb/pull/2341)
* Fixed a bug in the code that creates a MongoDB index for the "id" in the transactions collection. It works now, and performance is improved. [Pull request #2378](https://github.com/bigchaindb/bigchaindb/pull/2378)
* The logging server would keep runnning in some tear-down scenarios. It doesn't do that any more. [Pull request #2304](https://github.com/bigchaindb/bigchaindb/pull/2304)
The `bigchaindb upsert-validator` subcommand is not working yet, but a solution ([BEP-21](https://github.com/bigchaindb/BEPs/tree/master/21)) has been finalized and will be implemented before we release the final BigchainDB 2.0.
### Notes
* A lot of old/dead code was deleted. Pull requests
* Improved the documentation page "How to setup a BigchainDB Network". [Pull Request #2312](https://github.com/bigchaindb/bigchaindb/pull/2312)
## [2.0 Beta 1] - 2018-06-01
Tag name: v2.0.0b1
### Fixed
* Fixed a bug that arose with some code that treated transactions-waiting-for-block-inclusion as if they were already stored in MongoDB (i.e. already in a block). [Pull request #2318](https://github.com/bigchaindb/bigchaindb/pull/2318)
* If a user asked for a block and it happened to be an empty block, BigchainDB returned 404 Not Found, as if the block did not exist. Now it returns a 200 OK with a block containing no transactions, i.e. an empty block. [Pull request #2321](https://github.com/bigchaindb/bigchaindb/pull/2321)
### Known Issues
* An issue was found with the `bigchaindb upsert-validator` command. A solution was proposed in [BEP-19](https://github.com/bigchaindb/BEPs/pull/45) and is being implemented in [pull request #2314](https://github.com/bigchaindb/bigchaindb/pull/2314)
* If you run BigchainDB locally using `make start` (i.e. using Docker Compose) and then you put the node under heavy write load, Tendermint can become unresponsive and running `make stop` can hang.
* There seems to be one or more issues with Tendermint when it is put under heavy load (i.e. even when BigchainDB isn't involved). See Tendermint issues [#1394](https://github.com/tendermint/tendermint/issues/1394), [#1642](https://github.com/tendermint/tendermint/issues/1642) and [#1661](https://github.com/tendermint/tendermint/issues/1661)
### Notes
* There's a [new docs page](https://docs.bigchaindb.com/projects/server/en/v2.0.0b1/simple-network-setup.html) about how to set up a network where each node uses a single virtual machine.
* We checked, and BigchainDB 2.0 Beta 1 works with MongoDB 3.6 (and 3.4).
* Support for RethinkDB is completely gone.
## [2.0 Alpha 6] - 2018-05-17
Tag name: v2.0.0a6
### Changed
Upgraded PyMongo to version 3.6 (which is compatible with MongoDB 3.6, 3.4 [and more](https://docs.mongodb.com/ecosystem/drivers/driver-compatibility-reference/#python-driver-compatibility)). [Pull request #2298](https://github.com/bigchaindb/bigchaindb/pull/2298)
### Fixed
When deploying a node using our Docker Compose file, it didn't expose port 46656, which is used by Tendermint for inter-node communications, so the node couldn't communicate with other nodes. We fixed that in [pull request #2299](https://github.com/bigchaindb/bigchaindb/pull/2299)
### Notes
We ran all our tests using MongoDB 3.6 and they all passed, so it seems safe to use BigchainDB with MongoDB 3.6 from now on.
## [2.0 Alpha 5] - 2018-05-11
Tag name: v2.0.0a5
### Changed
To resolve [issue #2279](https://github.com/bigchaindb/bigchaindb/issues/2279), we made some changes to the `bigchaindb-abci` package (which is our fork of `py-abci`) and told BigchainDB to use the new version (`bigchaindb-abci==0.4.5`). [Pull request #2281](https://github.com/bigchaindb/bigchaindb/pull/2281).
## [2.0 Alpha 4] - 2018-05-09
Tag name: v2.0.0a4
### Changed
The Kubernetes liveness probe for the BigchainDB StatefulSet was improved to check the Tendermint /status endpoint in addition to the Tendermint /abci_info endpoint. [Pull request #2275](https://github.com/bigchaindb/bigchaindb/pull/2275)
There's a new [page in the docs about storing files in BigchainDB](https://docs.bigchaindb.com/en/latest/store-files.html). [Pull request #2259](https://github.com/bigchaindb/bigchaindb/pull/2259)
## [2.0 Alpha 3] - 2018-05-03
Tag name: v2.0.0a3
### Changed
* Upgraded BigchainDB Server code to use the latest version of Tendermint: version 0.19.2. Pull requests [#2249](https://github.com/bigchaindb/bigchaindb/pull/2249), [#2252](https://github.com/bigchaindb/bigchaindb/pull/2252) and [#2253](https://github.com/bigchaindb/bigchaindb/pull/2253)
* Made some fixes to `py-abci` (an external Python package) and used our fixed version with BigchainDB. Those fixes resolved several known issues, including [issue #2182](https://github.com/bigchaindb/bigchaindb/issues/2182) and issues with large transactions in general. Note: At the time of writing, our fixes to `py-abci` hadn't been merged into the main `py-abci` repository or its latest release on PyPI; we were using our own special `bigchaindb-abci` package (which included our fixes). Pull requests [#2250](https://github.com/bigchaindb/bigchaindb/pull/2250) and [#2261](https://github.com/bigchaindb/bigchaindb/pull/2261)
* If BigchainDB Server crashes and then comes back, Tendermint Core doesn't try to reconnect to it. That's just how Tendermint Core works. We revised our Kubernetes-based production deployment template to resolve that issue: BigchainDB Server and Tendermint Core are now in the same Kubernetes StatefulSet; if the connection between them ever goes down, then Kubernetes restarts the whole StatefulSet. [Pull request #2242](https://github.com/bigchaindb/bigchaindb/pull/2242)
Tendermint changed how it responds to a request to store data (via the [Tendermint Broadcast API](https://tendermint.com/docs/tendermint-core/using-tendermint.html#broadcast-api)) between version 0.12 and 0.19.2. We started modifying the code of BigchainDB Server to account for those changes in responses (in [pull request #2239](https://github.com/bigchaindb/bigchaindb/pull/2239)), but we found that there's a difference between what the Tendermint documentation _says_ about those responses and how Tendermint actually responds. We need to determine Tendermint's intent before we can finalize that pull request.
### Notes
We were focused on getting the public BigchainDB Testnet stable during the development of BigchainDB 2.0 Alpha 3, and we think we largely succeeded. Because of that focus, we delayed the deployment of an internal test network until later. It would have had the same instabilities as the public BigchainDB Testnet anyway. In the future, we'll always test a new version of BigchainDB on our internal test network before deploying it on the public BigchainDB Testnet. (That wasn't possible this time around, because there was no old/stable version of BigchainDB 2.n to run on the public BigchainDB Testnet while we tested BigchainDB 2.[n+1] internally.)
## [2.0 Alpha 2] - 2018-04-18
Tag name: v2.0.0a2
### Added
An implementation of [BEP-8 (BigchainDB Enhancement Proposal #8)](https://github.com/bigchaindb/BEPs/tree/master/8), which makes sure a node can recover from a system fault (e.g. a crash) into a consistent state, i.e. a state where the data in the node's local MongoDB database is consistent with the data stored in the blockchain. Pull requests [#2135](https://github.com/bigchaindb/bigchaindb/pull/2135) and [#2207](https://github.com/bigchaindb/bigchaindb/pull/2207)
### Changed
When someone uses the HTTP API to send a new transaction to a BigchainDB network using the [POST /api/v1/transactions?mode={mode}](https://docs.bigchaindb.com/projects/server/en/master/http-client-server-api.html#post--api-v1-transactions?mode=mode) endpoint, they now get back a more informative HTTP response, so they can better-understand what happened. This is only when mode is `commit` or `sync`, because `async`_means_ that the response is immediate, without waiting to see what happened to the transaction. [Pull request #2198](https://github.com/bigchaindb/bigchaindb/pull/2198)
### Known Issues
* If BigchainDB Server crashes and then is restarted, Tendermint Core won't try to reconnect to BigchainDB Server and so all operations requiring that connection won't work. We only understood this recently. We'll write a blog post explaining what we intend to do about it.
* The known issues in 2.0 Alpha (listed below) are still there.
## [2.0 Alpha] - 2018-04-03
Tag name: v2.0.0a1
There were _many_ changes between 1.3 and 2.0 Alpha, too many to list here. We wrote a series of blog posts to summarize most changes, especially those that affect end users and application developers:
* [BigchainDB 2.0 is Byzantine Fault Tolerant](https://blog.bigchaindb.com/bigchaindb-2-0-is-byzantine-fault-tolerant-5ffdac96bc44)
* [Some HTTP API Changes in the Next Release](https://blog.bigchaindb.com/some-http-api-changes-in-the-next-release-49612a537b0c)
* [Three Transaction Model Changes in the Next Release](https://blog.bigchaindb.com/three-transaction-model-changes-in-the-next-release-dadbac50094a)
* [Changes to the Server Command Line Interface in BigchainDB 2.0](https://blog.bigchaindb.com/changes-to-the-server-command-line-interface-in-bigchaindb-2-0-e1d6576e7155)
* _A forthcoming post about changes in BigchainDB Server configuration settings_
### External Contributors
* @r7vme contributed [pull request #1984](https://github.com/bigchaindb/bigchaindb/pull/1984) which fixed a bug in our Kubernetes-based production deployment template.
### Known Issues
We intend to resolve these issues before releasing the final BigchainDB 2.0:
* There's a known Heisenbug that (sometimes) arises and we found that making the BigchainDB webserver single-threaded prevents that bug from causing problems. We intend to resolve that bug, but in the meantime our temporary workaround is to change the _default_ webserver configuration settings to single-threaded mode, i.e. `BIGCHAINDB_SERVER_WORKERS=1` and `BIGCHAINDB_SERVER_THREADS=1`.
* Issues sometimes happen when a large transaction is sent to a BigchainDB network.
* Improved documentation about blocks and votes. [Pull request #1855](https://github.com/bigchaindb/bigchaindb/pull/1855)
## [1.2] - 2017-11-13
Tag name: v1.2.0
### Added
* New and improved installation setup docs and code. Pull requests [#1775](https://github.com/bigchaindb/bigchaindb/pull/1775) and [#1785](https://github.com/bigchaindb/bigchaindb/pull/1785)
* New BigchainDB configuration setting to set the port number of the log server: `log.port`. [Pull request #1796](https://github.com/bigchaindb/bigchaindb/pull/1796)
* New secondary index on `id` in the bigchain table. That will make some queries execute faster. [Pull request #1803](https://github.com/bigchaindb/bigchaindb/pull/1803)
* When using MongoDB, there are some restrictions on allowed names for keys (JSON keys). Those restrictions were always there but now BigchainDB checks key names explicitly, rather than leaving that to MongoDB. Pull requests [#1807](https://github.com/bigchaindb/bigchaindb/pull/1807) and [#1811](https://github.com/bigchaindb/bigchaindb/pull/1811)
* When using MongoDB, there are some restrictions on the allowed values of "language" (if that key is used in the values of `metadata` or `asset.data`). Those restrictions were always there but now BigchainDB checks the values explicitly, rather than leaving that to MongoDB. Pull requests [#1806](https://github.com/bigchaindb/bigchaindb/pull/1806) and [#1811](https://github.com/bigchaindb/bigchaindb/pull/1811)
* There's a new page in the root docs about permissions in BigchainDB. [Pull request #1788](https://github.com/bigchaindb/bigchaindb/pull/1788)
* There's a new option in the `bigchaindb start` command: `bigchaindb start --no-init` will avoid doing `bigchaindb init` if it wasn't done already. [Pull request #1814](https://github.com/bigchaindb/bigchaindb/pull/1814)
### Fixed
* Fixed a bug where setting the log level in a BigchainDB config file didn't have any effect. It does now. [Pull request #1797](https://github.com/bigchaindb/bigchaindb/pull/1797)
* The docs were wrong about there being no Ping/Pong support in the Events API. There is, so the docs were fixed. [Pull request #1799](https://github.com/bigchaindb/bigchaindb/pull/1799)
* Fixed an issue with closing WebSocket connections properly. [Pull request #1819](https://github.com/bigchaindb/bigchaindb/pull/1819)
### Notes
* Many changes were made to the Kubernetes-based production deployment template and code.
## [1.1] - 2017-09-26
Tag name: v1.1.0
### Added
* Support for server-side plugins that can add support for alternate event consumers (other than the WebSocket API). [Pull request #1707](https://github.com/bigchaindb/bigchaindb/pull/1707)
* New configuration settings to set the *advertised* wsserver scheme, host and port. (The *advertised* ones are the ones that external users use to connect to the WebSocket API.) [Pull request #1703](https://github.com/bigchaindb/bigchaindb/pull/1703)
* Support for secure (TLS) WebSocket connections. [Pull request #1619](https://github.com/bigchaindb/bigchaindb/pull/1619)
* A new page of documentation about the contents of a condition (inside a transaction). [Pull request #1668](https://github.com/bigchaindb/bigchaindb/pull/1668)
### Changed
* We updated our definition of the **public API** (at the top of this document). [Pull request #1700](https://github.com/bigchaindb/bigchaindb/pull/1700)
* The HTTP API Logger now logs the request path and method as well. [Pull request #1644](https://github.com/bigchaindb/bigchaindb/pull/1644)
* @ketanbhatt - Pull requests [#1643](https://github.com/bigchaindb/bigchaindb/pull/1643) and [#1644](https://github.com/bigchaindb/bigchaindb/pull/1644)
### Notes
* New drivers & tools from our community:
* [Java driver](https://github.com/authenteq/java-bigchaindb-driver), by [Authenteq](https://authenteq.com/)
* [Ruby library](https://rubygems.org/gems/bigchaindb), by @nileshtrivedi
* Many improvements to our production deployment template (which uses Kubernetes).
* The production deployment template for the multi-node case was out of date. We updated that and verified it. [Pull request #1713](https://github.com/bigchaindb/bigchaindb/pull/1713)
## [1.0.1] - 2017-07-13
Tag name: v1.0.1
### Fixed
* Various issues in the Quickstart page. Pull requests
[#1641](https://github.com/bigchaindb/bigchaindb/pull/1641) and
**This just reports the changes since the release of 1.0.0rc1. If you want the full picture of all changes since 0.10, then read the 1.0.0rc1 change log below as well as the upgrade guide.**
### Changed
* The file name of the upgrade guide changed from `docs/upgrade-guides/v0.10-->v1.0.md` to `docs/upgrade-guides/v0.10-v1.0.md`.
* In `transaction.inputs[n].fulfills`, `output` was renamed to `output_index`. [Pull Request #1596](https://github.com/bigchaindb/bigchaindb/pull/1596)
* In `transaction.outputs[n].condition.details`, 1) `signature` was removed (from signature conditions) and 2) `subfulfillments` was renamed to `subconditions` (in threshold conditions). [Pull Request #1589](https://github.com/bigchaindb/bigchaindb/pull/1589)
* Refined transaction schema validation to check that the `transaction.outputs[n].condition.uri` corresponds to a condition that BigchainDB Server 1.0.0 actually supports. [Pull Request #1597](https://github.com/bigchaindb/bigchaindb/pull/1597)
* Before, GET requests (to the HTTP API) with header `Content-Type: 'application/json'` would get a response with the message, "The browser (or proxy) sent a request that this server could not understand." Now, if a GET request includes a `Content-Type` header, that header gets deleted (i.e. ignored). [Pull Request #1630](https://github.com/bigchaindb/bigchaindb/pull/1630)
### Fixed
* If an end user sends a transaction with `operation` equal to `GENESIS`, it will be rejected as invalid. [Pull Request #1612](https://github.com/bigchaindb/bigchaindb/pull/1612)
## [1.0.0rc1] - 2017-06-23
Tag name: v1.0.0rc1
### Added
* Support for secure TLS/SSL communication between MongoDB and {BigchainDB, MongoDB Backup Agent, MongoDB Monitoring Agent}. Pull Requests
* Text search support (only if using MongoDB). Pull Requests [#1469](https://github.com/bigchaindb/bigchaindb/pull/1469) and [#1471](https://github.com/bigchaindb/bigchaindb/pull/1471)
* The `database.connection_timeout` configuration setting now works with RethinkDB too. [#1512](https://github.com/bigchaindb/bigchaindb/pull/1512)
* New code and tools for benchmarking CREATE transactions. [Pull Request #1511](https://github.com/bigchaindb/bigchaindb/pull/1511)
### Changed
* There's an upgrade guide in `docs/upgrade-guides/v0.10-->v1.0.md`. It only covers changes to the transaction model and HTTP API. If that file hasn't been merged yet, see [Pull Request #1547](https://github.com/bigchaindb/bigchaindb/pull/1547)
* Cryptographic signatures now sign the whole (serialized) transaction body, including the transaction ID, but with all `"fulfillment"` values changed to `None`. [Pull Request #1225](https://github.com/bigchaindb/bigchaindb/pull/1225)
* In transactions, the value of `"amount"` must be a string. (Before, it was supposed to be a number.) [Pull Request #1286](https://github.com/bigchaindb/bigchaindb/pull/1286)
* In `setup.py`, the "Development Status" (as reported on PyPI) was changed from Alpha to Beta. [Pull Request #1437](https://github.com/bigchaindb/bigchaindb/pull/1437)
* If you explicitly specify a config file, e.g. `bigchaindb -c path/to/config start` and that file can't be found, then BigchainDB Server will fail with a helpful error message. [Pull Request #1486](https://github.com/bigchaindb/bigchaindb/pull/1486)
* Reduced the response time on the HTTP API endpoint to get all the unspent outputs associated with a given public key (a.k.a. "fast unspents"). [Pull Request #1411](https://github.com/bigchaindb/bigchaindb/pull/1411)
* Internally, the value of an asset's `"data"` is now stored in a separate assets table. This enabled the new text search. Each asset data is stored along with the associated CREATE transaction ID (asset ID). That data gets written when the containing block gets written to the bigchain table. [Pull Request #1460](https://github.com/bigchaindb/bigchaindb/pull/1460)
* Schema validation was sped up by switching to `rapidjson-schema`. [Pull Request #1494](https://github.com/bigchaindb/bigchaindb/pull/1494)
* If a node comes back from being down for a while, it will resume voting on blocks in the order determined by the MongoDB oplog, in the case of MongoDB. (In the case of RethinkDB, blocks missed in the changefeed will not be voted on.) [Pull Request #1389](https://github.com/bigchaindb/bigchaindb/pull/1389)
* Parallelized transaction schema validation in the vote pipeline. [Pull Request #1492](https://github.com/bigchaindb/bigchaindb/pull/1492)
* `asset.data` or `asset.id` are now *required* in a CREATE or TRANSFER transaction, respectively. [Pull Request #1518](https://github.com/bigchaindb/bigchaindb/pull/1518)
* The HTTP response body, in the response to the `GET /` and the `GET /api/v1` endpoints, was changed substantially. [Pull Request #1529](https://github.com/bigchaindb/bigchaindb/pull/1529)
* Changed the HTTP `GET /api/v1/transactions/{transaction_id}` endpoint. It now only returns the transaction if it's in a valid block. It also returns a new header with a relative link to a status monitor. [Pull Request #1543](https://github.com/bigchaindb/bigchaindb/pull/1543)
* All instances of `txid` and `tx_id` were replaced with `transaction_id`, in the transaction model and the HTTP API. [Pull Request #1532](https://github.com/bigchaindb/bigchaindb/pull/1532)
* The hostname and port were removed from all URLs in all HTTP API responses. [Pull Request #1538](https://github.com/bigchaindb/bigchaindb/pull/1538)
* Relative links were replaced with JSON objects in HTTP API responses. [Pull Request #1541](https://github.com/bigchaindb/bigchaindb/pull/1541)
* In the outputs endpoint of the HTTP API, the query parameter `unspent` was changed to `spent` (so no more double negatives). If that query parameter isn't included, then all outputs matching the specificed public key will be returned. If `spent=true`, then only the spent outputs will be returned. If `spent=false`, then only the unspent outputs will be returned. [Pull Request #1545](https://github.com/bigchaindb/bigchaindb/pull/1545)
* The supported crypto-conditions changed from version 01 of the crypto-conditions spec to version 02. [Pull Request #1562](https://github.com/bigchaindb/bigchaindb/pull/1562)
* The value of "version" inside a transaction must now be "1.0". (Before, it could be "0.anything".) [Pull Request #1574](https://github.com/bigchaindb/bigchaindb/pull/1574)
### Removed
* The `server.threads` configuration setting (for the Gunicorn HTTP server) was removed from the default set of BigchainDB configuration settings. [Pull Request #1488](https://github.com/bigchaindb/bigchaindb/pull/1488)
### Fixed
* The `GET /api/v1/outputs` endpoint was failing for some transactions with threshold conditions. Fixed in [Pull Request #1450](https://github.com/bigchaindb/bigchaindb/pull/1450)
### External Contributors
* @elopio - Pull Requests [#1415](https://github.com/bigchaindb/bigchaindb/pull/1415) and [#1491](https://github.com/bigchaindb/bigchaindb/pull/1491)
* We dropped support for Python 3.4. [Pull Request #1564](https://github.com/bigchaindb/bigchaindb/pull/1564)
* There were many improvements to our Kubernetes-based production deployment template (and the associated documentaiton).
* There is now a [BigchainDB Ruby driver](https://github.com/LicenseRocks/bigchaindb_ruby), created by @addywaddy at [license.rocks](https://github.com/bigchaindb/bigchaindb/pull/1437).
* The [BigchainDB JavaScript driver](https://github.com/bigchaindb/js-bigchaindb-driver) was moved to a different GitHub repo and is now officially maintained by the BigchainDB team.
* We continue to recommend using MongoDB.
## [0.10.3] - 2017-06-29
Tag name: v0.10.3
## Fixed
* Pin minor+ version of `cryptoconditions` to avoid upgrading to a non
* Documentation for the BigchainDB settings `wsserver.host` and `wsserver.port`. [Pull Request #1408](https://github.com/bigchaindb/bigchaindb/pull/1408)
### Fixed
* Fixed `Dockerfile`, which was failing to build. It now starts `FROM python:3.6` (instead of `FROM ubuntu:xenial`). [Pull Request #1410](https://github.com/bigchaindb/bigchaindb/pull/1410)
* Fixed the `Makefile` so that `release` depends on `dist`. [Pull Request #1405](https://github.com/bigchaindb/bigchaindb/pull/1405)
## [0.10.0] - 2017-04-18
Tag name: v0.10.0
### Added
* Improved logging. Added logging to file. Added `--log-level` option to `bigchaindb start` command. Added new logging configuration settings. Pull Requests
* The main BigchainDB Dockerfile (and its generated Docker image) now contains only BigchainDB Server. (It used to contain both BigchainDB Server and RethinkDB.) You must now run MongoDB or RethinkDB in a separate Docker container. [Pull Request #1174](https://github.com/bigchaindb/bigchaindb/pull/1174)
* Made separate schemas for CREATE and TRANSFER transactions. [Pull Request #1257](https://github.com/bigchaindb/bigchaindb/pull/1257)
* When signing transactions with threshold conditions, we now sign all subconditions for a public key. [Pull Request #1294](https://github.com/bigchaindb/bigchaindb/pull/1294)
* Many changes to the voting-related code, including how we validate votes and prevent duplicate votes by the same node. Pull Requests [#1215](https://github.com/bigchaindb/bigchaindb/pull/1215) and [#1258](https://github.com/bigchaindb/bigchaindb/pull/1258)
### Removed
* Removed the `bigchaindb load` command. Pull Requests
* Removed old `/speed-tests` and `/benchmarking-tests` directories. [Pull Request #1359](https://github.com/bigchaindb/bigchaindb/pull/1359)
### Fixed
* Fixed the URL of the BigchainDB docs returned by the HTTP API. [Pull Request #1178](https://github.com/bigchaindb/bigchaindb/pull/1178)
* Fixed the MongoDB changefeed: it wasn't reporting update operations. [Pull Request #1193](https://github.com/bigchaindb/bigchaindb/pull/1193)
* Fixed the block-creation process: it wasn't checking if the transaction was previously included in:
* a valid block. [Pull Request #1208](https://github.com/bigchaindb/bigchaindb/pull/1208)
* the block-under-construction. Pull Requests [#1237](https://github.com/bigchaindb/bigchaindb/issues/1237) and [#1377](https://github.com/bigchaindb/bigchaindb/issues/1377)
* Fixed bug in how the transaction `VERSION` string was calculated from the BigchainDB Server `__short_version__` string. [Pull Request #1160](https://github.com/bigchaindb/bigchaindb/pull/1160)
## [0.9.0] - 2017-02-06
Tag name: v0.9.0
It has been more than two months since the v0.8.0 release, so there have been _many_ changes. We decided to describe them in broad strokes, with links to more details elsewhere.
### Added
- Support for MongoDB as a backend database.
- Some configuration settings and `bigchaindb` command-line commands were added. In particular, one can specify the database backend (`rethinkdb` or `mongodb`). For MongoDB, one can specify the name of the replicaset. Also for MongoDB, there are new command-line commands to add and remove hosts from the replicaset. See [the Settings & CLI docs](https://docs.bigchaindb.com/projects/server/en/v0.9.0/server-reference/index.html).
- Transaction schema validation. The transaction schema is also used to auto-generate some docs. [Pull Request #880](https://github.com/bigchaindb/bigchaindb/pull/880)
- Vote schema validation. The vote schema is also used to auto-generate some docs. [Pull Request #865](https://github.com/bigchaindb/bigchaindb/pull/865)
- New `ENABLE_WEB_ADMIN` setting in the AWS deployment configuration file. [Pull Request #1015](https://github.com/bigchaindb/bigchaindb/pull/1015)
### Changed
- The transaction model has changed substantially. @libscott wrote a blog post about the changes and it will be published soon on [the BigchainDB Blog](https://blog.bigchaindb.com/). Also, see [the docs about the transaction model](https://docs.bigchaindb.com/projects/server/en/v0.9.0/data-models/transaction-model.html).
- The HTTP API has changed substantially. @diminator wrote a blog post about the changes and it will be published soon on [the BigchainDB Blog](https://blog.bigchaindb.com/). Also, see [the docs about the vote model](https://docs.bigchaindb.com/projects/server/en/v0.9.0/data-models/vote-model.html).
- All RethinkDB-specific database calls were replaced with abstract calls to a backend database.
- Some improvements to the Dockerfile, e.g. Pull Requests [#1011](https://github.com/bigchaindb/bigchaindb/pull/1011) and [#1121](https://github.com/bigchaindb/bigchaindb/pull/1121)
- Many improvements to the tests
- We standardized on supporting Ubuntu 16.04 for now (but BigchainDB Server also works on similar Linux distros).
### Removed
- `api_endpoint` was removed from the BigchainDB configuration settings. (It was never used anyway.) [Pull Request #821](https://github.com/bigchaindb/bigchaindb/pull/821)
- Removed all remaining StatsD monitoring code, configuration settings, docs, etc. (We'll add another monitoring solution in the future.) [Pull Request #1138](https://github.com/bigchaindb/bigchaindb/pull/1138)
### Fixed
- Fixed a memory (RAM) overflow problem when under heavy load by bounding the size of the queue at the entrance to the block pipeline. [Pull Request #908](https://github.com/bigchaindb/bigchaindb/pull/908)
- Fixed some logic in block validation. [Pull Request #1130](https://github.com/bigchaindb/bigchaindb/pull/1130)
### External Contributors
- @amirelemam - [Pull Request #762](https://github.com/bigchaindb/bigchaindb/pull/762) (closed but used as the basis for [Pull Request #1074](https://github.com/bigchaindb/bigchaindb/pull/1074))
- There were many additions and changes to the documentation. Fun fact: The JSON in the HTTP API docs is now auto-generated to be consistent with the current code.
- There's a draft spec for a BigchainDB Event Stream API and we welcome your feedback. See [Pull Request #1086](https://github.com/bigchaindb/bigchaindb/pull/1086)
- The big new thing in version 0.8.0 is support for divisible assets, i.e. assets like carrots or thumbtacks, where the initial CREATE transaction can register/create some amount (e.g. 542 carrots), the first TRANSFER transaction can split that amount across multiple owners, and so on. [Pull Request #794](https://github.com/bigchaindb/bigchaindb/pull/794)
- Wrote a formal schema for the JSON structure of transactions. Transactions are now checked against that schema. [Pull Request #798](https://github.com/bigchaindb/bigchaindb/pull/798)
- Wrote a formal schema for the JSON structure of transactions. [Pull Request #798](https://github.com/bigchaindb/bigchaindb/pull/798)
- New configuration parameter: `backlog_reassign_delay`. [Pull Request #883](https://github.com/bigchaindb/bigchaindb/pull/883)
### Changed
@ -40,7 +734,7 @@ committed:
- Renamed "verifying key" to "public key". Renamed "signing key" to "private key". Renamed "vk" to "pk". [Pull Request #807](https://github.com/bigchaindb/bigchaindb/pull/807)
- `get_transaction_by_asset_id` now ignores invalid transactions. [Pull Request #810](https://github.com/bigchaindb/bigchaindb/pull/810)
- `get_transaction_by_metadata_id` now ignores invalid transactions. [Pull Request #811](https://github.com/bigchaindb/bigchaindb/pull/811)
- Updates to the configs and scripts for deploying a test network on AWS. The example config file deploys virtual machines running Ubuntu 16.04 now. Pull Requests
- Updates to the configs and scripts for deploying a test network on AWS. The example config file deploys virtual machines running Ubuntu 16.04 now. Pull Requests
- Changed logging of transactions on block creation so now it just says the length of the list of transactions, rather than listing all the transactions. [Pull Request #861](https://github.com/bigchaindb/bigchaindb/pull/861)
2. an `assignee`: the public key of the node it was assigned to.
- The `assignment_timestamp` wasn't removed before writing the transaction to a block. That was fixed in [Pull Request #627](https://github.com/bigchaindb/bigchaindb/pull/627)
- The `assignment_timestamp` and `assignee` weren't removed in the response to an HTTP API request sent to the `/api/v1/transactions/<txid>` endpoint. That was fixed in [Pull Request #646](https://github.com/bigchaindb/bigchaindb/pull/646)
- When validating a TRANSFER transaction, if any fulfillment refers to a transaction that's _not_ in a valid block, then the transaction isn't valid. This wasn't checked before but it is now. [Pull Request #629](https://github.com/bigchaindb/bigchaindb/pull/629)
- When validating a TRANSFER transaction, if any fulfillment refers to a transaction that's _not_ in a valid block, then the transaction isn't valid. This wasn't checked before but it is now. [Pull Request #629](https://github.com/bigchaindb/bigchaindb/pull/629)
- Round timestamps to a precision of one second, and replace payload hash with payload UUID in transactions: [Pull Request #384](https://github.com/bigchaindb/bigchaindb/pull/384)
- Updated cryptoconditions API usage: [Pull Request #373](https://github.com/bigchaindb/bigchaindb/pull/373)
- Updated cryptoconditions API usage: [Pull Request #373](https://github.com/bigchaindb/bigchaindb/pull/373)
- The block processes now use GroupProcess: [Pull Request #267](https://github.com/bigchaindb/bigchaindb/pull/267)
- Replaced the `json` Python package with `rapidjson` (a Python wrapper for a fast JSON parser/generator written in C++), to speed up JSON serialization and deserialization: [Pull Request #318](https://github.com/bigchaindb/bigchaindb/pull/318)
- Overhauled `ROADMAP.md` and moved it to [the bigchaindb/org repository](https://github.com/bigchaindb/org): Pull Requests
- Overhauled `ROADMAP.md` and moved it to [the bigchaindb/org repository](https://github.com/bigchaindb/org): Pull Requests
@ -358,18 +1052,18 @@ committed: April 26, 2016, 11:09 AM GMT+2
- Ability to use environment variables to set (or partially set) configuration settings: [Pull Request #153](https://github.com/bigchaindb/bigchaindb/pull/153)
- `bigchaindb --version`, and one central source for the current version (`version.py`): [Pull Request #208](https://github.com/bigchaindb/bigchaindb/pull/208)
There are many ways you can contribute to the BigchainDB project, some very easy and others more involved. We want to be friendly and welcoming to all potential contributors, so we ask that everyone involved abide by some simple guidelines outlined in our [Code of Conduct](./CODE_OF_CONDUCT.md).
## Easy Ways to Contribute
The BigchainDB community has a Google Group and a Gitter chatroom. Our [Community page](https://www.bigchaindb.com/community) has more information about those.
You can also follow us on Twitter [@BigchainDB](https://twitter.com/BigchainDB) or read [our blog on Medium](https://medium.com/the-bigchaindb-blog).
If you want to file a bug report, suggest a feature, or ask a code-related question, please go to the `bigchaindb/bigchaindb` repository on GitHub and [create a new Issue](https://github.com/bigchaindb/bigchaindb/issues/new). (You will need a [GitHub account](https://github.com/signup/free) (free).) Please describe the issue clearly, including steps to reproduce when it is a bug.
## How to Contribute Code or Documentation
### Step 0 - Decide on an Issue to Resolve, or Create One
We want you to feel like your contributions (pull requests) are welcome, but if you contribute something unnecessary, unwanted, or perplexing, then your experience may be unpleasant. Your pull request may sit gathering dust as everyone scratches their heads wondering what to do with it.
To prevent that situation, we ask that all pull requests should resolve, address, or fix an existing issue. If there is no existing issue, then you should create one first. That way there can be commentary and discussion first, and you can have a better idea of what to expect when you create a corresponding pull request.
When you submit a pull request, please mention the issue (or issues) that it resolves, e.g. "Resolves #123".
Exception: hotfixes and minor changes don't require a pre-existing issue, but please write a thorough pull request description.
### Step 1 - Prepare and Familiarize Yourself
To contribute code or documentation, you need a [GitHub account](https://github.com/signup/free).
Familiarize yourself with how we do coding and documentation in the BigchainDB project, including:
* [our Python Style Guide](PYTHON_STYLE_GUIDE.md) (includes how we write tests)
* [Make sure you have the latest Python 3 version of pip and setuptools](https://docs.bigchaindb.com/projects/server/en/latest/appendices/install-latest-pip.html)
### Step 3 - Fork bigchaindb on GitHub
In your web browser, go to [the BigchainDB repository on GitHub](https://github.com/bigchaindb/bigchaindb) and click the `Fork` button in the top right corner. This creates a new Git repository named `bigchaindb` in _your_ GitHub account.
### Step 4 - Clone Your Fork
(This only has to be done once.) In your local terminal, use Git to clone _your_`bigchaindb` repository to your local computer. Also add the original GitHub bigchaindb/bigchaindb repository as a remote named `upstream` (a convention):
### Step 5 - Fetch and Merge the Latest from `upstream/master`
Switch to the `master` branch locally, fetch all `upstream` branches, and merge the just-fetched `upstream/master` branch with the local `master` branch:
```text
git checkout master
git fetch upstream
git merge upstream/master
```
### Step 6 - Install the Python module and the CLI
In order to use and run the source you just cloned from your fork, you need to install BigchainDB on your computer.
The core of BigchainDB is a Python module you can install using the standard [Python packaging tools](http://python-packaging-user-guide.readthedocs.org/en/latest/).
We highly suggest you use `pip` and `virtualenv` to manage your local development.
If you need more information on how to do that, refer to the *Python Packaging User Guide* to [install `pip`](http://python-packaging-user-guide.readthedocs.org/en/latest/installing/#requirements-for-installing-packages) and to [create your first `virtualenv`](http://python-packaging-user-guide.readthedocs.org/en/latest/installing/#creating-virtual-environments).
Once you have `pip` installed and (optionally) you are in a virtualenv, go to the root of the repository (i.e. where the `setup.py` file is), and type:
```text
pip install -e .[dev]
```
This will install the BigchainDB Python module, the CLI, and all the dependencies useful for contributing to the development of BigchainDB.
How? Let's split the command down into its components:
- `pip` is the Python command to install packages
- `install` tells pip to use the *install* action
- `-e` installs a project in [editable mode](https://pip.pypa.io/en/stable/reference/pip_install/#editable-installs)
- `.` installs what's in the current directory
- `[dev]` adds some [extra requirements](https://setuptools.readthedocs.io/en/latest/setuptools.html#declaring-extras-optional-features-with-their-own-dependencies) to the installation. (If you are curious, open `setup.py` and look for `dev` in the `extras_require` section.)
Aside: An alternative to `pip install -e .[dev]` is `python setup.py develop`.
### Step 7 - Create a New Branch for Each Bug/Feature
If your new branch is to **fix a bug** identified in a specific GitHub Issue with number `ISSNO`, then name your new branch `bug/ISSNO/short-description-here`. For example, `bug/67/fix-leap-year-crash`.
If your new branch is to **add a feature** requested in a specific GitHub Issue with number `ISSNO`, then name your new branch `feat/ISSNO/short-description-here`. For example, `feat/135/blue-background-on-mondays`.
Otherwise, please give your new branch a short, descriptive, all-lowercase name.
```text
git checkout -b new-branch-name
```
### Step 8 - Make Edits, git add, git commit
With your new branch checked out locally, make changes or additions to the code or documentation. Remember to:
* write and run tests for any new or changed code. There's a section in [our Python Style Guide](PYTHON_STYLE_GUIDE.md) about writing and running tests.
* add or update documentation as necessary. Follow [our documentation strategy](./docs/README.md).
As you go, git add and git commit your changes or additions, e.g.
```text
git add new-or-changed-file-1
git add new-or-changed-file-2
git commit -m "Short description of new or changed things"
```
You will want to merge changes from upstream (i.e. the original repository) into your new branch from time to time, using something like:
```text
git fetch upstream
git merge upstream/master
```
Once you're done commiting a set of new things and you're ready to submit them for inclusion, please be sure to run all the tests (as per the instructions at the end of our [Python Style Guide](PYTHON_STYLE_GUIDE.md)).
(When you submit your pull request [following the instructions below], we run all the tests automatically, so we will see if some are failing. If you don't know why some tests are failing, you can still submit your pull request, but be sure to note the failing tests and to ask for help with resolving them.)
### Step 9 - Push Your New Branch to origin
Make sure you've commited all the additions or changes you want to include in your pull request. Then push your new branch to origin (i.e. _your_ remote bigchaindb repository).
```text
git push origin new-branch-name
```
### Step 10 - Create a Pull Request
Go to the GitHub website and to _your_ remote bigchaindb repository (i.e. something like https://github.com/your-user-name/bigchaindb).
See [GitHub's documentation on how to initiate and send a pull request](https://help.github.com/articles/using-pull-requests/). Note that the destination repository should be `bigchaindb/bigchaindb` and the destination branch will be `master` (usually, and if it's not, then we can change that if necessary).
If this is the first time you've submitted a pull request to BigchainDB, then you must read and accept the Contributor License Agreement (CLA) before we can merge your contributions. That can be found at [https://www.bigchaindb.com/cla](https://www.bigchaindb.com/cla).
Once you accept and submit the CLA, we'll email you with further instructions. (We will send you a long random string to put in the comments section of your pull request, along with the text, "I have read and agree to the terms of the BigchainDB Contributor License Agreement.")
Someone will then merge your branch or suggest changes. If we suggest changes, you won't have to open a new pull request, you can just push new code to the same branch (on `origin`) as you did before creating the pull request.
## Quick Links
* [BigchainDB Community links](https://www.bigchaindb.com/community)
This document is for whoever has the ability to merge pull requests in the Git repositories associated with BigchainDB.
If the pull request is from an employee of ascribe GmbH, then you can ignore this document.
If the pull request is from someone who is _not_ an employee of ascribe, then:
* Have they agreed to the Individual Contributor Agreement in the past? (Troy, Greg, and others have a list.) If yes, then you can merge the PR and ignore the rest of this document.
* Do they belong to a company or organization which agreed to the Entity Contributor Agreement in the past, and will they be contributing on behalf of that company or organization? (Troy, Greg, and others have a list.) If yes, then you can merge the PR and ignore the rest of this document.
* Otherwise, go to the pull request in question and post a comment using this template:
Hi @nameofuser
Before we can merge this pull request, we need you or your organization to agree to one of our contributor agreements. One of the big concerns for people using and developing open source software is that someone who contributed to the code might claim the code infringes on their copyright or patent. To guard against this, we ask all our contributors to sign a Contributor License Agreement. This gives us the right to use the code contributed and any patents the contribution relies on. It also gives us and our users comfort that they won't be sued for using open source software. We know it's a hassle, but it makes the project more reliable in the long run. Thank you for your understanding and your contribution!
If you are contributing on behalf of yourself (and not on behalf of your employer or another organization you are part of) then you should:
1. Go to: https://www.bigchaindb.com/cla/
2. Read the Individual Contributor Agreement
3. Fill in the form "For Individuals"
4. Check the box to agree
5. Click the SEND button
If you're contributing as an employee, and/or you want all employees of your employing organization to be covered by our contributor agreement, then someone in your organization with the authority to enter agreements on behalf of all employees must do the following:
1. Go to: https://www.bigchaindb.com/cla/
2. Read the Entity Contributor Agreement
3. Fill in the form "For Organizations”
4. Check the box to agree
5. Click the SEND button
We will email you (or your employer) with further instructions.
(END OF COMMENT)
Once they click SEND, we (ascribe) will get an email with the information in the form. (Troy gets those emails for sure, I'm not sure who else.) The next step is to send an email to the email address submitted in the form, saying something like (where the stuff in [square brackets] should be replaced):
Hi [NAME],
The next step is for you to copy the following block of text into the comments of Pull Request #[NN] on GitHub:
BEGIN BLOCK
This is to confirm that I agreed to and accepted the BigchainDB [Entity/Individual] Contributor Agreement at https://www.bigchaindb.com/cla/ and to represent and warrant that I have authority to do so.
[Insert long random string here. One good source of those is https://www.grc.com/passwords.htm ]
END BLOCK
(END OF EMAIL)
The next step is to wait for them to copy that comment into the comments of the indicated pull request. Once they do so, it's safe to merge the pull request.
For all code in this repository, BigchainDB GmbH ("We") either:
## Copyrights
1. owns the copyright, or
2. owns the right to sublicense it (because all external contributors must agree to a Contributor License Agreement).
For all the code and documentation in this repository, the copyright is owned by one or more of the following:
Therefore We can choose how to license all the code in this repository. We can license it to Joe Xname under one license and Company Yname under a different license.
- BigchainDB GmbH
- A BigchainDB contributor who agreed to a BigchainDB Contributor License Agreement (CLA) with BigchainDB GmbH. (See [BEP-16](https://github.com/bigchaindb/BEPs/tree/master/16).)
- A BigchainDB contributor who signed off on the Developer Certificate of Origin (DCO) for all their contributions. (See [BEP-24](https://github.com/bigchaindb/BEPs/tree/master/24).)
- (Rarely, see the **Exceptions Section** below) A third pary who licensed the code in question under an open source license.
The two general options are:
## Code Licenses
1. You can get it under a commercial license for a fee. We can negotiate the terms of that license. It's not like we have some standard take-it-or-leave it commercial license. If you want to modify it and keep your modifications private, then that's certainly possible. Just ask.
2. You can get it under the AGPLv3 license for free. You don't even have to ask us. That's because all code in _this_ repository is licensed under the GNU Affero General Public License version 3 (AGPLv3), the full text of which can be found at [http://www.gnu.org/licenses/agpl.html](http://www.gnu.org/licenses/agpl.html).
All code in this repository, including short code snippets in the documentation, but not including the **Exceptions** noted below, is licensed under the Apache License, Version 2.0, the full text of which can be found at [http://www.apache.org/licenses/LICENSE-2.0](http://www.apache.org/licenses/LICENSE-2.0).
If you don't like the AGPL license, then just ignore it. It doesn't affect any other license.
For the licenses on all other BigchainDB-related code (i.e. in other repositories), see the LICENSE file in the associated repository.
All short code snippets embedded in the official BigchainDB _documentation_ are also licensed under the Apache License, Version 2.0, the full text of which can be found at [http://www.apache.org/licenses/LICENSE-2.0](http://www.apache.org/licenses/LICENSE-2.0).
## Documentation Licenses
For the licenses on all other BigchainDB-related code, see the LICENSE file in the associated repository.
The official BigchainDB documentation, _except for the short code snippets embedded within it_, is licensed under a Creative Commons Attribution 4.0 International license, the full text of which can be found at [http://creativecommons.org/licenses/by/4.0/legalcode](http://creativecommons.org/licenses/by/4.0/legalcode).
# Documentation Licenses
## Exceptions
The official BigchainDB documentation, _except for the short code snippets embedded within it_, is licensed under a Creative Commons Attribution-ShareAlike 4.0 International license, the full text of which can be found at [http://creativecommons.org/licenses/by-sa/4.0/legalcode](http://creativecommons.org/licenses/by-sa/4.0/legalcode).
The contents of the `k8s/nginx-openresty/` directory are licensed as described in the `LICENSE.md` file in that directory.
SPDX-License-Identifier: (Apache-2.0 AND CC-BY-4.0)
Code is Apache-2.0 and docs are CC-BY-4.0
--->
# Python Style Guide
This guide starts out with our general Python coding style guidelines and ends with a section on how we write & run (Python) tests.
@ -6,7 +13,10 @@ This guide starts out with our general Python coding style guidelines and ends w
Our starting point is [PEP8](https://www.python.org/dev/peps/pep-0008/), the standard "Style Guide for Python Code." Many Python IDEs will check your code against PEP8. (Note that PEP8 isn't frozen; it actually changes over time, but slowly.)
BigchainDB uses Python 3.4+, so you can ignore all PEP8 guidelines specific to Python 2.
BigchainDB uses Python 3.5+, so you can ignore all PEP8 guidelines specific to Python 2.
We use [pre-commit](http://pre-commit.com/) to check some of the rules below before every commit but not everything is realized yet.
The hooks we use can be found in the [.pre-commit-config.yaml](https://github.com/bigchaindb/bigchaindb/blob/master/.pre-commit-config.yaml) file.
### Python Docstrings
@ -47,8 +57,15 @@ It seems the preference is for slashes, but using parentheses is okay too. (Ther
If you need to `import` lots of names from a module or package, and they won't all fit in one line (without making the line too long), then use parentheses to spread the names across multiple lines, like so:
```python
from Tkinter import (
Tk, Frame, Button, Entry, Canvas, Text,
LEFT, DISABLED, NORMAL, RIDGE, END,
)
# Or
from Tkinter import (Tk, Frame, Button, Entry, Canvas, Text,
LEFT, DISABLED, NORMAL, RIDGE, END)
LEFT, DISABLED, NORMAL, RIDGE, END)
```
For the rationale, see [PEP 328](https://www.python.org/dev/peps/pep-0328/#rationale-for-parentheses).
we use the `format()` version. The [official Python documentation says](https://docs.python.org/2/library/stdtypes.html#str.format), "This method of string formatting is the new standard in Python 3, and should be preferred to the % formatting described in String Formatting Operations in new code."
## Runnng the Flake8 Style Checker
## Running the Flake8 Style Checker
We use [Flake8](http://flake8.pycqa.org/en/latest/index.html) to check our Python code style. Once you have it installed, you can run it using:
We write unit tests for our Python code using the [pytest](http://pytest.org/latest/) framework.
The content of this section was moved to [`bigchaindb/tests/README.md`](https://github.com/bigchaindb/bigchaindb/blob/master/tests/README.md).
All tests go in the `bigchaindb/tests` directory or one of its subdirectories. You can use the tests already in there as templates or examples.
You can run all unit tests using:
```text
py.test -v
```
or, if that doesn't work, try:
```text
python -m pytest -v
```
or:
```text
python setup.py test
```
If you want to learn about all the things you can do with pytest, see [the pytest documentation](http://pytest.org/latest/).
**Automated testing of pull requests.** We use [Travis CI](https://travis-ci.com/), so that whenever someone creates a new BigchainDB pull request on GitHub, Travis CI gets the new code and does _a bunch of stuff_. You can find out what we tell Travis CI to do in [the `.travis.yml` file](.travis.yml): it tells Travis CI how to install BigchainDB, how to run all the tests, and what to do "after success" (e.g. run `codecov`). (We use [Codecov](https://codecov.io/) to get a rough estimate of our test coverage.)
Note: We automatically run all tests on all pull requests (using Travis CI), so you should definitely run all tests locally before you submit a pull request. See the above-linked README file for instructions.
[](https://gitter.im/bigchaindb/bigchaindb?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
# BigchainDB Server
BigchainDB is a scalable blockchain database. [The whitepaper](https://www.bigchaindb.com/whitepaper/) explains what that means.
BigchainDB is the blockchain database. This repository is for _BigchainDB Server_.
### [Set Up & Run a Dev/Test Node](https://docs.bigchaindb.com/projects/server/en/latest/dev-and-test/setup-run-node.html)
### [Run BigchainDB Server with Docker](https://docs.bigchaindb.com/projects/server/en/latest/appendices/run-with-docker.html)
* [Try the Quickstart](https://docs.bigchaindb.com/projects/server/en/latest/quickstart.html)
* [Read the BigchainDB 2.0 whitepaper](https://www.bigchaindb.com/whitepaper/)
* [Check out the _Hitchiker's Guide to BigchainDB_](https://www.bigchaindb.com/developers/guide/)
## Run and Test BigchainDB Server from the `master` Branch
Running and testing the latest version of BigchainDB Server is easy. Make sure you have a recent version of [Docker Compose](https://docs.docker.com/compose/install/) installed. When you are ready, fire up a terminal and run:
[](https://gitter.im/bigchaindb/bigchaindb?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
[](https://gitter.im/bigchaindb/bigchaindb?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
# BigchainDB 서버
BigchaingDB는 블록체인 데이터베이스입니다. 이 저장소는 _BigchaingDB 서버_를 위한 저장소입니다.
### 기본 사항
* [빠른 시작 사용해보기](https://docs.bigchaindb.com/projects/server/en/latest/quickstart.html)
* [BigchainDB에 대한 _Hitchiker's Guide_를 확인십시오.](https://www.bigchaindb.com/developers/guide/)
### `master` Branch에서 BigchainDB 서버 실행 및 테스트
BigchaingDB 서버의 최신 버전을 실행하고 테스트하는 것은 어렵지 않습니다. [Docker Compose](https://docs.docker.com/compose/install/)의 최신 버전이 설치되어 있는지 확인하십시오. 준비가 되었다면, 터미널에서 다음을 실행하십시오.
SPDX-License-Identifier: (Apache-2.0 AND CC-BY-4.0)
Code is Apache-2.0 and docs are CC-BY-4.0
--->
# Our Release Process
## Notes
BigchainDB follows
[the Python form of Semantic Versioning](https://packaging.python.org/tutorials/distributing-packages/#choosing-a-versioning-scheme)
(i.e. MAJOR.MINOR.PATCH),
which is almost identical
to [regular semantic versioning](http://semver.org/), but there's no hyphen, e.g.
- `0.9.0` for a typical final release
- `4.5.2a1` not `4.5.2-a1` for the first Alpha release
- `3.4.5rc2` not `3.4.5-rc2` for Release Candidate 2
**Note 1:** For Git tags (which are used to identify releases on GitHub), we append a `v` in front. For example, the Git tag for version `2.0.0a1` was `v2.0.0a1`.
**Note 2:** For Docker image tags (e.g. on Docker Hub), we use longer version names for Alpha, Beta and Release Candidate releases. For example, the Docker image tag for version `2.0.0a2` was `2.0.0-alpha2`.
We use `0.9` and `0.9.0` as example version and short-version values below. You should replace those with the correct values for your new version.
We follow [BEP-1](https://github.com/bigchaindb/BEPs/tree/master/1), which is our variant of C4, the Collective Code Construction Contract, so a release is just a [tagged commit](https://git-scm.com/book/en/v2/Git-Basics-Tagging) on the `master` branch, i.e. a label for a particular Git commit.
The following steps are what we do to release a new version of _BigchainDB Server_. The steps to release the Python Driver are similar but not the same.
## Steps
1. Create a pull request where you make the following changes:
- Update `CHANGELOG.md`
- Update all Docker image tags in all Kubernetes YAML files (in the `k8s/` directory).
For example, in the files:
- `k8s/bigchaindb/bigchaindb-ss.yaml` and
- `k8s/dev-setup/bigchaindb.yaml`
find the line of the form `image: bigchaindb/bigchaindb:0.8.1` and change the version number to the new version number, e.g. `0.9.0`. (This is the Docker image that Kubernetes should pull from Docker Hub.)
Keep in mind that this is a _Docker image tag_ so our naming convention is
a bit different; see Note 2 in the **Notes** section above.
- In `bigchaindb/version.py`:
- update `__version__` to e.g. `0.9.0` (with no `.dev` on the end)
- update `__short_version__` to e.g. `0.9` (with no `.dev` on the end)
- In the docs about installing BigchainDB (and Tendermint), and in the associated scripts, recommend/install a version of Tendermint that _actually works_ with the soon-to-be-released version of BigchainDB. You can find all such references by doing a search for the previously-recommended version number, such as `0.31.5`.
- In `setup.py`, _maybe_ update the development status item in the `classifiers` list. For example, one allowed value is `"Development Status :: 5 - Production/Stable"`. The [allowed values are listed at pypi.python.org](https://pypi.python.org/pypi?%3Aaction=list_classifiers).
2. **Wait for all the tests to pass!**
3. Merge the pull request into the `master` branch.
4. Go to the [bigchaindb/bigchaindb Releases page on GitHub](https://github.com/bigchaindb/bigchaindb/releases)
and click the "Draft a new release" button.
5. Fill in the details:
- **Tag version:** version number preceded by `v`, e.g. `v0.9.1`
- **Target:** the last commit that was just merged. In other words, that commit will get a Git tag with the value given for tag version above.
- **Title:** Same as tag version above, e.g `v0.9.1`
- **Description:** The body of the changelog entry (Added, Changed, etc.)
6. Click "Publish release" to publish the release on GitHub.
7. On your local computer, make sure you're on the `master` branch and that it's up-to-date with the `master` branch in the bigchaindb/bigchaindb repository (e.g. `git pull upstream master`). We're going to use that to push a new `bigchaindb` package to PyPI.
8. Make sure you have a `~/.pypirc` file containing credentials for PyPI.
9. Do `make release` to build and publish the new `bigchaindb` package on PyPI. For this step you need to have `twine` installed. If you get an error like `Makefile:135: recipe for target 'clean-pyc' failed` then try doing
```text
sudo chown -R $(whoami):$(whoami) .
```
10. [Log in to readthedocs.org](https://readthedocs.org/accounts/login/) and go to the **BigchainDB Server** project, then:
- Click on "Builds", select "latest" from the drop-down menu, then click the "Build Version:" button.
- Wait for the build of "latest" to finish. This can take a few minutes.
- Go to Admin --> Advanced Settings
and make sure that "Default branch:" (i.e. what "latest" points to)
is set to the new release's tag, e.g. `v0.9.1`.
(It won't be an option if you didn't wait for the build of "latest" to finish.)
Then scroll to the bottom and click "Save".
- Go to Admin --> Versions
and under **Choose Active Versions**, do these things:
1. Make sure that the new version's tag is "Active" and "Public"
2. Make sure the **stable** branch is _not_ active.
3. Scroll to the bottom of the page and click "Save".
11. Go to [Docker Hub](https://hub.docker.com/) and sign in, then:
- Click on "Organizations"
- Click on "bigchaindb"
- Click on "bigchaindb/bigchaindb"
- Click on "Build Settings"
- Find the row where "Docker Tag Name" equals `latest`
and change the value of "Name" to the name (Git tag)
of the new release, e.g. `v0.9.0`.
- If the release is an Alpha, Beta or Release Candidate release,
then a new row must be added.
You can do that by clicking the green "+" (plus) icon.
The contents of the new row should be similar to the existing rows
of previous releases like that.
- Click on "Tags"
- Delete the "latest" tag (so we can rebuild it)
- Click on "Build Settings" again
- Click on the "Trigger" button for the "latest" tag and make sure it worked by clicking on "Tags" again
- If the release is an Alpha, Beta or Release Candidate release,
then click on the "Trigger" button for that tag as well.
Congratulations, you have released a new version of BigchainDB Server!
SPDX-License-Identifier: (Apache-2.0 AND CC-BY-4.0)
Code is Apache-2.0 and docs are CC-BY-4.0
--->
# Acceptance test suite
This directory contains the acceptance test suite for BigchainDB.
The suite uses Docker Compose to set up a single BigchainDB node, run all tests, and finally stop the node. In the future we will add support for a four node network setup.
## Running the tests
It should be as easy as `make test-acceptance`.
Note that `make test-acceptance` will take some time to start the node and shutting it down. If you are developing a test, or you wish to run a specific test in the acceptance test suite, first start the node with `make start`. After the node is running, you can run `pytest` inside the `python-acceptance` container with:
```bash
docker-compose run --rm python-acceptance pytest <usewhateveroptionyouneed>
```
## Writing and documenting the tests
Tests are sometimes difficult to read. For acceptance tests, we try to be really explicit on what the test is doing, so please write code that is *simple* and easy to understand. We decided to use literate-programming documentation. To generate the documentation run:
SPDX-License-Identifier: (Apache-2.0 AND CC-BY-4.0)
Code is Apache-2.0 and docs are CC-BY-4.0
--->
# Overview
A high-level description of the files and subdirectories of BigchainDB.
There are three database tables which underpin BigchainDB: `backlog`, where incoming transactions are held temporarily until they can be consumed; `bigchain`, where blocks of transactions are written permanently; and `votes`, where votes are written permanently. It is the votes in the `votes` table which must be queried to determine block validity and order. For more in-depth explanation, see [the whitepaper](https://www.bigchaindb.com/whitepaper/).
## Files
### [`core.py`](./core.py)
### [`lib.py`](lib.py)
The `Bigchain` class is defined here. Most operations outlined in the [whitepaper](https://www.bigchaindb.com/whitepaper/) as well as database interactions are found in this file. This is the place to start if you are interested in implementing a server API, since many of these class methods concern BigchainDB interacting with the outside world.
The `BigchainDB` class is defined here. Most node-level operations and database interactions are found in this file. This is the place to start if you are interested in implementing a server API, since many of these class methods concern BigchainDB interacting with the outside world.
### [`models.py`](./models.py)
`Block`, `Transaction`, and `Asset` classes are defined here. The classes mirror the block and transaction structure from the [documentation](https://docs.bigchaindb.com/projects/server/en/latest/topic-guides/models.html), but also include methods for validation and signing.
`Block`, `Transaction`, and `Asset` classes are defined here. The classes mirror the block and transaction structure from the [documentation](https://docs.bigchaindb.com/projects/server/en/latest/data-models/index.html), but also include methods for validation and signing.
### [`consensus.py`](./config_utils.py)
### [`validation.py`](./validation.py)
Base class for consensus methods (verification of votes, blocks, and transactions). The actual logic is mostly found in `transaction` and `block` models, defined in [`models.py`](./models.py).
Base class for validation methods (verification of votes, blocks, and transactions). The actual logic is mostly found in `transaction` and `block` models, defined in [`models.py`](./models.py).
### [`processes.py`](./processes.py)
@ -26,16 +31,8 @@ Entry point for the BigchainDB process, after initialization. All subprocesses
Methods for managing the configuration, including loading configuration files, automatically generating the configuration, and keeping the configuration consistent across BigchainDB instances.
### [`monitor.py`](./monitor.py)
Code for monitoring speed of various processes in BigchainDB via `statsd` and Grafana. [See documentation.](https://docs.bigchaindb.com/projects/server/en/latest/clusters-feds/monitoring.html)
## Folders
### [`pipelines`](./pipelines)
Structure and implementation of various subprocesses started in [`processes.py`](./processes.py).
### [`commands`](./commands)
Contains code for the [CLI](https://docs.bigchaindb.com/projects/server/en/latest/server-reference/bigchaindb-cli.html) for BigchainDB.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
