[chef] Re: Announcing Little Chef

[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: