- 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?
- 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.
