We need to move the service to the single repo, improve it, and make the deployment-manager, to be renamed in sut-deployment-manager, more stable and expositing new APIs to be ready for future development.
APIs:
Mirror the docker-compose (even better the Docker stack APIs), in a more reliable and stronger way to also check when the system is ready:
As part f the test definition we currently allow the users to specify a regular expression to check for in the log, to detect when the system is ready. We should add this information as part of the sut docker-compose using a label, so that it can be passed to sut-deployment-manager that can take care of checking the status respond back to Faban client, that has to wait/poll since we cannot send (at least for now) callbacks to Faban.
We need also to expose APIs to obtain list of available servers, so it can be used to validate the request obtained from the user (initially every time, then with caching). For this we probably need at least: alias (maybe hostname), local_network_ip/privateip, public (we need something similar to the following but in Java: http://stackoverflow.com/questions/691045/how-do-you-determine-if-an-ip-address-is-private-in-python)
Manage Dynamically Added Machines:
Docker machine if we need to be dynamic in adding machines. Since there is no Java library for Docker machine we can create a wrapper for the command line taking inspiration from the Python wrapper to Docker Machine, and by following the following reference: http://alvinalexander.com/java/java-exec-processbuilder-process-1
Deployment:
Docker and Docker Swarm mode store data on volumes, so I need to add named volumes so that information can survive to service restart.
Current (Accepted) Limitations:
For now still fine behind the firewall, then not work with docker hosts having certificates to connect to the API, or if swarm mode does it, then do it and init the swarm in the service.
We need to move the service to the single repo, improve it, and make the
deployment-manager
, to be renamed insut-deployment-manager
, more stable and expositing new APIs to be ready for future development.APIs:
docker-compose
(even better the Dockerstack
APIs), in a more reliable and stronger way to also check when the system is ready:test
definition we currently allow the users to specify a regular expression to check for in the log, to detect when the system is ready. We should add this information as part of the sutdocker-compose
using alabel
, so that it can be passed tosut-deployment-manager
that can take care of checking the status respond back to Faban client, that has to wait/poll since we cannot send (at least for now) callbacks to Faban.Among the other things to consider we hare:
Storing Infrastructure Knowledge:
We need also to expose APIs to obtain list of available servers, so it can be used to validate the request obtained from the user (initially every time, then with caching). For this we probably need at least: alias (maybe hostname), local_network_ip/privateip, public (we need something similar to the following but in Java: http://stackoverflow.com/questions/691045/how-do-you-determine-if-an-ip-address-is-private-in-python)
Manage Dynamically Added Machines:
Docker machine if we need to be dynamic in adding machines. Since there is no Java library for Docker machine we can create a wrapper for the command line taking inspiration from the Python wrapper to Docker Machine, and by following the following reference: http://alvinalexander.com/java/java-exec-processbuilder-process-1
Deployment:
Docker and Docker Swarm mode store data on volumes, so I need to add named volumes so that information can survive to service restart.
Current (Accepted) Limitations:
For now still fine behind the firewall, then not work with docker hosts having certificates to connect to the API, or if swarm mode does it, then do it and init the swarm in the service.