[chef] Re: Re: Re: Feelings on chef

[Adam Jacob < >]

On Tue, May 4, 2010 at 6:22 AM, Marcus Bointon
<
 >
 wrote:
>> The cool part about the chef server and client is they communicate using a
>> REST interface that is well documented. This means a new server
>> implementation that isn't built to scale to a large network of nodes
>> is possible with an existing light weight web application framework
>> like Sinatra.
>
> That's exactly what I was thinking - has anyone built such a thing?

I just wanted to chime in here and say that we've had conversations
about it with a number of people, and a few of them are probably going
to actually start work on it.

From the beginning we've seen the API as the key point of integration
- if you are API compliant, you are good to go.  The chef-server
implementation clearly comes from my own needs and background -
larger, more complex deployments where the goal is to do deep
integration throughout the entire infrastructure.  If you look at the
choices we've made for the chef server, they are reflected in that.
The different components are segregated, failure of one part of the
server infrastructure won't necessarily stop everything, etc.

So from our point of view, we're stoked to see people re-use some of
the code we've written and build a more compact chef server
implementation.  We talk about how the chef-server is a reference
implementation of the API, and we mean it.

As far as who would maintain the lighter-weight implementation, the
answer is "probably not Opscode", just because of the amount of
cognitive dissonance introducing a third code-base would have.  We
would be super happy to collaborate, answer questions, provide hints
to code that could be shared, all of that.  We're just not going to be
the guys who write it. :)

Adam

-- 
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: