[[chef-dev]] Introduction and Alternate Rubygems provider


Chronological Thread 
  • From: Pierre Baillet < >
  • To:
  • Subject: [[chef-dev]] Introduction and Alternate Rubygems provider
  • Date: Fri, 14 May 2010 16:19:24 +0200

Hi,

I'm quickly introducing myself in the list and will then expose an issue we have here and a way we found to fix it. 

I'm Pierre Baillet, the lead server administrator at fotonauts. I'm in charge of most of the servers used for the fotopedia website. We use Chef on all our development, testing and production instances as a way to standardise our deployments, keep a state of what's installed on each server in case of server failure and automate releases. We are quite happy with Chef, especially when it comes to its powerful Search features that allows building all our monitoring configuration automatically !

When installing (usually at bootstrap) complex projects, the regular Rubygems Package Provider ( Chef::Provider::Package::Rubygems ) does a lot of `gem` calls, hence slowing the installation of gem quite lot. Moreover, using chef recipes that include  "~>" version checking are run at every chef run and because we run chef every 5 minutes here at fotonauts (mainly as a deployment helper) we appreciate every spared second during this procedure.

As a workaround for this, we have developed a Rubygems provider (based on a monkey patched version of the regular provider) which no longer calls the gem binary every time but:

* Uses the Gem API to grab the list of available gems, 
* Keeps this list in a cache so that subsequent calls to the Provider are much faster

The only parts that use `gem ..` is the one that actually install the gems although there is also a way to programmatically install a gem using the Gem API.

By looking at the original source code of the Provider, I think that the fact that it's not using the Gem API is something that's voluntary and I guess that it's to prevent any dependency with the internal Gem API. Am I wrong ? 

If this is the case, I suppose that our patched version will never make it to the official HEAD (although I'm not sure I understand the interest of this restriction today as Chef already relies on several external and sometimes API-changing libraries :D). 

However, if this is not the case, I'll gladly provide a patched version of the Rubygems provider with our enhancement, for testing first, of course :)

Thank you very much for your time,
-- 
Pierre.





Archive powered by MHonArc 2.6.16.

§