[chef] Re: Chef Server

[Adam Jacob < >]

To be clear, the Web UI won't be re-built in Erlang (that would.. um.. hurt) 
but likely will move to Rails.

Adam

---
Opscode, Inc.
Adam Jacob, Chief Customer Officer
T: (206) 619-7151 E: 

 

On Jan 3, 2012, at 7:21 PM, Joshua Timberman wrote:

> 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