New Docker Engine back-end, the Swarm back-end is now deprecated
Nodes and ZApps can be labelled for constraining execution placement, for example to run ZApps only on nodes with GPUs
Use non-reserved memory, cores, labels and image availability to take placement decisions
The elastic scheduler is considered stable, the simple scheduler is now deprecated
Expand the status page for the administrator
More information about authentications in the log output of zoe-api
Endpoint links in the web interface open in new windows
Distinguish between reserved, allocated and in-use resources
Allocate cores automatically, respecting the minimum configured in the ZApp
Small graphic updates to the execution inspect web page
Allow for more options and resource limits to be customized on the web interface (users or admins, not for guests), maximum limits are set in the zoe.conf file
Additional volumes can be mounted by specifying them in the zoe.conf file
Update unit and integration testing
Elastic services that die are rescheduled on a new node
Optional support for gathering usage metrics via KairosDB, for now these metrics are only used in the status page plots
Fix UTC and timezone bugs for execution timestamps
More configuration options for LDAP authentication
Major web UI redesign
New app shop, users can choose applications from a catalog in the web interface
New status page for administrators to check on the elastic scheduler status
Split command-line tools for user and admin tasks
Provide an integrated way of managing ZApp logs, by receiving UDP GELF messages into a simple directory structure
The elastic scheduler is now fully tested and ready for production use
Extensive documentation updates to the install procedure
ZApp description format revision
use JSON schemas to validate ZApps
Expand the execution list API, adding filtering capabilities to limit the number of results returned
Several minor bug fixes
Deployment scripts and zoe frontend moved to external repository for easier maintenance and testing
Removed proxy code
ZApps have been split into multiple repositories for easier maintenance, testing and automated building
Tyk or Kong can be used to provide SSL termination and authentication to the API
A new script create_db_tables.py can be used to create the schema in an empty database, useful for CI scenarios
Major documentation update
Deployment scripts to install Zoe on Linux (Kubernetes or Swarm back-ends) or Windows
Updated Swarm backend, uses the new Docker Python API
Zoe code now goes through an automated testing pipeline
Added unit and integration tests
Preview of the new AngularJS front-end
Log management bug fixes
Fix a bug with the scheduler time trigger
Sort by ID when listing execution from the command-line client
Service discovery API endpoint: simple, read-only, unauthenticated access to a list of DNS names of services. Needed for frameworks that need a list of hosts for configuration, can be used by scripts in the images.
Add -s option to the start command of the commandline client to have it wait for execution termination and stream the log meanwhile.
Add the workspace-deployment-path option in the configuration file. It should be used when the workspace path should be build not with the deployment name, but with something else.
All errors generated by docker while creating containers are now considered as fatal, except the "not enough free resource" one. When a fatal error is generated, Zoe will not try to start the execution again.
Error messages generated by Docker are now exposed to the user
(experimental) if the configuration option service-log-path is set, container output is saved from docker into the specified directory. If the logs are big, this can have a significant impact on execution termination time
This version is the start of a new series of releases moving toward a new architecture
Only one overlay network (created by the sysadmin) will be used by all Zoe executions. We provide Dockerfiles for SOCKS and SSHd containers that can be used to give users access inside the Zoe overlay network. These containers will no longer be managed by Zoe.
Move the REST API in the web process and add a ZeroMQ-based API between the web and the master.
Move all user management in the web process.
Use Postgresql to store the state
Rename the zoe-web component in zoe-api to better describe its new role
User authentication can be performed by a CSV text file or via LDAP
Check application description version during validation.
Bump application description version to 2 since we are going to make some major changes in the format
Add fields total_count, essential_count and startup_order to service descriptions.
Comment code related to the parsing of cluster statistics from Swarm. The data returned by API changes too often and parsing it consistently is too complex. A bug is open on the Swarm issue tracker.
Workspaces: Zoe now supports starting containers with a directory from the hosts mounted as a volume. The directory is private for the user and is not wiped when the Zoe execution terminates. There are some issues with file permissions when the container images define users with arbitrary UIDs.
Add an error status and error message visible to the user when Zoe fails starting an execution
Add a Docker Compose file to help test deployments
The gateway container image is now configurable
Move applications to their own repository (zoe-applications)
Move the Zoe logger code into its own repository
Update the stats module to the latest Docker version. Since the Python Docker API refuses to provide machine readable output, we have to stay locked to Docker versions
Add date and time to log output produced by Zoe processes
Expand the web interface, users can now list, start, terminate and restart executions