[META] Compare efforts with xforty/vagrant-chef

[pearcec]

Hi @patcon I am opening a ticket so we can dialog about our different efforts so far. @dkingofpa has done most of the heavy lifting on our project. But he bounced a lot of ideas off of me.

https://github.com/xforty/vagrant-drupal

One of the big struggles we have so var is VirtualBox performance is crappy even with NFS. It is making us rethink using it. We tried had to make our chef files portable so we can provision KVM guests for development. What has your experience been?

[patcon]

Hey pearce,

Can I ask what machines you're using (OS and specs)? We're trying to standardize organization-wide on quadcore macbook pro's with SSD

When we have trouble on those machines, it's due to something that would otherwise be an issue on production too. I'm sure some developers would say at times that the VM has ill-performed, but on my end, I know that when this has been the case, it's been due to misconfiguration on my part as I'm learning what's best. I'm new to the ops world -- we still use Acquia for hosting the important stuff.

[patcon]

xforty/xforty-drupal@a418dbd#L1R24

We were playing around with laying out a makefile like this for local testing, but then it builds a site that has an install profile as a repo whose remote can't be pushed too. To explain, we keep all our custom module code in the install profile, using a .gitignore with an entry for */contrib. That way, our stub fetches the git repo profile, the nested makefile is found and built into profiles/xforty-drupal/modules/contrib. And now devs can edit the code in profiles/xforty-drupal/modules/custom/custom_module, see the changes locally, then just commit and push when satisfactory.

Basically, our profile, custom modules/themes, and makefile all live in one repo. This makes continuous integration/delivery MUCH simpler when the time comes, since you just monitor one repo per project.

But now that we're looking at capistrano, this could solve the issue of having a local repo referenced in the makefile -- I guess there could be a cap task to swap the profile's git remote from being a local ref to a github ref, so committing these edits would be more intuitive for devs...

[patcon]

Re: https://github.com/xforty/vagrant-drupal/blob/develop/Cheffile

Ok, so this is probably a matter of personal preference, but what are your thoughts on simply merging/overriding the canonical cookbooks instead of pulling in custom ones, at least when the changes aren't too... "intrusive", I suppose?

As in, chef allows you to specific two cookbooks_path array values, and it will merge in the second. I usually prefer to have a second path called cookbooks-overrides that merges in changed or new recipes or other files. This kinda ties back into the it-should-be-as-simple-as-possible-to-merge-with-someone-else's-infra thing. The canonical cookbooks are referenced as much as possible in the Cheffile[.lock], and you anyone intested can scope out cookbooks-overrides to see what differences are merged in. It just seems more grokkable to me. Those familiar with Chef will "trust" a canonical cookbook, and the code that needs to be scrutinized will be handily in the cookbooks-overrides directory :)

So with my equivalent of your chef-php_mod cookbook, for example, my own angle would be to create cookbooks-overrides/php/recipes/mod_blah.rb, and that just gets pulled in -- metadata should also technically be overriden in order to bump versions, but at the moment, there's no truly safe version-number to bump for local customizations (see last bullet for potential future solution). Anyhow, so when I now want to pull in a newer php cookbook version, I just run librarian-chef update and remove any of my override mod_blah recipes that have been merged in the canonical already. Same goes for minor edits to templates and the likes.

What are your thoughts between the two? I only ask because I'm sure we're both considering whether our efforts are worth merging. Just want to see if we can hash out our differences in approaches :)

[pearcec]

We don't standardize. We have Mac users, and Linux users.

That is interesting. How do you instruct to do the chef-overrides?

We might have different philosophies. We essentially clone our vagrant-drupal repo when we start a new project. Seems to me you use the same one ongoing? We use site-cookbooks to check in project specific cookbooks.

[patcon]

Sorry, the system wasn't the main concern, so much as the minimum specs
you're aiming to accommodate :)

And before I jump into any explanation, by "chef-overrides" do you mean our
"cookbooks-overrides" directory, or chef's override_attributes?

And as for reuse, I think we're aiming to allow it to be used for multiple
projects so someone can rerun "vagrant provision" after changing project
name in the INI file (or ENV variable), but it could just as easily be
cloned into a directory with a different name for each project-- all
variable data for each project gets a designated directory in the data/ dir.

[pearcec]

----- "Patrick Connolly" [email protected] wrote:

From: "Patrick Connolly" [email protected]
To: "Christian Pearce" [email protected]
Sent: Wednesday, February 15, 2012 9:32:41 AM GMT -05:00 US/Canada Eastern
Subject: Re: [ariadne] [META] Compare efforts with xforty/vagrant-chef (#1)

Sorry, the system wasn't the main concern, so much as the minimum
specs
you're aiming to accommodate :)

Oh we pretty much use ubuntu LTS. We are forced to use Red Hat (Centos) everyonce it a while.

And before I jump into any explanation, by "chef-overrides" do you
mean our
"cookbooks-overrides" directory, or chef's override_attributes?

yes.

And as for reuse, I think we're aiming to allow it to be used for
multiple
projects so someone can rerun "vagrant provision" after changing
project
name in the INI file (or ENV variable), but it could just as easily
be
cloned into a directory with a different name for each project-- all
variable data for each project gets a designated directory in the
data/ dir.

That is counter to our aim. Though I suppose ours could be used to allow it to be used for multiple projects with a simple "vagrant provision".

---

Reply to this email directly or view it on GitHub:
#1 (comment)

xforty technologies
Christian Pearce
888-231-9331 x1119
http://xforty.com

[patcon]

Do you all have SSD? Hybrid SSD? At least 2GB Ram? 4GB? Dual core? Quad core? Apologies for being unclear, but these sorts of things were what I was wondering about. Just trying to understand your performance concern in context.

Re: cookbooks-overrides

This might illustrate a bit better:
https://github.com/myplanetdigital/pennyworth-drupal

Keep in mind that cookbooks-sources was a previous approach. From that dir, the git submodules would now be in the Cheffile, and any subdirs would be in cookbooks-overrides. Maybe cookbooks-merge would be a more intuitive name, as they don't always override -- sometimes it a new recipe or amended template.

That is counter to our aim. Though I suppose ours could be used to allow it to be used for multiple projects with a simple "vagrant provision".

I'm not sure I understand the "counter" part. If a vagrant setup can accommodate multiple sites on one VM just as easily as single sites on separate VM's, would this be something that kept us from working together? Couldn't I just accommodate that and you guys could ignore that it even exists? You'd just only ever have data/xforty/shared[1..n] in that directory, right? Sorry if I'm misunderstanding.

[patcon]

Also, food for thought: Trying to consider how vagrant's cleanup method could be used with drush archive-dump to drop off an archive tarball every time we destroy, so dev's won't need to be so reluctant to destroy every so often:
http://frank.be/articles/2011/12/16/vagrant-and-chef-auto-deregister-on-vm-destroy/

[patcon]

I need to revisit this...!