Hi there,

For the past few months, I've been building Vagrant-based system for spinning up networks of VMs: Aegir-up. It started out as an Aegir-specific development tool, but I've since built out somewhat of a templating framework that simplifies definition of such networks. It's currently Puppet-based, but I get occasional requests for Chef support, and it should be pretty easy to adapt.

I'm just in the process of converting the shell scripts in the project to drush commands, and I'm thinking of re-branding it, since it's no-longer Aegir-specific. So, I'd like to test the waters about merging with this project (into a 2.x branch, perhaps), as its current functionality could easily be supported as a template.

Let me know what you think.

Comments

ergonlogic’s picture

Title: Discuss merging Vagrant-based Drupal/Drush projects » Discuss merging with Aegir-up project

If this were well-received, I think folding in http://drupal.org/project/drush-vagrant too, might be a good step. Mostly to avoid namespace conflicts, but also since the functionality will fit well within the project. It would also mean only one Vagrant-based Drupal/Drush project, rather than 3 (and possibly more). Pooling our resources seems wise.

ergonlogic’s picture

Title: Discuss merging with Aegir-up project » Discuss merging Vagrant-based Drupal/Drush projects

FYI, also posted #1504670: Discuss merging Vagrant-based Drupal/Drush projects in the Drush Vagrant queue pointing towards this issue.

... and #1504676: Discuss merging Vagrant-based Drupal/Drush projects in the Aegir-up queue.

patcon’s picture

Really really like this idea. Think it makes a ton of sense to merge with QuickStart too.

Dries mentioned the ideas of building Drupal development SDK's in the keynote. Would something like this not being up that alley? A cross-platform development platform for building drupal sites that everyone can share, with all the required tools for the various workflows and ways of developing/building?

Not sure what would be in scope, but thought I'd post this as well:
http://drupal.org/project/awssdk

glennpratt’s picture

Title: Discuss merging with Aegir-up project » Discuss merging Vagrant-based Drupal/Drush projects

I might try to reframe the question around what we can collaborate on and make some dependencies (Chef repos, Puppet repos, Vagrant-Drush helper, etc).

Not that I'm opposed to the idea, but we probably won't be able to make everyone happy with all these use cases.

We've talked about QuickStart before, but I haven't gotten as much time to work on those roles as I hoped.

ergonlogic’s picture

Aegir-up is essentially a Drush extension that implements a system for generating Vagrant projects ("workspaces") from templates ("blueprints"). The Vagrantfile has been abstracted quite a bit and looks for settings in human-readable, .ini-like config files.

A blueprint (template) currently includes such a settings file, one or more Drush Make files, along with the scripts required to provision the VMs. In current blueprints, these scripts are Puppet manifests and modules, but could just as easily be Chef cookbooks, shell scripts, or other Vagrant supported provisioning methods.

Initializing a workspace involves copying a blueprint, and generating a second config file that includes things such as a usable subnet, and the user's uid & gid (used to mount Drupal directories locally on the host), writing an entry in /etc/hosts and initializing a Git repo within the directory. A workspace can also be initialized from such a Git repo (instead of using a blueprint), making collaboration exceedingly easy. If one were to post such a Git repo as a d.o project, it then becomes available to download directly from Drush (drush dl ), making the creation and sharing of blueprints themselves very easy.

At this point, plenty of Aegir-specific assumptions remain built-in, but I'm working to further abstract it. A framework is emerging that would allow both our use-cases and many more.

Also, according to this comment, the maintainer of the 'drush-vagrant' project (Steven Merrill of Phase2) appears to be on board.

patcon’s picture

I just wanted to chime in that Aegir holds a very special place in my heart, it being the first tool that blew my mind in the sense of "holy showza! this stuff can all be automated?". Having said that, I'm not currently interested in deploying and managing sites with Aegir (although that might change).

Can we make a point to separate the aspects of this tool related to server provisioning (eg. provisioning database, varnish, webservers, or setting it all up on one...) from the parts that deploy and/or configure the application and do things like rollback?

My personal preference is to have one tool handle provisioning (server-related configs), and another handle deployment (app-related). Some prefer using configuration management software (puppet/chef) to deploy, but I'd rather use another tool for that bit -- one specifically designed for deploying (cap or to a lesser extent, phing). For the app config that needs to be infra-aware, the provisioning software just drops the bare minimum relevant config files somewhere on the system, and the app knows to look for them there (thinking settings.php here).

So I'm a little cautious (although still really excited) about combining efforts, as not only can config-management tools be used differently, but I get the impression Aegir's aim has always been to walk that server-app-config line. Seems like we might have different ideas on how things should work, so we'd need to be extra careful to remain approach-agnostic :)

Anyhow, just wanted to get that out there! Again, really excited to be talking and sharing a project in which our approaches can interact! The more we talk about this stuff, the better!

glennpratt’s picture

Speaking for the Chef side, application deployment would definitely be separate cookbooks, roles and data_bags, so they ought to be able to be separated easily.

Steven Jones’s picture

@patcon I'm fairly certain that ergonlogic's Vagrant work is fairly orthogonal to Aegir, sure one of his templates installs Aegir, but there's no requirement to do so.

As far as I can tell, being able to have some kind of templated system means that we can cater for everyone, as people who want to use puppet can use puppet, and those that want to use chef can use chef etc.

ergonlogic’s picture

Exactly right, Steven.

I just posted this write-up to help explain what Aegir-up does, and where I'd like to go with it: http://ergonlogic.com/blog/aegir-vagrant-project-templating-framework

It only really covers the Vagrantfile stuff, and leaves out the rest of what's involved in the template framework, and pretty much everything that happens in the Drush commands. I may write some further posts explaining those bits, if it's warranted.

ergonlogic’s picture

BTW, I'll be migrating the Drush commands and Vagrant template framework stuff from Aegir-up into http://drupal.org/project/drush-vagrant, as per: http://drupal.org/node/1504670#comment-5862022

rooby’s picture

Issue summary: View changes