Progress update - Frontend and Backend are now completely separate. Experimental multi-server support.

One of the major changes to Aegir for the 0.2 release, is integrating with Drush 2.x.

What this comes down to is that, like Drush, Provision has ceased being a 'module' in the traditional sense.
Each server that Aegir manages will now need to have one instance of Drush, and one instance of Provision.

This resulted in some refactoring in the Hosting module, as it was depending on Provision being available as a module for a number of things.

One of the other things that I added to the code in HEAD, once the refactoring had taken place, is the ability to call instances of Drush and Provision on remote servers. This means that you can now install, enable, disable, delete, backup, roll back , and upgrade Drupal sites on multiple servers, that are managed by Aegir.

We already manage the information necessary to make it happen, and the clean design meant that adding this feature ended up being
a total of 4 lines of additional code. This is still pretty basic, and we haven't even begun solving some of the biggest related issues, such
as simplifying ssh key management and deployment and being able to migrate sites between servers.

Further issues creep in when you factor in the fact that our object model for managing servers needs to be refactored. We currently have distinct nodes for the web server, database server and DNS server, where the correct model would be to have a 'server' node type with multiple 'services' associated to it.

What this means is that our 0.2 release will already incorporate some experimental 0.3 features, in the same way that we were able to support multiple platforms in the 0.1 release through the hostslave install profile. These features will be clearly marked as experimental, but will be available to you if you really need to be ahead of the curve.

This new functionality also opens some interesting doors for us, in that we will be in a situation where we can start taking Aegir to the cloud, through integration with services such as Amazon EC2, which will be able to roll out a new server
for you simply by creating the server node on your hostmaster. A possible avenue we need to look at is integration with the existing Amazon EC2 module for Drupal, if it proves feasible.

The refactoring of the server object model will take place during the 0.3 release schedule, alongside the upgrade of the front end to Drupal 6 and many other user interface improvements such as complete integration with views 2.x, and possibly triggers.

Returning to our focus on building a solid back end in our 0.2 release, and limiting the amount of changes to the front end, I have been working on porting the major features of the Provision API to Drush 2.x.

This is being done to close the gap between pure drush commands, and provision commands. Provision until now has existed as kind of a 'super drush'. It worked around limitations in Drush to provide several core features we required, such as scriptability of commands and
very complete logging and error tracking.

We have already successfully migrated error handling and logging upstream into Drush 2.x improving, generalizing and documenting along the way. We have also completed the refactoring of our system to use these new general API's.

Our next big task, is migrating the RESTful API for drush commands that we are currently using in provision. Once this is done, any drush command will be re-usable by Aegir, or even Drush itself. This will allow us to easily solve issues such as automatic platform creation, whereby provision can simply re-use the existing drush command to download a specific version of Drupal.

This also gives us access to the 'pm' suite of Drush commands, that would allow us to do 'a la cart' module installation, from the Drupal repositories. We will also likely provide a mechanism to watch the Drupal project feeds from within the system, and be alerted when a new release or security fix of any of your installed modules are available, and allow you to easily automate upgrades to the latest version.

The major blocking issue for that functionality however is the implementation of package dependency checking, which will need to be completed before an 0.2 release can be made.

One of the interesting points regarding the backend drush improvements, is that Drush itself will gain the ability to communicate with Drush instances on remote servers, which has a lot of possible uses.

Once the backend api for Drush has been ported, we will be completing work on the implementation of the drush_invoke API into Drush 2.x. The end result of this will be that Provision will no longer be 'super drush', but all drush commands will have the power to extend other commands, which results in many interesting automation uses and greatly reduces the amount of code that needs to be written, optimizes the re-use of existing code and provides substantial mechanisms for ensuring the integrity of any code that gets run.

In closing, feel free to come chat to me at Drupalcon DC in march, where I will also be doing a presentation about Aegir, which will touch on some of these new features.