[chef] Re: MySQL and PostgreSQL cookbooks, RubyGems and You!

[Joshua Timberman < >]

Ohai again, Chefs!

While we haven't seen a *lot* of response on this topic, or on the related 
tickets[0], the general answers to my questions in the original email are 
answered thus:

> 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
> application(s)?

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 
nothing dramatic.

> 1. Move the list of package names for client installation and server
> installation to attributes in both cookbooks. They will be:
> 
>    node['mysql']['client_packages']
>    node['mysql']['server_packages']
>    node['postgresql']['client_packages']
>    node['postgresql']['server_packages']
> 
> Respectively, and platform specific package names would be selected
> using a case statement. This is proposed in part for the ticket
> COOK-1236[2]. 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:
> 
>   node['mysql']['ruby_package']
>   node['postgresql']['ruby_package']
> 
> 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
> resources.

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 
"database::postgresql".

> 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:

* http://tickets.opscode.com/browse/COOK-1441

-- 
Opscode, Inc
Joshua Timberman, Technical Program Manager
IRC, Skype, Twitter, Github: jtimberman