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

patcon’s picture

I'm all over this. Let me know when you've got a sandbox up and running Glenn :)

patcon’s picture

Can 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

mike stewart’s picture

Status: Active » Postponed (maintainer needs more info)

Totally 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.

patcon’s picture

I 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).

  • I believe I've heard that puppet has something like Chef's concept of attributes and the node object available in the new addition of Hiera. I've also heard that you can now have ruby in your manifests, although not sure. I can only imagine how these might be implemented, but I feel they have been inserted in response to the competition from Chef, and so I'm doubtful that the architecture is as coherent as Chef's, where it was built from the ground up to provide such things. Basically, I feel Puppet is playing catch-up in the technology.

Anyhow, Cheers!

mike stewart’s picture

Thanks 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.

patcon’s picture

I 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! :)

dkingofpa’s picture

When 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.

MichaelCole’s picture

Thanks 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

MichaelCole’s picture

Status: Postponed (maintainer needs more info) » Active
patcon’s picture

Sounds 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.

patcon’s picture

Oops. just realized that our projects had never been posted in this thread:
#1200844-5: Do something cool with Vagrant