Backend abstraction

The container backend Zoe uses is configurable at runtime. Internally there is an API that Zoe, in particular the scheduler, uses to communicate with the container backend. This document explains the API, so that new backends can be created and maintained.

Zoe assumes backends are composed of multiple nodes. In case the backend is not clustered or does not expose per-node information, it can be implemented in Zoe as exposing a single node.

Package structure

Backends are written in Python and live in the zoe_master/backends/ directory. Inside there is one Python package for each backend implementation.

To let Zoe use a new backend, its class must be imported in zoe_master/backends/interface.py and the _get_backend() function should be modified accordingly. Then the choices in zoe_lib/config.py for the configuration file should be expanded to include the new backend name.

More options to the configuration file can be added to support the new backend. Use the --<backend name>-<option name> convention for them.

API

Whenever Zoe needs to access the container backend it will create a new instance of the backend class. The class must be a child of zoe_master.backends.base.BaseBackend.

class zoe_master.backends.base.BaseBackend(conf)

The base class that all backends should implement.

init(state)

Initializes the backend. In general this includes finding the current API endpoint and opening a connection to it, negotiate the API version, etc. Here backend-related threads can be started, too. This method will be called only once at Zoe startup.

platform_state() → zoe_master.stats.ClusterStats

Get the platform state. This method should fill-in a new ClusterStats object at each call, with fresh statistics on the available nodes and resource availability. This information will be used for taking scheduling decisions.

shutdown()

Performs a clean shutdown of the resources used by Swarm backend. Any threads that where started in the init() method should be terminated here. This method will be called when Zoe shuts down.

spawn_service(service_instance: zoe_master.backends.service_instance.ServiceInstance)

Create a container for a service.

The backend translates all the configuration parameters given in the ServiceInstance object into backend-specific container options and starts the container.

This function should either:

• raise ZoeStartExecutionRetryException in case a temporary error is generated
• raise ZoeStartExecutionFatalException in case a fatal error is generated
• return a backend-specific ID that will be used later by Zoe to interact with the running container

terminate_service(service: zoe_lib.state.service.Service) → None

Terminate the container corresponding to a service.