[chef] Re: Re: chef-client cookbook and log rotation

[Joshua Timberman < >]

Ohai,


On 12/18/12 5:20 PM, "Brad Knowles" 
<
 >
 wrote:

>On Dec 18, 2012, at 3:57 PM, Kirill Timofeev 
><
 >
> wrote:
>
>> I cloned chef-client cookbook from
>>https://github.com/opscode-cookbooks/chef-client. It looks like this
>>cookbook doesn't setup logrotate for chef-client. May I ask you if this
>>was done intentionally or this is a bug?
>
>I don't work for Opscode, so I can't give you a definitive answer.

I can :-).

In this specific context, it's intentional as much as when the cookbook
was originally written the only way to manage the chef-client service was
through runit, in that init scripts weren't written, and runit's svlogd
handles log rotation on its own.

One thing we prefer to do is keep individual components free of
interdependence on other cookbooks, because it is less surprising. We
don't always do this, and we can't always do this, each cookbook is an
individual project with its own considerations here.

That said, we're not entirely consistent, and working to improve that.

>First off, keep in mind that the cookbooks provided via github are not
>the official sources of the cookbooks as far as community is concerned.
>That's where they do development of the cookbooks, but (unless specified
>otherwise) they only officially support the versions as uploaded to
><http://community.opscode.com/cookbooks>.

That is to say, Opscode's cookbooks that are published on the community
site, in as much as those are the "tested and released" versions. The
GitHub repositories are in development, like any other source repository
that ever existed, and sometimes bad code gets overlooked and pushed to
master. We often get that fixed fairly quickly, but not always.

As much as we'd like to, we can't speak to the other hundreds of cookbooks
on the community site, as we simply don't have the human capacity to do
so. 

What "cookbook support" means is outlined on this wiki page:

* http://wiki.opscode.com/display/chef/Cookbook+Support


>Secondly, the cookbooks they provide are intended to be a starting point,
>to give you ideas of how things could be done.  They are not generally
>intended to be all-encompassing.

A couple goals of our cookbooks include:

1. Generally useful primitives for commonly used or managed infrastructure
system components.
2. Examples showing various use cases, patterns, and features of Chef
itself.

This isn't all encompassing. As mentioned, each cookbook is a separate
software project with its own considerations. They're not always all
encompassing, because we don't know what other components you're going to
use with them.

For example, think about monitoring and logging systems. Should each
cookbook come with full support (via recipes, plugins) for munin,
graphite, collectd, nagios, logrotate, rsyslog, syslog-ng, logstash, or
others? Or should they each give just enough support to take care of their
own individual service and the cookbooks that support the
monitoring/logging systems have resources/providers, plugins, libraries,
etc that you can compose together for your infrastructure and your
business needs?

>Third, my view is that they try fairly hard to be OS-agnostic, and a
>cookbook like logrotate is going to necessarily have to be fairly
>OS-specific in the way it is implemented -- FreeBSD won't necessarily
>work anything like Ubuntu, Ubuntu won't necessarily work anything like
>Red Hat, none of them will work anything remotely like Windows or OS X,
>etc....

This is definitely true, and that's why, for example, our apache2 cookbook
sets up the apache2 configuration for *all* platforms it supports like
Debian/Ubuntu.

We do attempt to support as many platforms as is reasonably possible. We
rely on community contribution and testing for a lot of this, especially
for less common platforms (like FreeBSD or SmartOS).



-- 
Opscode, Inc
Joshua Timberman, Technical Community Manager
IRC, Skype, Twitter, Github: jtimberman