Bryan is exactly spot-on as to the reasons for the port. We’ve run into several scaling issues with the existing Ruby server and CouchDB storage. The Erlang-based server consumes less memory, generally has better performance, and we’ve found (re-discovered?) relational databases to be a better match for our server-side needs.
See the links at the end of “Introducing erchef” (http://www.opscode.com/blog/2012/08/27/introducing-erchef) if you’re interested in the gory details.
On Sep 17, 2012, at 4:26 PM, John Wong wrote:
Exactly, what’s the reason behind moving from Ruby API (I think it’s in Ruby?) to Erlang API?
Is Chef itself rebuilt as well?
On Mon, Sep 17, 2012 at 4:00 PM, Bryan McLellan firstname.lastname@example.org wrote:
On Mon, Sep 17, 2012 at 3:51 PM, email@example.com wrote:
i’d like to read up on chef 11 as i make decisions on handling my current chef
10 infrastructure. i’d like to be prepared for what’s coming, and make
all i’ve found so far is
any other docs? or is development on chef 11 just not far enough along yet?
Chef 11 is planned to ship in a couple of months, and is pretty far along.
The Chef 11 API Server is written in erlang. Check out the initial
blog post for the “erchef” project here:
The big feature here is scalability, as a lot of this work was driven
by our internal work scaling Opscode Hosted Chef.
The best way to get familiar with it now is to test it in a sandbox.
More documentation will come along with the release.