aegir

Events happening in the community are now at Drupal community events on www.drupal.org.
adrian's picture

Aegir 0.2 screencast

Click on the image below to watch the screencast of the 0.2 release of Aegir.
Only local images are allowed.

Read more
adrian's picture

Aegir 0.2 ALPHA 1 released.

We're proud to announce the first alpha of the 0.2 release of the Aegir hosting system for Drupal.

Ægir is a set of contributed modules for Drupal that aims to solve the problem of managing a large number of Drupal sites. It does this by providing you with a simple Drupal based hosting front end for your entire network of sites. To deploy a new site you simply have to create a new Site node. To backup or upgrade sites, you simply manage your site nodes as you would any other node.

This release is the first alpha release of our 0.2 development cycle, which has been focused on complete support for running multiple concurrent Drupal releases, and managing upgrades of sites between Drupal releases. This release has also primarily been focussed on improving and simplifying the back end system, by incorporating a lot of our custom API's upstream into the Drush 2.x project.

Update: Check out this screencast for a quick walkthrough of the features available in this release.

Read more
adrian's picture

Drupal 'ports' collection

What is it?

My recent work on Aegir has been very deeply oriented with Drupal package management and dependency checking.

From the perspective I have been working from (unix command line scripts), the currently existing functionality of the update module is simply not useful.
I am in need of an easily mirrorable meta-info repository of all the drupal projects, and all the drupal modules. I need to be able to figure out dependencies

Read more
adrian's picture

Progress update: Package management and dependency checking


Progress towards our main development goals.

Drush stuff

Last week I completed what is basically a major rewrite of Drush, save the actual command files. Everything is a lot more sensible and normalized now. This also led to me massively refactoring Provision (our drush based back end) to make use of these new API's. I wrote up a small post about what's been happening with Drush for those that want more in depth information.

The major thing that is coming out of Drush becoming more like Provision every day, is that the drush_extras project is being re-integrated into Drush itself, using the provision conditional include API for the Drupal version specific code. Once that is done, we will be migrating Drupal install and update commands upstream to provision, which provide a much larger user base for the code, getting it far more testing. It will also significantly reduce the size of provision, and make it easier to maintain and will hopefully become the standard way that 'real' Drupal developers run update.php on their sites.

Because we are so deeply involved in Drush now, we are also tied to their release cycle. We are at a point where we want to release an alpha, but moshe has decided to re-integrate Drush_extras first, which should take about as long as it would to have gotten each version of drush_extras ready for an alpha too.



Enabled packages on a site

Aegir stuff

I haven't been resting on my laurels though, I've been tackling many of our critical issues (take a look at how good our issue queue is looking). I have been continuing in my crusade to make the Aegir project easier to build and maintain.

In the last week I finally nailed down the biggest issue that was holding us off on an alpha, namely the package management features. With drush 1.x we could rely on each platform being a site, to have access to the database, unfortunately with 0.2 that isn't possible anymore, so I wrote some routines that index entire Drupal platforms and find all the modules, themes etc for the whole platform, all the profiles and each of the sites, which I then import on the front end to build relationships between the package entities and the sites etc.

This now allows us to do some dependency checking, which we sorely needed. Previously it would let you attempt to migrate any site to any platform, no matter of the version.

This is much nicer. Imagine how great it will be once we have spaces, context and features properly playing along with all this stuff. You'll be able to roll out new features incredibly easily, and seeing that you can extract features with Drush, we can automate that too.



Package compatibility between platforms

As you can see, we're already very close to an alpha, so we're going to be working towards that along with the Drush guys. After the alpha there's going to be another phase of refactoring going on, as we'll have solved all our major issues for the release, and now it's time to make sure the codebase is up to scratch. We're also going to take some time and get some of the contrib modules playing nicely with 0.2, so that will take some time too.

I have also spent a few hours today on the community side of things, mostly fixing up the groups.drupal.org page. It looks way better now, and displays the release status proudly (keeps us honest, heh).

We'll be continuing forward in the next week or two on both the Aegir and Drush projects, and we'll probably have more announcements soon.


Read more
adrian's picture

UPDATE: 0.2 Alpha release soon, even closer relationship to Drush.

We finally have HEAD to a stable enough state that we can work towards releasing an alpha release in the next week or so. This is pretty exciting news because it means that we're nearing the end of the 0.2 Development cycle.

Read more
adrian's picture

What does my new position at Development Seed mean for Aegir?

By now, many of you are probably aware of the fact that I have joined the Development Seed team.

Before I go into the specifics, I would just like to thank Raincity Studios, for giving me the opportunity to start this project. Without their support, Aegir might never have gotten off the ground, and the experience I gained from developing and maintaining Hostmaster (Aegir's predecessor) has been invaluable in guiding the Aegir project to where it is today. I wish them all the best of luck, and I look forward to seeing them prosper from the foresight that guided them to support the project thus far.

Read more
adrian's picture

Back from Drupalcon.

This is just a note to say that I've just returned from Drupalcon DC.

It was a pretty amazing conference, and one of my favorites so far (I still have a soft spot for Barcelona).
Like Szeged, the video team at DCDC were very on the ball, and had the videos up the same day as the presentation.
You can catch the Aegir presentation on archive.org.

Read more
Macronomicus's picture

Aegir Server Setup and Dependencies. What would be the optimal rig?

I was talking with who will potentially be my host provider toady about aegir. I am wondering what would be the best setup to run aegir? The server will be a dedicated ubuntu 8.10 build of which I will have complete control.

I noticed in the install instructions that a debian build is required, which ubuntu is based off of so thats good right? I also can use debian if necessary. Is aegir utilizing some built in virtualization mechanisms from debian? I am just curious how aegir is creating the vertual hosts for all the subsequent sites.

Read more
adrian's picture

Drupalcon DC - Deploying and Maintaining Drupal Sites Using the Aegir Hosting System

I will be attending Drupalcon in Washington DC in March 2009, and will be doing a presentation on Aegir, on 5 march at 4:15 PM.

The presentation will cover some of the Aegir design basics, and also go into some of the cool new developments we have in store for our 0.2 release.

If you are at all interested in seeing what Aegir is capable of, or want to gain an insight into where we are going, please attend.

Read the complete presentation summary.

Read more
adrian's picture

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.

Read more
Subscribe with RSS Syndicate content