Do something cool with Vagrant

The "drush vagrant" command prompts you for information about Drupal sites running in a Vagrant VM and then parses the output of vagrant ssh_config and renders a Drush remote alias for you to stick into your aliases.drushrc.php file.

http://drupal.org/project/drush-vagrant

Niiiice! Thanks @niccolo!

Just a heads up: https://github.com/myplanetdigital/ariadne
We're scratching an internal itch at the moment, but I'd love to see where we can work together :)

Marked a duplicate: #1256980: Vagrant and DevStructure Blueprints

+1 for Vagrant

To give the full context, we're working at Myplanet Digital to create a Vagrant box, Ariadne, for which the instructions (ie. chef cookbooks) can be used to build either a VM or an actual server in the cloud. So far it's just the VM, but the idea is to use something like "knife-solo" to allow it to be deployed onto a fresh cloud server.
https://github.com/myplanetdigital/ariadne

This is being developed hand-in-hand with a jenkins environment that works on a similar basis -- just as easy to boot locally with vagrant (for evaluating), but can use the same instructions to spin up an actual instance.
https://github.com/myplanetdigital/inception

The CI environment and the development environment are being built based on a set of assumptions which will take the form of a base install profile:
https://github.com/myplanetdigital/2ndleveldeep

To be honest, the projects aren't logically connected yet. For example, the Ariadne development environmnet doesn't yet boot with a demo using the 2ndleveldeep base install profile, and the Inception CI setup doesn't build an example based on it yet either. But that's the direction.

Anyhow, can't guarantee it will always be working while in development, but anyone should feel free to check it out :)

Cheers all!

I note that Aegir Up is also an interesting Vagrant implementation
http://drupal.org/project/aegir-up

personally, I'd like a tool-chain from Drupal Quickstart [DEV] > VBOA [STAGING] (+ Jenkins)> BOA [PRODUCTION]
http://drupal.org/node/1649472

For the last 7 months, we've been working on a vagrant drupal dev environment that people on this thread might find of interest. We are actively using it for our client projects with great success. It leverages vagrant, chef, drush, and drush make. Feedback is always welcome. https://github.com/xforty/vagrant-drupal

Yes! Vagrant is already in the next version.

dkingofpa, I'll check out Vagrant-Drupal.

Have you seen http://drupal.org/project/aegir-up? What's your thoughts on that?

Mike

Aegir Up is REALLY cool, but I hope we can work on a base development environment that doesn't make the assumption that we'll want to use Aegir. While I have the utmost respect for the folks who develop it (you might say "mad respect"), I personally prefer to make use of tools that originate in the larger community. Making Aegir a centerpiece of Quickstart would unfortunately put us on the outside of this effort.

The great thing about systems integration tools is that you can usually layer on components (using "roles" in chef or the equivalent in Puppet) and use Vagrant/Ruby to choose which parts you'd like to spin up (ie. components=varnish,nginx,aegir vagrant up).

Relevant: http://jtimberman.housepub.org/blog/2011/07/17/specify-chef-run-list-at-...

With regards to aegir, we've actually moved away from it for our workflow. We were leveraging aegir for about a year with all our development and some production hosting. There were a number of issues that caused us to leave almost a year ago. In no particular order...

1. This major security issue: http://drupal.org/node/762138
2. Constant permission issues. Such as safely giving access to external contractors.
3. Aegir uses multisite. Multisite has it's uses, but I don't think it makes sense to apply it to a site that doesn't require it.
4. Difficult to move a site from internal dev to an external host (and vice versa).
5. If something went wrong with a migration, you may not be able to roll back. If the site gets totally hosed during an update, aegir (drush) can't deal with that situation. You have to manually fix that.
6. Constant task queue issues. We even installed the host_queue_runner helper, but it was still a source of frustration during development
7. When automatic backups ran, it would bring the server to it's knees.
8. Onboarding new developers was difficult.
9. Migrating a site from dev aegir server to prod aegir server (and vice-versa) was a huge pita.

I'm sure some of these things have improved since we last used aegir, but I enjoy working in our current workflow rather than within the aegir workflow.

there have been big improvements, but I agree there are issues

much of it is, aegir-way workflow techniques are undocumented and not embedded in tools

imho aegir is only getting stronger, more stable and will eventually exceed early, too-high expectations

there are, however, many, many, excellent developers, who where early believers in the vision, and left, because it was all a bit to aegir-hard

bringing them back is important