[chef] Re: Re: Announcing Little Chef

[Miquel Torres < >]

Hi Adam,

> As for Solo being a first class citizen, it certainly is for Opscode -
well, I didn't doubt that. That is why in my suggestions I knowingly wrote:
"In general, *continue* considering Chef Solo a first-class citizen"
;-)

Nice to see you care about this kind of use cases.

Also, if many of you find it useful, we could set up a wiki page for
Chef newbies to get started the Little Chef way. I think some people
would find that easier.

Another thing. I read some comments on the possibility of a Python
bridge for cookbooks. I can not even begin to express how cool that
would be. Little Chef being in the Python Package Index could already
bring Chef new exposure to the Python devops world. If you add to that
Python cookbooks, well, Chef would have the potential of becoming
*the* Configuration Management system, across language and culture
divides. I would certainly contribute lots of Python cookbook
"translations"!

Cheers,
Miquel


2010/10/27 Adam Jacob 
<
 >:
> This is great to see, Miquel.  For the record, we're all about people
> using Chef to fit the workflow they want most. :)
>
> As for Solo being a first class citizen, it certainly is for Opscode -
> the difference is that, unlike the client/server model, it isn't the
> way we run our infrastructure day to day.  I would love to see folks
> who care deeply about Solo become more active in development, so that
> we can make sure you're needs are getting met.
>
> Nice work!
>
> Adam
>
> On Wed, Oct 27, 2010 at 6:34 AM,  
> <
 >
>  wrote:
>> Hi Chefs!
>>
>> I would like to present Little Chef, a new project that integrates with 
>> Chef.
>>
>> LittleChef is actually an offspring of The Overmind, which was released a
>> couple of weeks ago
>> (http://mail-archives.apache.org/mod_mbox/incubator-libcloud/201010.mbox/
 ).
>> Overmind aims to be a complete server management application. The first 
>> release
>> features server provisioning, and we want to tackle Configuration 
>> Management
>> next. We have decided on Chef, but as The Overmind wants to know everything
>> about its minions, we won't be using Chef Server.
>>
>> To explore the possibility of just using Chef Solo, LittleChef was born. 
>> It is
>> a tiny framework that replaces a subset of the functionality of Chef Server
>> using a push-based system.
>>
>> Instead of needing a server to let your nodes pull info from, recipes are
>> automatically “pushed” to nodes every time you want to configure them. You
>> install LittleChef on your desktop/laptop, and work in “kitchens”
>> (deployment directories), where you have a cookbooks dir, a roles dir and a
>> nodes dir. That's it.
>>
>> Right now, in version 0.1 LittleChef:
>>
>>    * Allows to apply a recipe or role to a particular node
>>    * Saves recipes, roles and attributes for every node in configuration
>> files, which can afterwards be edited to override attributes
>>    * Updates cookbooks on every node automagically, without the need for 
>> repo
>> syncing
>>    * Can reconfigure every node
>>    * Understands simple queries like showing all nodes with particular 
>> recipes
>>    * Can't bake cookies yet
>>
>>
>> There is an extensive README explaining installation and usage details.
>>
>> FAQ
>> Q: “Wait, wait, did the world *really* need this duplication of efforts?”
>> A: “You are right. I am very sorry that I deprived the world of a couple of
>> hours of my precious hacking time to code those 200 lines of code. I hope 
>> the
>> world doesn't mourn such a devastating loss for too long.”
>>
>> Yes, you read that right. The whole thing is just a 200 lines of Python 
>> code.
>>
>> Yes, you read that right. It is written in Python.
>>
>> Python talking to Ruby. Yes, I am crazy and hope that this is the 
>> beginning of
>> a beautiful friendship.
>>
>> The repo site: (http://github.com/tobami/littlechef)
>>
>> Now, what is my purpose with this weird project besides experimenting and 
>> why
>> do I think anyone would be interested?
>>
>> LittleChef is in essence a Pocket Chef (sadly an already registered 
>> trademark).
>> There are three areas in which a Pocket Chef could be useful:
>>
>>    * For newbies: Newcomers can have a hard time getting Chef running for 
>> the
>> first time, specially if they are evaluating other alternatives and have 
>> little
>> time, and even harder if they don't have an inkling of Ruby. In the docs 
>> you
>> rightly recommend to get your feet wet with Chef Solo first, thus avoiding 
>> all
>> the Chef Server set-up/authentication overhead. But there are still to many
>> things to figure out at once. You should ideally only have to figure out a
>> single thing: how a cookbook works (and gets executed). With LittleChef, 
>> you
>> download the project to a directory on your computer and are immediately 
>> ready
>> to go. There is even a chef-solo deployment script that fetches opscode
>> packages for various distributions.
>>    * For development: while developing new cookbooks, you can currently 
>> edit
>> recipes at your working system, check-in changes and have the chef-clients
>> execute the new version of the cookbooks. That is not an optimal work-flow,
>> because you end-up checking in small or experimental changes. With 
>> LittleChef
>> you develop cookbooks at your LittleChef/cookbooks/ directory, certainly 
>> under
>> source control. When you make changes and want to try them out, you just
>> execute “fab host:hostname recipe:mynewrecipe”. The cookbooks dir will get
>> gzipped, uploaded to the node, and the recipe run by chef-solo. When your
>> recipe has attained “delicious” status, you can then check in your changes.
>> Note that this is not incompatible with using Shef.
>>    * For very small deployments: LittleChef will never be a full 
>> replacement
>> for the Chef server. A push architecture and configuration file is not the
>> right way to manage lots of servers. I can imagine though, small 
>> organizations
>> managing small numbers of servers (1-6) using LittleChef, thus avoiding the
>> need for a Chef server. They would possibly not have even considered using
>> Chef, but in this way they can manage their servers “the right way “(with a
>> CMS!) from the start.
>>
>> This project, and even more a possible integration of Chef into Overmind, 
>> have
>> only been possible because of some great design decisions in Chef 
>> development:
>>
>>    * Having chef-solo in addition to chef-client
>>    * Using json as the input/command issuing format, which removes language
>> barriers
>>    * In cookbooks, having attributes you can override listed in json format
>> will allow for even more powerful integration.
>>
>> I have a couple of suggestions so that Chef can remain a component other
>> projects can integrate seamlessly:
>>
>>    * Cookbooks: always clearly mark what cookbooks cannot be run without a
>> Chef server. Even better: always make them work without a chef server, by
>> listing the dynamic attributes in metadata.json and attributes/default.rb
>>    * In general, continue considering Chef Solo a first-class citizen. That
>> means lots of little things like for example not starting the chef-client
>> service on package installation, so that chef-solo users don't have to 
>> disable
>> the chef-client service every time after installation (which happens for
>> debian, but is done right for RHEL and CentOS)
>>
>> Happy cooking, and careful with those nodes!
>> Remember,  although a famous Chef used to say that “Anyone can cook”,
>> Little Chef says:
>> “Yeah. Anyone can, that doesn't mean that anyone should”.
>> --
>> Miquel Torres
>>
>
>
>
> --
> Opscode, Inc.
> Adam Jacob, CTO
> T: (206) 508-7449 E: 
> 
 
>