Following a two-year hiatus of active development (and a working prototype), the Consensus team undertook a re-invigoration of the project and working hard to solidify an architectural foundation based on our initial prototype.
Over the course of 2021 onward, we have:
As noted on the main Roadmap page, we’ve revised the structure and focus of our upcoming milestones based on an MVP launch. Previously, the goals for the next few milestones were roughly:
Generally our focus on the pre-Alpha releases was enabling other developers to meaningfully engage with Aegir development, and putting the pieces in place to enable us to build out Drupal functionality to get us back to feature parity with Aegir3 (core).
With the pre-Alpha0 release, we completed the foundational implementation of
dispatcherd, and began the process of finalizing some tests and
documentation around the queue system’s architecture.
Originally we had the Drupal front-end components requesting tasks be run on the back-end via the dispatcherd Celery/RabbitMQ message queue component, triggering Ansible tasks to be run on the server side.
With the move to DDEV for local development, we more closely modeled the decoupled architecture of the front- and back-end components, where all communication should be managed through the message queue.
This allowed us to more easily build out a test-driven “front-end” daemon
relayd, and distinguished from the backend
dispatcherd), and rip
out the HTTP-based mechanism our prototype had used to get log data back to the frontend.
See Issue #71 and related issues for details.
While the focus here was on passing log information back to the front-end, this entailed completing the end-to-end communication over the message queue, which opens the door to building higher-level functionality.
dispatcherdcan run tasks in minions. (see #60).
Re-model variable structure for dispatching tasks (see #44).
Consolidate per-Task roles into Ansible task-files in Platform/Application-level roles. (see #91
Re-name Aegir entity classes, etc. (see #76).
One goal: define DX APIs to allow Aegir community devs to plug-in.
Another goal is to think through some outstanding architectural and workflow questions, considering our current understanding and goals for Aegir overall, in some ways broader than ever. For example: the data we pass between the front-end and back-end, and vice versa. where do we store its metadata? How do we maintain state of the system overall?
Also architecture-wise: codebases and sites are currently entity types, that are bundleable. Currently, to create one we inherit from a template/base class; there’s no other behaviour.
dispatcherdcan run more than just Ansible playbooks. (see #52).
Here we intended to explore the idea of making the back-end tasks “pluggable” in the sense that Ansible playbooks is only one possibility. Currently the obvious second back-end type would be Terraform, but we’ll use this case as a basis to make Aegir flexible as to what kind of tasks to run in the backend (could be shell scripts, other config management or provisioning tools, etc.)
While our direct work was on the backburner later in 2022 and 2023, a new pluggable Backend presented itself, in the form of Kubernetes. We’ve therefore taken up this aspect more directly.