If a tool works for you in a certain way, to say that you shouldn’t use the tool because it has X functionality that you are not using seems like a very exclusionary stance.
In any case, my point about chef-local and search was simply to point out that chef-local still provides search in a sense. This is important because certain community cookbooks you may want to use do have search functions and will not work at all with solo ( ie - the samba cookbook ), but you can get them to function with chef-local, which will still accomplish the goal of running in a masterless mode ( or even, say, just testing with Test Kitchen on a local instance ).
Sent from my iPhone
On Apr 8, 2015, at 8:16 AM, Booker Bense <bbense@gmail.commailto:bbense@gmail.com> wrote:
IMHO, if you really don’t want chef server, then chef likely is the wrong choice for you.
Having a standard access to search data is kinda the whole point.
With enough duct tape and bailing wire, you can probably accomplish the list of features
you have, but you’re essentially reinventing chef server in a one off, hard to maintain version.
On Tue, Apr 7, 2015 at 10:14 AM, Lamont Granquist <lamont@chef.iomailto:lamont@chef.io> wrote:
Sure, the search API works, but it doesn’t know about the rest of your infrastructure the way a chef server would, you’d need to prepopulate critical nodes or something.
On 4/7/15 10:10 AM, Hajducko, Steven wrote:
If you are not heavily using search (and moving
to chef local mode will eliminate your ability to use search entirely)
I thought local mode ( ie - chef zero ) kept the ability to do ‘searches’. At least, it works with the samba cookbook.
chef-solo, on the other hand, has no search ability.
From: Lamont Granquist <lamont@chef.iomailto:lamont@chef.io>
Sent: Tuesday, April 07, 2015 10:01 AM
To: chef@lists.opscode.commailto:chef@lists.opscode.com
Subject: [chef] Re: Questions About Solo / Local Only Chef
On 4/6/15 9:34 PM, Michael Pawlak wrote:
Chefs,
I come primarily from a Puppet background and am curious about using
Chef. Currently we have a nodeless and masterless Puppet
implementation that pulls all modules, manifests, etc. from Git and
stores configuration data in a backend PostgreSQL DB (PuppetDB).
With this being said, I am trying to figure out what similar
functionality Chef offers. Some specific questions about this are
listed below. Basically, I am trying to eliminate the Chef Server, due
to scalability / maintainability reasons, similar to removing a Puppet
Master in puppet.
Have you actually tested that a Chef Server fails to scale in your
environment? Since the Chef Server does not assemble a manifest like a
Puppet Master does, it is very thin. Mostly it just serves
configuration files. If you are not heavily using search (and moving
to chef local mode will eliminate your ability to use search entirely)
then a single Chef Server should scale to tens of thousands of nodes, or
somewhere around 10x more than a Puppet Master running on the same
hardware does. Most of the computational offload that you’re getting
from the approach you are taking with Puppet is already baked into the
Chef Client.
Where you’re used to the Puppet Master assembling a manifest and
shipping it to the Client, the analogous thing in Chef is the Resource
Collection. That is a dynamically created object that is created in the
Chef Client, rather than the server. Since the Client creates it, you
can more easily dynamically change the contents of the Resource
Collection based on the existing state of the node and the information
that the node can gather about its surroundings, and the processing
overhead is assumed entirely by the Client, not the Server.
TL;DR is don’t blindly treat Chef like Puppet right out of the gate, you
may have learned the wrong lessons.
