- From: Joshua Timberman <
- Subject: [chef-dev] Re: MySQL and PostgreSQL cookbooks, RubyGems and You!
- Date: Mon, 6 Aug 2012 17:35:34 -0600
Ohai again, Chefs!
While we haven't seen a *lot* of response on this topic, or on the related
tickets, the general answers to my questions in the original email are
> 1. Do you expect that the "client" recipe for mysql/postgresql will
> install Ruby libraries?
Answer: No. A separate recipe is better, and can be included if desired.
> 2. If so, do you expect that because you want to use them within the
> same Chef run? Or because you want to use them with your
Answer: As the above was no, the general use is for Chef, and not for an
application deployment. Applications that require Ruby bindings often will
use bundler during deployment to get the right gems for the app. This is
consistent with Ruby community best practices.
As we've not seen obvious objections to the proposal, I think we'll proceed
with the changes outlined below. I do have some notes/updates inline, but
> 1. Move the list of package names for client installation and server
> installation to attributes in both cookbooks. They will be:
> Respectively, and platform specific package names would be selected
> using a case statement. This is proposed in part for the ticket
> COOK-1236. This replaces the current use of a local variable.
I added COOK-1532 for tracking this for the postgresql cookbook.
> 2. Remove the RubyGem installation from both cookbooks' client recipes.
> 3. Add an attribute that indicates the name of the native package that
> should be installed, and will be false by default, meaning that the
> package wouldn't be installed. Proposed attribute names:
> Then, a user can set the attribute (e.g., via a role) to the package
> name if they want to install it.
Rather than add a separate attribute, a user will simply add the name of the
package for the Ruby bindings to the node attribute for the client packages
from #1 above if they want the native package for the database Ruby libraries.
> 4. In the "database" cookbook, create "mysql" and "postgresql" recipes
> which handle installing the RubyGems "mysql" and "pg" respectively,
> using the chef_gem resource so they can be used by the database
The recipe will actually be "ruby" in the two cookbooks, and the database
cookbook's recipes will include it so you can use "database::mysql" or
> 5. Handle installing build-essential's packages during recipe compile
> phase so chef_gem works, and also ensure that the package cache is
> updated on Debian family.
This will use the new attribute in build-essential, and create a "soft"
dependency on the build-essential cookbook. As it will not be the default
behavior of the cookbooks to install the Ruby gems, we won't create a hard
dependency on the build-essential cookbook, and document its requirement for
those recipes' use only.
These will be all reflected in sub-task tickets of COOK-1441.
Questions or comments:
Joshua Timberman, Technical Program Manager
IRC, Skype, Twitter, Github: jtimberman
- [chef-dev] Re: MySQL and PostgreSQL cookbooks, RubyGems and You!, Joshua Timberman, 08/06/2012
Archive powered by MHonArc 2.6.16.