Following the Drupalcon Chicago 2011 BOFs discussion, the community came up with a series of ideas and wishlist items for the upcoming 2.0 release. This roadmap may be updated or trimmed down as development goes ahead.

Port frontend to Drupal 7

We were originally planning to release 1.0 with Drupal 7 support to make sure it was a "long term support" release, but this has changed - we hope to keep the release cycle short and therefore Drupal 7 was pushed back to 2.0. But it is still a target to make sure we a reliable release that will be supported for a long time.

Drupal 7 also introduces the concept of entities which could be very useful to lighten our many content types in the frontend. It could also be useful for DNS support as zonefiles could be modeled directly as entities.

This concerns of course only the port of the frontend (hostmaster.profile, eldir.theme and hosting.module), the backend already supports d7 installs and upgrades.

Multi-server improvements

While Aegir 1.0 has multi-server support, it is far from ideal or complete, and we wish to harden that design in 2.0.

From a hub-spoke to a mesh model

The current model where there is one main server (the "hub") where all platforms and sites are created and then synced to remote servers (the "spokes") seems to be showing scalability issues and concerns about where the authoritative data should be.

For example, it's currently not recommended to allow developpers to access sites on remote servers, as the authoritative data resides on the hostmaster site. Another issue is that aliases are maintained only on the master server, and therefore are not accessible on remote servers. Finally, the fact that drush and provision are not installed on remote servers make some operations unnecessarily slow as we need to make the operation locally and then sync the result.

The alternative has yet to be discussed. We especially want to chime in with the Drush community here to see how the best practices should be. The conversation has started, and with the migration of Drupal.org to git, a lot of possibilities just opened up, with a lot of people being all of a sudden more familiar with this excellent too.

In general, it should be possible to expect remote servers to have drush and provision installed and be relatively independent from the "master" server. A design like this could eventually mean that Aegir could manage other Aegir sites and upgrade them. It is the "mesh" design, of which the "hub and spoke" model is only a subset.

This follows the practice of "tools not policy" we are heading towards: we leave the mesh vs hub/spoke decision to the site administrators and provide the tools to support both approaches the best we can.

Improve cluster support

The current multi-server model doesn't support clusters and shared filesystems very well. Aegir 2.0 should allow scaling your web hosts horizontally by spreading a single site amongst multiple servers. While 1.0 can setup sites on remote servers, it follows more the concept of "sharding", spreading different sites amongst different servers than load balancing all sites amongst all servers.

This involves supporting load balancers (e.g. IPVs, Pound, Varnish), maybe through the existing "cluster" service, but also shared filesystems (e.g. NFS, OCFS, GFS, GlusterFS), maybe through a new "fileserver" service.

Optimizing clones and migrates

We quickly mentionned git support above, but this could lead to significant improvements, for example by using git clone --shared instead of the traditional "backup and deploy" approach to clone/migrate sites.

There is certainly the possibility of rewriting clone to optimize away "backup and deploy" and merge them in a single operation that could use copy on write mechanisms like hardlinks (cp -al), git tricks (git clone --shared) or filesystem snapshots (e.g. BTRFS snapshot directory/file support).

This would need to integrate with and support the multi-server model elegantly too, especially the hypothetical fileserver service.

Modularization of more systems

Aegir 1.0 is already pretty modular: "services" are an abstract concept that can be implemented and inherited. For example, the "HTTP service" has four implementations: Apache, Apache-SSL, Nginx and Nginx-SSL. The database and DNS layers are also abstracted that way.

But more can be done here.

Modular backup system

Right now backups can be pretty heavy and use the venerable (1979!) tar backup format and utilities, which made Aegir portable to almost any UNIX operating system. It's a good start, but it's highly inefficient. As mentionned above for the clone and migrate optimization, we could also use modern filesystem features like snapshots or use git support. Another suggestion was to use S3 or similar services for offsite backups.

The basic idea here is that backups should be extendable - if you want to backup in your shoebox, Aegir should allow you to write a plugin for it.

Modular queuing system

The current queuing system is what we informally call the "ghetto queue". It's a cron job that pulls tasks from a MySQL database. While this scales well for a few sites, on busy servers it's a total nightmare, especially for mass migrations. Tasks stack up and concurrency is not managed at all. This needs to be completely redone.

A possibility is to use Drupal 7's abstracted queue API and let administrators implement their own queuing system according to their local APIs.

[... to be continued ...]

(see also this evaluation)

Unsorted items

• automatic upgrades - managing platforms and automatically create new ones based on feeds (e.g. from feature servers)
• backend PostgreSQL support - being able to setup databases and users for site installs on PostgreSQL
• statistics improvements (packages, quotas, bandwidth stats) - a dashboard-style overview page for all sites pertaining to a given client or platform
• optionnally hook up Drupal 7 unit testing in post-migrations
• full DNS support

porting the existing ubercart integration to the commerce module

improved intersite security hooks for post-migrate unit testing allowing cross-profile migration