Oh man, in the past few weeks I was JUST starting to look into how Vagrant might speed up our dev environment processes! Really glad some others are all about it as well. Just found the project, but I'll poke around and see if I can help in any way :)

Also, not sure your approach, but my initial thinking was simply to turn Drupal Quickstart into base box. Any particular reason why this approach is less desirable? (Or hey, maybe this is how you're going, but it didn't seem so from the project description...

Also, we're still using D6 for some of our more complex sites, so perhaps I could help by keeping things D6-friendly

Comments

patcon’s picture

patcon commented

Also, I was planning to work with Puppet as the provisioner instead of Chef, so perhaps that could be my contribution. And let me apologize for the braindump nature of this issue -- I'm all over the place, and I'm not sure how seriously you're taking issue queue etiquette at this point :)

christianchristensen’s picture

christianchristensen commented
Status: Active » Needs work

Re: Base box = Quickstart; I think this approach is *ok*, but I think it misses a lot of opportunities we have with config management. One approach we could take here is using the quickstart build scripts (http://drupalcode.org/project/quickstart.git/tree) to make a "quickstart" config management. Basically representing the full binary in config management (notice a lot of work has already been done here; it is just getting those shell scripts into a config management form). Additionally, I think base boxing quickstart is probably also a poor decision b/c of box dl size; the quickstart torrent is currently around 1.5Gb - I believe there is alot to be gained from a clean and small base box built (one that is agnostic of config environment...as best possible) as it drives home trying to make sure all actions are committed to VCS in a config management form. (realizing here that package dl's will begin to account for a large portion of dl size as well).

Re: Puppet; I think we are currently entrenched in Chef; however, I am not sure this is permanent. If there are compelling arguments for a puppet build I would see no reason to switch (or try and support both, although I believe this is probably not actually feasible).

Goals: I think there are a couple of goals with this project: quick local, controllable, drupal development environment, canonical configs for both VirtualBox *and* other server config deployment (EC2, RackSpace, Linux box, etc...) - particularly for repeatability and control, a proper config representing an optimized stack setup for Drupal (much like Mercury from project Pantheon).

MIssion: Direct someone unfamiliar with Drupal (and all the moving pieces to a Drupal install - LAMP, etc...) to something as easy (nay - easier) than a MAMP or WAMP setup that closely represents an environment that will be in production; using the same *server* configuration on local dev as production.

patcon’s picture

patcon commented

Re: Quickstart base box
I actually agree with everything you've said. I think I was in quick-solution mode, so that was my first instinct when I wanted to get Quickstart working with Vagrant. But you're 100% right.

Re: Puppet
As far as I know, Chef recipes and Puppet manifests can happily coexist in a box, as you specific the provisioner in the Vagrantfile itself. We could offer one Vagrantfile and comment out the small number of Puppet lines, and the manifest folder would be completely ignored. The other option would be package it with something like Vagrantfile.puppet and Vagrantfile.chef_solo, and just instruct the use to remove the right suffix. I don't think there's actually conflict is supporting both, just the hassle of keeping them synced :)

Re: Canonical config for cloud
Might want to check out mig5's Madelon project if you haven't yet: http://github.com/mig5/madelon
He's using the libcloud library (which abstracts communication with cloud providers through a common API) in conjunction with puppet to allow spinning up an Aegir instance in a jiffy. Might be some overlap in interests there. Also, might be a reason to favour Puppet at some point.

On a related note, would be really cool to get some manifests/cookbooks assembled for aegir main and remote servers (with requirements to support Web and/or Database services as required):
http://community.aegirproject.org/node/30

I'll keep you posted on any progress I make with making Vagrant and Drupal play nice together

Cheers Christian!

glennpratt’s picture

glennpratt commented

As for D6, we are heavy D6 users as well. This project is version agnostic and we plan to keep it that way (though our releases may be marked as 7.x, like Drush).

glennpratt’s picture

glennpratt commented

Oh, and the Git repo is up an running, so you don't need to wait for a release to dive in!

crdant’s picture

crdant commented

I didn't think to look on d.o for a Vagrant related project since it didn't fit what I'd expect to find there, but I've been working on something similar in parallel. I've got a stripped down version of Puppet configurations that I've been using for it. I'll take a look at how they compare and see what I can do to contribute as well.

glennpratt’s picture

glennpratt commented

@crdant - Cool. Would love to see the Puppet configs if it's something you can share.

crdant’s picture

crdant commented

@glennpratt - I've got a project on Github: git://github.com/crdant/vagrant-drupal.git, I'm trying to get a clone of this project to do some analysis of how I can make them equivalent.