brewblox / brewblox-service Goto Github PK

Many features start long-running background tasks, and have to close them in their shutdown() function.

Centrally managing these tasks would reduce boilerplate code.

Use Registrator / Consul to look up url of features

Using old/ as a source, reimplement the Flask framework in new/.

Includes plugin manager, does not include SSE or InfluxDB.

resin/raspberry-pi-python is both not supported, and intended for Raspberry Pi 1 and Zero.

Correct should be resin/raspberrypi3-python

Brewpi-service should be split into separate API framework and Plugin repositories.

This is the API repository. It is responsible for:

• Flask REST API
• Flask plugin management
• SSE
• InfluxDB logging
• Event handling

Backend code (controllerbox or legacy) will be added to a separate repository.

For now the old code will be moved to a separate directory, until it can be removed completely.

If RabbitMQ is not online, the reconnect logs an error every second. This message should be prevented.

Cross compiled Raspberry Pi docker images are currently supported on brewblox-devcon-spark. This functionality should also be ported to brewblox-service

Docker + docker compose deployment of a service cloud

Configuration was simplified in brewblox-devcon-spark by introducing the .env file, and moving coveragerc to tox.ini

This should be ported to the other repositories

Swagger attempts to run the local spec through the online validator, and fails because that can't access the 192.168.0.5 address.

Service features often use values placed in app['config'] by commandline arguments.

It is not transparent which keys are used by which features. The ServiceFeature class should allow registering config keys in order to generate clear and concise error messages when config is not provided.

Whenever a new commit is pushed to an open PR, we should run our automated test in for example Travis and report test results and coverage.

brewblox_logger was implemented in brewblox-devcon-spark to preserve readable formatting in log messages when __name__ exceeded column width.

This is a generic feature best suited for implementation in service itself.

Docker containers on raspberry

Currently, all services assume they and everyone else are on localhost. This needs to be configurable.

Throughout the various services, there is a generic pattern of modules having setup(app) and get_<handler>(app) functions.

Individual handlers use a setup(app) to register startup an cleanup functions.

They may include other handlers by using get_handler(app) functions.

The ServiceHandler class already exists, but does not pass app, only loop.
Not all handlers use it yet either.

The pattern of using get_handler(app) functions also could use a review, as it has the potential to make the dependency tree very fragile and opaque.

We are interested in the following data points:

• Controller measurement values
• Controller block connected/disconnected
• UI block association with controller block added/removed
• Controller block configuration changed
• User added annotation to time point
• User sends command to controller
• Controller acknowledges command

We want to filter on the following data points / properties:

• events
• UI blocks
• hardware blocks
• annotations
• activity members
• process members
• composited UI block members
• time points

We want to simultaneously display data from (including all members):

• activities
• processes
• UI blocks
• hardware blocks

During docker image build, each child image of brewblox-service correctly inherits a filled /wheels directory, but does not skip building already-present wheels.

Use docker manifests to deploy multiple images for the same tag.

Both AMD and ARM pull brewblox/brewblox-service:latest, and both get the correct image.

push new events to clients

Create boilerplate configuration that can be copied for any new plugin project.

Should not include production code, but management boilerplate from things like setup.py, MANIFEST.in, tox.ini etc etc.

The service should accept new configuration
The service should return randomized values for each leaf node in the configuration when queried.

Not all services need both - don't start both when calling events.setup(app)

• Allow services to modify status output
• Connect status endpoint to Docker heartbeat