The container back-end Zoe uses is configurable at runtime. Internally there is an API that Zoe, in particular the scheduler, uses to communicate with the container back-end. This document explains the API, so that new back-ends can be created and maintained.
Zoe assumes back-ends are composed of multiple nodes. In case the back-end is not clustered or does not expose per-node information, it can be implemented in Zoe as exposing a single node.
Zoe assumes back-ends are composed of multiple nodes. In case the back-end is not clustered or does not expose per-node information, it can be implemented in Zoe as exposing a single big node. In this case, however, many of the smart scheduling features of Zoe will be unavailable.
@@ -31,14 +31,4 @@ Using the Docker executor, we configured our runner with these options::
[runners.cache]
Insecure = false
Please note that since our private registry is protected with TLS, we need to pass also the CA certificate to be able to push Docker images build inside the CI pipeline.
Variables
---------
To run the tests a number of variables need to be set from the GitLab interface:
* SSH_PRIVATE_KEY: private key to be used to deploy via rsync the staging build
* STAGING_IP: IP/hostname of the staging server
* WEB_STAGING_PATH: path for the web interface on the staging server
* ZOE_STAGING_PATH: path for Zoe on the staging server
Please note that since our private registry is protected with TLS, we need to pass also the CA certificate to be able to push Docker images built inside the CI pipeline.
@@ -7,19 +7,13 @@ Zoe can be used from the command line or the web interface. For more complex tas
The API is provided by the zoe-api processes, on the same port of the web interface (5001 by default). Every URL of the API contains, after the hostname and port, the path ``/api/<api version>/``. **The current API version is 0.7**.
In case the request causes an error, an appropriate HTTP status code is returned. The reply will also contain a JSON document in this format::
{
"message": "missing or wrong authentication information"
}
With an error message detailing the kind of error that happened.
In case the request causes an error, an appropriate HTTP status code is returned. The Status header will also contain a human-readable string detailing the error.
Some endpoints require credentials for authentication. The API uses HTTP Basic authentication. After the first successful authentication, a cookie will be returned in the response headers. The cookie can be used as an authentication token for the subsequent requests.
Login endpoint
--------------
Get back a cookie for further authentication/authorization with other api endpoints instead of using HTTP basic username, password
Get back a cookie for further authentication/authorization with other api endpoints instead of using HTTP basic for each request.