A large part of that was an unfortunate side-affect of gecode (a library Chef used for dependency resolution in Chef 10) not having a -nox package, thus pulling in libqt4-dev, which then spirals out of control. The chef-server cookbook used the gecode cookbook which automated installing from source without qt to avoid this if one desired.
Do it early, for many reasons. I worked as a systems administrator for startups before we wrote Chef, and I wouldn't go back to managing infrastructure by hand.
A few reasons:
* You don't have to maintain that database manually, Chef collects and stores node information for you.
* If you've already automated building out your servers, you're all set when you need more of them.
* The recipes document your systems, so if you "get hit by a bus" someone else can figure out how the bits get around.
* When your datacenter burns down, you can rebuild quickly from bare metal, a chef repository, and backups of your application data.
Also see this article written by Jesse Robbins, one of the Opscode founders, but before Chef existed:
I'm sorry you feel that you didn't have a good experience.
As one of the original Chef contributors before Opscode, and then becoming one of the lead people working with the open source community for Opscode, the vitality of the open source Chef project is very important to me. However, Opscode's support for all of our open source projects also hinges on the company being successful enough to continue to do so. Thus, a balance must be struck.
Opscode doesn't respond to every ticket on that open source tracker, just like we don't write all of the code in the open source project. I personally try to at least see every issue, but with over 1.8 million installs of the Chef gem alone, there are a lot of users out there. If you want a guaranteed response, we do have various paid support plans which will provide you with that, but it doesn't come for free because we have to pay the people who research and write those responses.
There are multiple ways to install the Chef 10 Server and many ways to start the processes. We have tried to support the most popular, and I think most people have found success. We're proud that we can do things like release our rewrite of the Chef Server in erlang back to open source. We want it to be easy for people to use Chef. We initially wrote it to make our lives easier, and we want your lives to be easier too. That's why the Chef 11 Server ships in our Omnibus packaging, which provides a running Chef Server in three commands or less.
Firstly, thanks for your reply and your works on chef. I really appreciate it.
I think there is a difference between people who want free support & people who document a bug of a opensource project clearly in the hope of to improve the quality of that project - I hope I am in the latter case.
My reported issue can be easily fixed with some hacky workarounds, so I didn't bother with it and move on (As you can see I have never comment on that ticket). However, I still decided to create that ticket because I think the issue is easy to reproduce and will affect a lot of new comers to chef.
The issue is confirmed by others as well, one awesome commenter Florin Mihaila even provided a very detail analyse and solution to the issue.
For me, I would prefer if you can close the ticket if you think it is invalid, or mark as don't fix if resource is not allowed, rather than leaving as open and unanswered.
Of course, this is your project so I can't disagree with your preference, thanks anyway :)
Always appreciate bugs being filed. I did a little pondering on the ticket the other day. Since we're using update-rc.d, we're likely talking about debian package install, which means that we could probably set the defaults correctly with update-rc.d, someone just needs to do the research and patch the init scripts or the debian packaging. So it's best for the bug to be open.
The importance of the Chef DSL is abstracting away common system interactions and most importantly, all the edge cases that come up. Whatever you are automating, you're going to be installing packages, starting services, and creating configuration files. Everyone should not need to re-invent that wheel, nor suffer finding the same Ruby GC bug when running a certain IO method.
By design, Chef fully expects you to leverage Ruby if you are operating in an environment of any complexity. Herein it differs from some other configuration management tools which strive to model everything you would want to manage. We (I am a Chef developer) often refer to our resources as primitives, the building blocks with which you code your infrastructure.
Opinions of Rubygems differ greatly and I would consider cargo culting gems as a distribution and dependency management infrastructure for Chef cookbooks to only be great for those who are strong with Ruby.
Each community has its own requirements and those of the Chef cookbook authors in general are different than those of Ruby library authors.
Lets say that I right a cookbook for apache2 on Ubuntu. What should I name the gem? Many other people will write this cookbook, particularly since mine only works for Ubuntu. Perhaps 'chef-apache2-ubuntu-btm'? Where do you store such metadata so a user can find, use, and contribute to a cookbook?
This isn't a simple solution and is a bit unique, which is why Opscode has been crafting a solution at http://community.opscode.com. It is easy to get a copy of a cookbook from the repository using 'knife cookbook site install COOKBOOK_NAME' and you can search the site through the web interface and using 'knife cookbook site search' to find the cookbook you're looking for.
The community site development has been slow, but continuous. In December we added source browsing so you can review cookbooks without downloading them.
I've never used Chef either, but those don't strike me as unique challenges. Building a Chef-only distribution mechanism to support discovery, versioning, and source viewing is fine and all, but such things do already exist in any sane dependency management infrastructure (whether we're talking about gems or maven jars or cpan or whatever). In particular, the dev side of me is baffled by the notion of having a separate toolchain for downloading source dependencies. git submodules and such are bad enough, but mucking around with a special workflow to download sources seems like it's a long path with few benefits and perhaps some big downsides (i.e. build/process repeatability?).
That said, perhaps none of that really matters; I wonder if all this comes down to hidden assumptions re: constituencies and heterogeneous skillsets, which I think is what you were pointing at in the beginning of your comment. i.e. "you need to learn the Chef toolchain" may be a more sale-able/scalable message than "you need to learn the Ruby/gem toolchain".
If package management was as a happily solved of a problem as you imply, I think we would see fewer solutions out there. Each tends to solve for the needs of its own environment, users, and sometimes the whims and bias of its developers. When you ask, why not use "gems or maven jars or cpan or whatever" I think you have to stop and ask, "why are there so many options already?"
There are many views out there for what the answer should be for Chef cookbook workflow. What you are "baffled" by, another person uses daily and argues for.
When using knife to download a cookbook into your git managed chef repository, it creates a 'vendor' branch to store the upstream version. You can utilize this to create diffs and patches to contribute back to that cookbook project. It is up to the author exactly how to do that.
Some really like git submodules, others prefer one cookbook per git repository, some just have one company-wide repository and ask you to fork and apply branches against.
I think you're right about the 'Chef toolchain.' There are [large enterprise] users of Chef who don't care that Chef is written in Ruby nor particularly want to learn Ruby. They want to use Chef. Opscode continues to strive to provide tools to make the workflow easier for Chef users as a whole over preference to a particular toolchain, especially one tied to and solving problems for a single language.
