Under open development at https://gitlab.com/aegir/aegir.
This roadmap will be regularly updated as we iterate, to reflect current progress and status.
We’ve recently revised our aspirational development schedule for the pre-Alpha and Alpha release cycle, attempting to project out as far as an RC0 release by Drupal 7 (official) EOL, although that target seems to be shifting as well.
For now, only the immediate next steps to get to Beta-quality software are clear to us, and we hope to inspire broader community engagement by that point, to help further refine and implement Aegir5!
We are currently in pre-alpha development stage. Having prototyped the basic architectural pieces to prove its utility, we are currently focused on solidifying an initial foundation, so that we can better enable the existing Aegir community to participate in the project.
Following a two-year hiatus of active development (and a working prototype), the Consensus team has been undertaking a re-invigoration of the project and working hard to solidify an architectural foundation based on our initial prototype.
In the last year or so, we have:
In broad strokes, the goals for the next few milestones are roughly:
Generally our focus on the pre-Alpha releases is 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 have completed the foundational implementation of
dispatcherd, and are in 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’ve 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 will 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.)
The focus of the Alpha releases will be to get us back to feature parity with Aegir3 core as it stands today. This is specifically just the bare bones of CRUD operations on D8+ sites (probably not even D7 support initially), in order that we can begin to use it in real environments, and thus inform where to direct further development efforts.
In more detail:
composer.lockin a similar way
Stabilizing, improving performance, etc.
For the adventurous :)
Figure out what packaging looks like. However it gets deployed should be automated as much as possible with any
.rpm, Snap/Flatpak etc. for distribution. Must be automated on release. Eliminate the current day-long release cycle.