cloud-cv/origami-daemon

A long running daemon for Origami to deploy and manage demos on CloudCV servers.

origami-daemon's Issues

Configure Logging

This needs to have a solid logging configured, so if anything goes wrong we can easily debug and solve the problem without any delay.
For this purpose configure both *Console as well as File logging.

Redirect celery worker logging to origamid logger

Make daemon fully python2 compatible.

There are some problems when running daemon with python2 like problems with relative_imports. Make the package completely python2.7 compatible.

Add more API routes.

Add the following API routes to the daemon.

• api/demo/redeploy/<demo_id>
• api/demo/logs/<demo_id>
• api/demo/purge/<demo_id>
• api/demo/help
• api/demo/details/<demo_id>

Admin routes

• api/admin/demo/status
• api/admin/demo/purge/all
• api/admin/demo/redeploy/all
• api/admin/demo/stop/all

Add tests.

Add unit tests and integration tests for the following modules.

• api
• tasks
• utils
• database

Docker containter build logs.

Add a feature to provide docker container build logs to user.
For this create a column of log file in database and keep populating those build logs to that directory. The logs should be served using origami-daemon.

Add feature to optionally get callback from user for deploy.

Since the deployment for the demo is done asynchronously the deployer is sent a response stating deployment has started. So as of now, user don't get notified whether the demo has been deployed or not. As a solution to this, we can optionally ask deployer for the callback URI, which we will make a ping request to once the demo is deployed, this will notify the user that demo has been deployed and is ready for use.

Add documentation

Add sphinx documentation similar to https://github.com/Cloud-CV/origami-lib

Set up JWT based authentication.

For now, we are assuming that both origami-server and deploy-manager are running on the same host, so there is no need to set up authentication for this, we can simply bind the server to the loopback address and then origami-server can communicate with it internally without being exposed outside the host. But at some point of time, we will need to extend to a different server, wherein one server will have all the demos and other running origami-server, for such cases we need some sort of authentication.

The method that I have in mind is authentication via JWT, we can simply use Nginx reverse proxy to set up TLS for origami-daemon(so we don't have to set up anything for origami-daemon) and then we can simply authenticate origami-server via JWT. This way we can also provide an admin panel sort of thing for demo deployment.

Add signal handling to properly exit the utility.

Add signal handling capability to the application so that it can handle SIG* and exit properly saving necessary states.