[chef] Re: Chef Server


Chronological Thread 
  • From: Joshua Timberman < >
  • To:
  • Subject: [chef] Re: Chef Server
  • Date: Tue, 3 Jan 2012 20:21:54 -0700

Hello!

On Mon, Jan 2, 2012 at 3:49 PM, Tim Uckun 
< >
 wrote:
>
> There are so many moving parts in chef that it's kind of mind
> boggling.  Runit, solr, rabbitmq, merb (merb!!??), couchdb, chef,
> ohai, knife, and other addons like knife-solo (which needs python),
> librarian etc.  I am sure there is a good reason for all this but it's
> a bit intimidating to have to manage and learn all of these things.

Just to clarify a couple things about the choices in this stack:

1. Runit is not required, it is only used by default on Debian/Ubuntu
because it is more robust for service management than plain ol' init
scripts. After learning more about it, I find it far more simple than
any other service/daemon management tool.

http://smarden.org/runit

2. Merb was used because the Chef Server API and WebUI were written
well before Rails 3 or Sinatra were available. However, on Opscode
Hosted Chef, we're moving API endpoints over to Erlang based services,
and this will come to the Open Source Chef Server at some point
(mentioned in our community summit in November, but  release date is
not set - we're still moving internal services first[0]).

3. There is definitely a learning curve when considering additional
tools and plugins from the community. Chef is intended to provide you
with primitives you can use to build the configuration management and
system integration system that fits your needs best, and comes with a
number of tools and plugins that you can use right away.

> The bootstrap commands seem to ignore the fact you may have rubygems
> already installed and want to download one anyway. I wasn't expecting
> that and ended up writing my own bootstrap script.

Indeed. If you're doing Ruby/RubyGems installation in your base OS
installation or image, you'll probably need to account for that by a
custom bootstrap template.

> Knife, chef-client, chef-solo all need different config files and some
> items are repeated. I would prefer just one config file with all the
> options in it.

You can specify the configuration file to use with any of the commands
with the -c option.

knife -c /etc/chef/client.rb

For example. You should read the configuration settings page for more
information about how the various configuration options matter by
context of the tool they're used in.

http://wiki.opscode.com/display/chef/Chef+Configuration+Settings

> It would be nice if I could define my nodes in ruby like I define all
> my recipes and roles. Same goes for databags.  I also prefer yaml to
> json but that's just me.

I believe you *can*, actually, use Ruby rather than JSON for node
documents in the Chef Repository.

The class used is Chef::Knife::Core::ObjectLoader

https://github.com/opscode/chef/blob/master/chef/lib/chef/knife/core/object_loader.rb

> The wiki is pretty nice, thanks to whoever is maintaining that.

Our support engineering team is responsible for the updates and
content. We have some plans for further awesomeness coming soon.


[0]: 
http://wiki.opscode.com/display/chef/Opscode+Chef+Short-Term+Roadmap+and+Performance+Improvements
-- 
Opscode, Inc
Joshua Timberman, Technical Program Manager
IRC, Skype, Twitter, Github: jtimberman



Archive powered by MHonArc 2.6.16.

§