0.4 - automate platform creation

drush_backend is in and working, and all drush commands can call each other.

What's needed now is the bits added to hosting to create release nodes from the drupal.org update repo, and passing the
platform version parameter to the provision verify task.

This is all pretty simple, so we're almost there.

drush_backend is in and working, and all drush commands can call each other.

What's needed now is the bits added to hosting to create release nodes from the drupal.org update repo, and passing the
platform version parameter to the provision verify task.

This is all pretty simple, so we're almost there.

We have decided that we should leave this for the 0.3 release.

While we would like to do it now, we simply do not have the right meta-information available to us. It does not help the user if we simply download drupal core itself, but not the right versions of any of the packages that his site needs to function.

So for this to be actually useful, we need to do some work on Drupal package management in general. I've written down some notes about what I'm working on to solve this here : http://groups.drupal.org/node/21295 , but this will not be ready for a timely 0.2 release, so to stop the 0.2 cycle from taking forever, we need to re-focus our efforts.

Definitely, it shouldn't delete enabled sites when deleting platform, or should just refuse to delete platform with any enabled sites. Now it simply deletes sites together with its platform - without any warning - not a problem when you know what are you doing.

~Grace

As to "automate platform creation" - I believe it can be safely automated with well done Drupal distros like Open Atrium, Acquia or Prosepoint. But in the real world we want more customized distros and then it stops to be simple enough to be automated, IMO.

Two examples: try to use OpenPublish or MediaMosa as platforms - it will not work for different reasons, and can't be automated.

~Grace

Ok tested this out and it appears to work as I would expect:
* Delete failed when it had sites on it as expected.
* Deleted when there were not sites as expected.

One problem I noticed is it wont allow me to add another platform at the old path... so I think when deleting the platform path should be also deleted since it doesn't exist anymore, or alternatively if you attempt to create a new platform at an old path on a delete platform it could just re-enable that platform node (ie: run verify again)

Also as discussed in IRC I think a profile disabled operation (or as discussed a better term for this task might be "lock" to avoid confusion between what site disabled means).

By locking a site it would prevent any new sites being added to the platform (e.g. add/clone/migrate), the use case for this is when you have a new release of a platform, but there are issues with migrating all the sites of the old platform. For security reason you probably want to prevent new sites being added to the platform but you also want to have full access/visibility of the platform to continue performing normal operations on the sites that are running on it.

I tested the lock, unlock, delete task and they all worked.

I also attempted to add a platform with the same name as an old deleted one and it just re-verified the old node which is great.

Couple of minor issues:
* should the lock, unlock and delete tasks appear as tabs on the platform node?
* when you have no platforms enabled (ie: all locked), then when you attempt to add a new site it fail with an ugly php warning

warning: Missing argument 2 for _hosting_site_form_populate() in /var/aegir/drupal-6.14/profiles/hostmaster/modules/hosting/site/hosting_site.module on line 905.

I don't think that warning should hold this up though as its unlikely you will lock all your platforms.

Ok, so i want automatic platform creation to be tied to drush make.

which means adding a new text field to platform nodes, that can either be a link or a local file to a makefile for the platform.

on platform creation we should have an install or make task, which then goes and rolls it out, before being verified.

I am seeing what you see in #19, there are no tabs - I actually hadn't noticed that the tab were removed with the recent task changes on the sites, so thats all cool.

I think that message you added is sufficient, I think its fairly unlikely you will have all platforms locked anyway.

So what you have looks good to me.

I added the ability for platforms to fetch themselves using drush_make :

when you set up the platform , ie:

"drush provision-save @mynewplatform --makefile=/path/to/filename --root=path"

Then when you do
"drush @mynewplatform provision-verify"

If the root doesnt exist, it will create it for you by fetching the platform from the makefile.

Now we just need a way to feed the makefiles to the platforms nodes.

I tried to work on this a little bit. I added a 'makefile' column to {hosting_platform} and a textfield on the platform add screen.
I haven't tested this out at all, but I wanted to post this to get some feedback on the general idea.

I tested this a bit. The update function works and the node saving, etc. For some reason I made the 'makefile' form field required, which is bogus. I'll remove that for the next reroll.

The platform verify task fails though, because it does not get the 'makefile' argument passed. Specifically the following code doesn't work as expected:
In hosting_hosting_platform_context_options():

+  if ($task->ref->makefile) {
+    $task->context_options['makefile'] = $task->ref->makefile;
+  }

When I remove the if clause and put in the name of the makefile manually it works, so it seems $task->ref->makefile is not being set. This is my first time digging into Aegir so help would be greatly appreciated. Also if there is any help on debugging these kinds of things. I looked in vain for the output of the various print_r()'s I put in that function :)

will check it out

i have committed your patch with some fixes..

it can now accept a url to a makefile, and pulls it down for you.

Wow, that's pretty awesome!!!

Currently an existing directory 'wins' over a makefile (ie if there is a directory, the makefile is not used). I wanted to ask, if there are plans to make that behaviour configurable in some way, that you could make the makefile 'win'. Ie on verify, if the directory exists, Aegir would check whether the existing build matches the makefile and otherwise rebuilds that. I couldn't really quite get my head around how/if that should/could work.

there's really no way to do that. not with drush make or anything else.

the parameters of 'wins' are so very wide and poorly defined.

THe current way is the only way that's non-destructive, and wont result in data loss.

All right.

One last question: I spent some time recently building a UI for creating makefiles. Ideally I'd like to point and click a platform together. I didn't really get that far, but I thought if there are larger plans to include something like this in hostmaster, because then my time would perhaps be better spent learning what the goal is and working towards that, instead of cooking something up myself.

i dont think aegir is the right place for that functionality.

what needs to happen is an external tool (similar to the feature servers) that allow you to build distributions, and then you syndicate those generated packages / makefiles into aegir.

so you'd have an rss feed of platforms.