Active
Project:
Quickstart: Prebuilt Drupal Development Environment
Component:
Image Build
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
8 Jul 2011 at 16:27 UTC
Updated:
11 Jul 2012 at 17:19 UTC
Hi Michael, It was nice talking with you at Dallas Drupal Days.
I'd love to start looking at defining Quickstart in Chef. This would help answer moving Quickstart development sites to production, and maybe remove the need to distribute pre-build images.
Looking through the code you have, I think we could get things running pretty quick and migrate your shell scripts to cookbooks in a lazy manner.
Perhaps we could make a branch here or I could start in a sandbox.
Comments
Comment #1
patcon commentedI'm all over this. Let me know when you've got a sandbox up and running Glenn :)
Comment #2
patcon commentedCan we keep an active mirror on github, or just host there? I find it simpler to track projects and contribute over there... (at least until d.o sees an equivalent to pull requests)
And since Quickstart isn't technically a module/theme/profile, I don't have lover's guilt over cheating on d.o
Comment #3
mike stewart commentedTotally open to this idea, although leaning more toward puppet. pathes welcome or either a bitbucket or github. let me know your preference and we'll get started.
Comment #4
patcon commentedI presented my case for Chef in a BOF on local dev environments at Drupalcon Denver, but I'll give it another shot (no hard feelings if you feel differently):
Some people list the Puppet DSL as a reason to go with Chef, with the argument seemingly going something like "developers won't need to learn a new language (Ruby)". I totally disagree with this. For one, they WILL have to learn a new language: the Puppet DSL. The difference is that this "language" is a dead-end that will never go further than Puppet. Chef's DSL is written in ruby itself (a language which is known for being great in constructing DSL's), so as you poke around recipes, you're getting more comfortable with a real language, and a whole new world of tools open up to you.
For whatever reason, the Ruby world is rife with "devopsy" tools that the Drupal community would do good to learn, so I see it as a foot in the door to start experimenting. We should be encouraging Drupal community members to cheat on PHP and diversify, as then we can become better by pulling in the good ideas. For instance, my work with rubygems/ruby/bundler has helped me see the benefits of package management, and so I'm rooting for Composer integration in Drupal/Drush in a way that would never have occurred to me without Chef/Ruby experience. In fact, pretty much everyone who dabbles with Chef has been pushing for Composer. That says something. On the other hand, the Puppets folks could quite literally have used Puppet for years, and barely written a lick of Ruby (which it runs on).
Anyhow, Cheers!
Comment #5
mike stewart commentedThanks for the feedback. I looked into the puppet vs chef thing and felt install/user base was a bigger determining factor. In either case, I haven't started at all. and am open to any patches you'd be willing to submit for inclusion. Since I really haven't played with either puppet, or chef, etc., I'm still not even certain the best path forward.
Comment #6
patcon commentedI feel this post helps illustrate that it's pretty much a toss-up, and given that Chef is newer on the scene, I would argue that it has more momentum:
http://redmonk.com/sogrady/2012/03/13/chef-and-puppet/
To clarify the update date on debian installs: Chef is installed almost exclusively via rubygems, and so the apt-get metrics are pretty useless, except to see how puppet installs may have been affected by Chef milestones
Cheers! :)
Comment #7
dkingofpa commentedWhen I started a devops project and had zero baggage, I decided to go with chef over puppet. I had to learn a new language either way (ruby vs. puppet). I figured I might as well learn a language that has usefulness beyond just devops (exactly one of the points @patcon made above). Very happy with that decision. ymmv
If you want to see an active implementation of chef for building a dev environment, you can take a look at https://github.com/xforty/vagrant-drupal
We are actively using it for our client projects with great success. It leverages vagrant, chef, drush, and drush make. Feedback is always welcome.
Comment #8
MichaelCole commentedThanks for the feedback patcon and glennpratt. It's been almost a year, and I'm looking forward to a new release.
Would you be interested in picking this up again?
Mike
Comment #9
MichaelCole commentedComment #10
patcon commentedSounds great Michael! dkingofpa and I were talking really briefly yesterday about compiling a list of all the ways that our setups differ, so that we could hash out the differences and maybe consider merging on the common ground.
Perhaps we could start a comparison wiki that includes quickstart as well? Or perhaps we could dive right in. The rationale behind the pre-chat was just that we recognized that we both had preferred ways of operating that we might be stubborn in unless we discuss :)
What do you think of starting a new branch? Or... would you be averse to working through GitHub and mirroring to d.o? I understand some folks obviously detest that approach, but I'm partial to the workflow over there, so I thought I'd suggest.
Comment #11
patcon commentedOops. just realized that our projects had never been posted in this thread:
#1200844-5: Do something cool with Vagrant