Spinning Up bos-auto
Now that bos-auto has been configured we want to make sure it works correctly. To do this, we need to start two processes:
An endpoint that takes incident reports from the data proxy and stores them in MongoDB as well as issues work for the worker via Redis.
The worker then takes those incidents and processes them.
Note: It is recommended to run both via system services.
The commands shown are for production installation, for debug installation replace “bos-auto” with “python3 cli.py”.
Note: Former installations also required to run the scheduler as a separate process. This is no longer necessary, it is spawned as a subprocess.
Start the Endpoint
This is a basic setup and uses the flask built-in development server, see Production Deployment below.
Important: Before executing the next command make sure that your node is set to the correct environment. For example, if the installation is for Testnet (Beatrice) run:
peerplays set node <Beatrice Node> where <Beatrice node> is any Beatrice API node.
cd bos-auto
bos-auto api --host 0.0.0.0 --port 8010 [--help for more information]After this, if it's set up correctly you'll see the following messages:
INFO | Opening Redis connection (redis://localhost/6379) * Running on http://0.0.0.0:8010/ (Press CTRL+C to quit)
This means that you can now send incidents to http://0.0.0.0:8010/.
Testing
You can test that the endpoint is properly running with the following command:
If the endpoint is running, the API daemon will print the following line:
At this point, we are done with setting up the endpoint and can go on to setting up the actual worker.
Delivery to Data Proxies
Data proxies are interested in this particular endpoint as they will push incidents to it. This means that you need to provide them with your IP address as well as the port that you opened above.
For more information on Data Proxies see:
DATA PROXIESMonitoring
The endpoint has an isalive call that should be used for monitoring:
which produces an output like:
Of interest here are the listed versions and queue.status.default.count.
The count should be zero most of the time, it reflects how many unhandled incidents are currently in the cache.
Production deployment
Going into production mode, a Witness may want to deploy the endpoint via UWSGI, create a local socket and hide it behind an SSL supported nginx that deals with a simple domain instead of ip:port pair, like https://dataproxy.mywitness.com/trigger.
Start worker
Important: At this point it's crucial to set the default Witness node to your own server (ideally running in localhost) using peerplays set node ws://ip:port. If this step is missed, the setup will not work or, at best, will work with very high latency.
Start the worker with the following commands:
It will already try to use the provided password to unlock the wallet and, if successful, return the following test:
Nothing else needs to be done at this point.
Testing
Important: For testing, we highly recommend that you set the nobroadcast flag in config.yaml to True
For testing, we need to throw a properly formatted incident at the endpoint. The following is an example of the file format,
Note: Because the incident data changes all the time and is quickly out of date, the actual contents of this file are unlikely to work. At the time of testing reach out to PBSA for some up to date incident data.
Store them in a file called replay.txt and run the following call:
Note the trigger at the end of the endpoint URL.
This will show you the incident and a load indicator at 100% once the incident has been successfully sent to the endpoint.
Your endpoint should return the following:
And your worker to return something along the lines of (once for each incident above):
Tip: Each incident results in two work items, namely a bookied.work.process() as well as a bookied.work.approve() call.
The former does the heavy lifting and may produce a proposal, while the latter approves proposals that we have created on our own.
Command Line Intervention
With the command line tool, we can connect to the MongoDB and inspect the incidents that we inserted above:
Where [Begin Date] and [End Date] specify the date range to pull incident data from.
The output should look like:
It tells you that two incidents for that particular match came in that both proposed to create the incident. The status tells us that the incidents have been processed.
We can now read the actual incidents with:
And replay any of the two incidents by using:
Tip: For more information on BOS supported commands run:
bos-auto --help or bos-incidents --help
Your worker should now be started.
Last updated
Was this helpful?