[chef] Re: Re: Announcing Little Chef

[Miquel Torres < >]

Hi again,

I was thinking that LittleChef has a single limitation for its
intended use: if you have too many cookbooks it will be slow to push
all of them to a node. So I went ahead this morning and rewrote that
part. It now mimics Chef Server. It looks for recipes being directly
applied + recipes in the roles being applied + dependencies, and sends
*only* those to the node.

I have released the new version as 0.2.1, with a couple more fixes and 
niceties.

Now it is not a problem to clone and work with the whole
opscode/cookbooks repo ;-)

Cheers,
Miquel



2010/10/27  
<
 >:
> 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
>