-
Notifications
You must be signed in to change notification settings - Fork 20
General: What's New?
This page documents key points in which the current version of Duffy (version 3.x) differs from the legacy one.
Legacy Duffy distinguished nodes by the version of the installed operating system (“CentOS” was assumed), their hardware architecture and their “flavor” (which indicated size of a node in terms of RAM and storage). Current Duffy is agnostic about these details, instead nodes are grouped into “pools” which share such properties, but only as a convention between the operator configuring them and tenants who use the service.
The current Duffy version supports arbitrary ways of provisioning through different, configurable Ansible playbooks. In order to support both bare metal and virtual/cloud deployment, Duffy can now differentiate between long-lived, reusable nodes (for physical deployments) and non-reusable, throw-away nodes which are created once, used and then discarded (usually for virtual machines or cloud). As before, nodes are provisioned ahead of time, so that they can be handed out quickly on request.
The current Duffy version implements a versioned REST API giving access to sessions, nodes and tenants. Tenants (the users of this service) create (or “request”) a session with their desired set of nodes from one or more pools (for example, 1 node of centos8stream-x86_64-big as a server and 3 nodes of fedora35-x86_64-small as clients). When done with testing, tenants “retire” the session with all contained nodes. This way, tenants can request (and retire) all nodes needed for testing in one step which either succeeds or fails, making handling of heterogeneous test setups easier than with Legacy Duffy which required separate requests for different types of nodes.
The current version comes with a metaclient, a separate service which translates between the old and new APIs.
For Legacy Duffy, there was a separate tool cicoclient to request and return nodes from the command line or in scripts. Current Duffy has this functionality integrated in the duffy client ... group of commands.
- Duffy has been reimplemented completely using actively maintained dependencies, the minimum supported Python version is 3.8.
- Through SQLAlchemy, it supports SQLite and PostgreSQL database backends. PostgreSQL is recommended for production instances.
- It is available on PyPi: https://pypi.org/project/duffy/
- It contains a comprehensive test suite covering all areas of operation.
- The current Duffy web API is self-documenting and follows a more idiomatic CRUD/REST model than the legacy one.
- Longer-running and regularly scheduled tasks – provisioning/deprovisioning, expiration – are driven as Celery task workers, the communication between the web API and task workers is done through Redis. The actual logic to provision or deprovision nodes is outsourced to Ansible playbooks (not included) which lets operators use virtually arbitrary backends (bare metal through proprietary management console APIs, virtual machines through e.g. OpenNebula, cloud nodes through the respective cloud provider’s API).
- Duffy uses HTTP Basic Authentication, with the tenant’s user name and API key, which allows storing the latter as a cryptographical hash. Legacy Duffy used a custom HTTP GET parameter containing only the tenant’s API key as both identifier and credential, requiring to store the API key in plain text.