community.aegirproject.org

As usual, everyone we talked to at DrupalCon who has had to manage more then a handful of sites for more than a few months wants to use a provisioning system, and Aegir remains the only serious contender for that job. The potential demand to provide support and customization is as great as that for large scale Drupal deployment. In this spirit, there were two well-attended BoF sessions at DrupalCon Chicago about Aegir: one a presentation for people not already familiar with the project, and the other a roadmap planning session where the developers discussed their plans and asked the user community for feedback. Aegir has reached the release candidate stage for version 1.0, and so the time has come to decide what features should be added next after the last remaining bugs are finished for this release.

At the roadmap BoF, about half the attendees were from universities, and most of the others were smaller shops who were looking to sanely manage a dev/stage/live workflow. There were also people present using Aegir in a software-as-a-service model, a user who creates personalized sites for UK members of parliament on the fly based on imports from a CSV feed, and others interested by the project out of curiosity. Antoine and others from Koumbit presented their plans for the future of Aegir , then asked what other users wanted to see in future versions.

The most common requests were handling sites in subdirectories without their own domain name, and a GUI for DNS management. Handling Drupal's subdirectory based multidomains is a serious technical challenge which isn't likely to be solved in the version 1.x branch, but DNS management already works well from the drush command line, so will be easier to provide to the enduser. This would allow A and CNAME records to be edited directly by clients with appropriate permissions, and would allow users to easily add the special DNS records necessary to have Google handle their email with a single checkbox.

We also talked about the need for a more mature queue system based on a third-party tool. Antoine is planning to improve the queueing system by making it pluggable, so that the existing "ghetto queue" would be provided as a default implementation with no extra dependencies, but other, more robust systems could be used instead.

Other popular requests include:

• porting the existing ubercart integration to the commerce module
• reconsidering the current multi-server model, maybe based on the queue redesign - see http://community.aegirproject.org/node/284
• automatic upgrades - managing platforms and automatically create new ones based on feeds (e.g. from feature servers)
• D7 port of the frontend (backend already supports d7 installs and upgrades of course)
• improved intersite security
• handling for remote file storage
• hooks for post-migrate unit testing
• allowing cross-profile migration
• a dashboard style overview page for all sites pertaining to a given client or platform

The official Aegir project roadmap is here: http://community.aegirproject.org/node/35 It only covers plans up to version 1.0 at the moment, but it will be updated soon.

Some of these goals are more technically challenging than others, but each will solve common problems for the existing Aegir user base, and make managing a web cluster with Aegir attractive to ever more users. We at Koumbit are glad to see Aegir becoming an ever more useful tool for the Drupal community, and look forward to meeting other Aegir users at the next DrupalCon in London!