I've been thinking up some ideas for potential further improvements to Aegir, and am putting them up here (in no particular logical order) for debate. These are just ideas to make things simpler for end users, and I have no particular attachment to them, so don't mind if they get shot down in flames :) If any of them prove popular in discussion I can open the appropriate feature request in the issue queue....
1. Create a role 'aegir admin' and user 2 to be the day to day admin
I think we could clean this up further by getting the user to create a 'user 2' login during the install profile that they then use for everyday use. It will be assigned to the role 'aegir admin' (and other users could also be created and added to that role later) so it can do all tasks across all clients and sites, enable or disable features etc. However it'll be different to user 1 in that we can hide the modules and theme pages, lots of other admin stuff thats not needed etc.
But also on node create and edit forms, they won't see the 'menu options', 'authoring', 'publishing' etc etc which'll make things cleaner.
2. More help inline for novice users that advanced users can dismiss
Ideally this will be displayed in the interface by default near the feature it describes. It'll explain terminology, how to get started etc, and link to more detailed online help. Advanced users will be able to either dismiss individual messages - or disable the entire 'Aegir Help' feature.
I've been looking at advanced_help module for this, and did a proof of concept - but that just provides a tiny help icon thats hard to spot and you can then click to pop up a help window. I'd prefer it if the help was displayed inline and then dismissed. Maybe a feature is a better way to go, using JQuery to do the displaying or hiding. Perhaps there could be options - 1/display help inline 2/display help on clicking an icon 3/switch help off.
3. Fewer downloads
I think it adds to users confusion, and developers workload, to have many different components of Aegir - but none of them called Aegir. D7 will make this easier with install profiles as modules I guess - perhaps there could be one 'Aegir' module then? Is anything simpler possible before then? Or is it possible to offer it as a distribution somewhere (perhaps on aegir-project.org ;) ?) I guess drush/provision always have to be installed separately though.
4. New Feature: Put a site in offline mode from Aegir
In some circumstances an admin may wish to put a site, or all sites in a platform, in offline mode before migrating etc. Could there be a task to do this on the site's node page, and on a platform's node page?
5. New Feature: Periodic Package review on cron
Users may update the packages on their platforms but then not think to re-verify. Could aegir scan, say once a day, each platform to get up to date info on the packages? probably without doing a full re-verify in case that leads to apache problems etc.
6. New Feature: Package update suggestions
Aegir knows what packages are on a platform, and it can communicate with d.o to get details on latest releases - could it then suggest updates to the admin for each platform? Each one would have an update button that would then run the drush update on that package. Kind of like status update does, but for whole platforms? But I guess running update.php for each site on the platform could be an issue.
7. New Feature: Site Status
Could aegir provide a basic automated check that each site is at least displaying something when accessed via http? Then a traffic light on each site could reassure admins at a glance that things are okay. One day the dream scenario would be simpletest via Aegir for each site :)
8. New Feature: Email alerts to admin
If (7) finds a site is down, or (6) finds a security update or certain other events, Aegir could alert the admin via email (or the messaging framework if we want to get fancy!).
9. New Feature: package install via aegir
Could a task be added to platforms that allows the user to enter a package name, which then gets downloaded to the platform via drush?
10. Platform Builder
This could be a wizard in which the user selects a version of drupal, then enters package names, then aegir builds it as a platform in /var/aegir/platforms grabbing the codebase and packages via drush and sets it up as a platform within aegir.
11. Migration Improvements
There's already been a lot of discussion on IRC about this, but here are some ideas... It could become more of a wizard - step 1: here's a list of platforms that are already compatible, here's a list of platforms that are not yet compatible and what packages you need to add or upgrade to make them compatible (no need to show them all the packages that are compatible, although maybe this could be shown in a collapsible fieldset or popup if they choose). step 2: if a not-yet-compatible platform is selected, do you want aegir to go and get the necessary packages/updates? if so these are the other existing sites on the platform that may be affected, is that okay? if so, it sends drush off to do this. step 3: if update.php needs to be run on these sites, please do this manually now and proceed when done. step 4: do you want to put the site to be migrated into offline mode?. Step 4: doing the migration. Step 5: here are the results
12. Obsolete a Platform option
An admin may wish to make a platform obsolete so that no sites can be migrated to it or created on it, but hasn't yet migrated sites away from it so it can be disabled or deleted. There could be a tickbox option on the node edit page for the platform that makes it unavailable for site migrations. For example, I've imported old codebases to get sites into aegir - and I want to gradually transfer these sites to newer platforms... but in the meantime I don't want those platforms to be available to create sites on or migrate sites to.
13. Platform Description
The admin should have the option to enter descriptive text about a platform - eg 'A platform for running ecommerce sites' or 'A simple blogging platform' etc. This can then be displayed on the site create forms, signup form etc
14. Whois and DNS info on each domain page
Aegir could pull in simple whois and DNS info onto the domain page so that the admin can see at a glance key data about the domain.
15. Get g.d.o to run on OpenAtrium :)
'nuff said.
Comments
Enable/Disable modules per site via Aegir
in IRC skwashd suggested also being able to enable or disable modules for each site via Aegir.
=======
Steve Parks
WunderRoot
http://www.wunderroot.com
A few notes on some
A few notes on some features:
9. New Feature: package install via aegir This one and feature 10 should provide a list of available modules that I dont know where can be retrieved from with no pain. Perhaps it must wait for the ports collection: http://groups.drupal.org/node/21295
10. Platform Builder Could be based on http://drupal.org/project/drush_make.
What drush_make does is download a drupal and a serie of modules/themes based on a Makefile. Aegir could provide a frontend for generationg a Makefile based on the user selection.
12. Obsolete a Platform option and 13. Platform Description seems a simple one to implement.
Couple Things to add to the bunch. ^_^
Just some thoughts I've had over the last few weeks .. im sure most of which have already been decided for good reasons but I just wanted to throw my 2 cents in and see.
Core & Platform Separation?
A new content type Core which would only contain an instance of Drupal Core, platforms would be dependent on a given core but not include the code. IMO (and I could be way wrong!) this would make Minor Drupal Core update far more simple, one would only need to update the core and then Any platforms that depend on it would then have the updated code available, We could then trigger the backup > updatedb > verify on each of the sites. I think this would make migrations be required far less often. This could also make it easier to manage hacked cores (for those that do that). This would free up the platforms to be more specific without a lot of code repetition.
Rules Triggers Actions
I think it might be useful to use these modules or some similar Aegir centric code. With this we can chain events, so for instance in the core update scenario above you can update core then trigger all its dependent platforms and consequently all of their included sites to go offline > backup > updatedb > verify > back online > send success email to client. The task cron cue should be able to handle getting all the tasks thrown at it and do them in order, and handle any errors/task failures etc.
Views Bulk Operations
Im waiting til I have some free time to test but couldn't we make a dashboard out of this to facilitate all the various tasks in Aegir? Back to the scenario above .. one could create/update a core and then migrate platforms to it which would then trigger all the backups > updatedb > verifys etc. Of course then we can do other things here like... set all sites to offline, send messages to all sites owners and other such useful goodies. Im still unsure how much can be done with views bulk operations as I have not tested it yet, but it or something similar might be highly useful in future Aegir release.
A way to preserve custom bits on settings.php
Maybe I'm doing something wrong but I noticed when migrating a site I loose the little bits I add to my settings.php ...really its only one thing .. I add a tag to set a maintenance theme for when a site is offline.. which seems to be lost in migration and has to be manually added to each site again.
In Reply to Macrocosm
On your settings.php issue, these will get overwritten everytime Aegir verifies the site. There is discussion in the issue queue about the best way to enable customisations in settings.php - its worth taking a look at that and adding your thoughts.
I like your other ideas - thanks for contributing!
Steve
=======
Steve Parks
WunderRoot
http://www.wunderroot.com
Other ideas
The 'Create Platform', 'Create Site' etc options could be their own menu options rather than being hidden under create content - creating a faster more usable menu.
Or perhaps there should be a separate 'Aegir' Menu, with available tasks on it?
=======
Steve Parks
WunderRoot
http://www.wunderroot.com
Thanks Steve .. your patch
Thanks Steve .. your patch worked perfectly for the site.inc bit ...Sweet!
... your suggestions above are quite insightful! I especially like #15 .. after seeing the new community site for Atrium I screamed that out myself in IRC! lol
Im sorry I just blabbed into your post without speaking to your thoughts above, I was just getting ready to write a similar post when I saw yours .. I have to catch some zZzZz's now im spent! ...but I think a lot of your suggestions are smart .. and I look forward to seeing if some of them make their way into the issues cue for patch testing.
For the create content links idea in your last post .. perhaps you can use dhtml or jquery menu or someasmuch .. still, even cooler would be to borrow the code from Open Atrium .. I love those new Create Content drop-downs ... quite nice!
Cheers!
^_^
some comments
I would rather have a "login as admin" button that would just be a one-time link magic. I think mig5 worked on that a bit recently.
Git could help with that. Otherwise, we could build a .tar.gz that would include all the goods, but I'm not sure that's a good idea. I would rather target packaging platforms (like Debian packages) instead.
This is already done on migrate, AFAIK. Plus that's basically what "disable" does.
We are planning on implementing task scheduling for the 0.4 release.
That would be awesome. I think we should also implement platform comparison. Adrian is working on that right now though.
That's basically the status of the last "verify" task...
Yes, it's something I think should be implemented in the long run. It should also be fairly easy but could create havoc in platforms, especially if the package already exists...
That would be awesome. I will shortly work on a platform duplication script.
I think a "status" option on all node types will quickly become mandatory.
Yep, that would be good. Right now, we're disabling the body on those node types, it's fairly trivial to re-enable it. We currently use comments on those nodes to post maintenance announcements and so on. We also change the title to reflect the status of the node.
That will be part of the DNS stuff.
Eh...
BTW, steve, you should all put this as feature requests in the trackers. No use in hiding here, i'll always find you! ;)
Hey anarcat
Hey anarcat
That's a lot of number 1 points :)
I didn't put these as feature requests because they're not fully formed ideas, just initial ideas to spark discussion - and I didn't want to pollute the issue queue.
If any of them gain wider interest I'll turn them into tickets.
And actually I did this post because at drupalcon you'd put up a 'goals for 0.4' post as a discussion on here, and encouraged me to go add some ideas - but by the time I'd done so we were already at 0.4 :)~
Anyway, essentially you're saying most of this is already on the RADAR, so that's good, and not worth opening new tickets about.
Once the discussion settles I'll pick what seems to be popular and open feature requests - but none of this is high priority stuff really.
cheers
steve
=======
Steve Parks
WunderRoot
http://www.wunderroot.com
Scheduled backups
Ability to schedule backups would be great. Probably isn't too hard to implement considering the backup feature exists already.
Already suggested here: http://groups.drupal.org/node/26024
anarcat, can the task scheduling be used for backups too, or is it meant only for the periodic package reviews?
7. New Feature: Site Status
+1 for that.
Would be useful to see similar to "drush status" on the site's node.
2) Platform creation.
3) Option for platform and site creation in one procedure.