Nginx cookbook changes/improvements

Ohai Chefs,

I’ve created a couple tickets for some pretty significant changes to
Opscode’s nginx cookbook.

First, COOK-19520. It seems that the bulk of the GeoIP recipe here has
nothing to actually do with nginx, and it should be moved to its own
cookbook, e.g. “geoip.” The nginx-specific bits would be refactored into
the cookbook accordingly.

Second, COOK-19531. This proposes the removal of all the source
compiling parts of the nginx cookbook to a new cookbook, "nginx_source."
This will help narrow the scope of nginx as a library-esque cookbook that
provides common default components that can be used no matter if nginx is
installed via package or from source - recipes, definitions, attributes,
etc.

There’s a number of benefits, least of all is that maintaining the "nginx"
cookbook will be easier, as will testing it with test-kitchen.

Does this change give anyone heartburn? In other words, is anyone
particularly strongly tied to having a single cookbook that handles the
relatively simple and straightforward package install vs the arduous and
complex source install that is required for basic nginx module
customization?


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

On Sat, Nov 24, 2012 at 11:51 PM, Joshua Timberman joshua@opscode.comwrote:

Second, COOK-1953[1]. This proposes the removal of all the source
compiling parts of the nginx cookbook to a new cookbook, "nginx_source."
This will help narrow the scope of nginx as a library-esque cookbook that
provides common default components that can be used no matter if nginx is
installed via package or from source - recipes, definitions, attributes,
etc.

There's a number of benefits, least of all is that maintaining the "nginx"
cookbook will be easier, as will testing it with test-kitchen.

Does this change give anyone heartburn? In other words, is anyone
particularly strongly tied to having a single cookbook that handles the
relatively simple and straightforward package install vs the arduous and
complex source install that is required for basic nginx module
customization?

You have my +1
I've been working in this area for my upcoming CloudFoundry cookbooks, and
reusing and customizing the nginx cookbookx is a PITA right now.
The change you suggest would make things easier to understand and hopefully
to change, and that's very welcome.

To clarify, these are proposed changes :-). We'd like some discussion
and feedback first before any code is written.

On 11/24/12 3:51 PM, "Joshua Timberman" joshua@opscode.com wrote:

I've created a couple tickets for some pretty significant changes to
Opscode's nginx cookbook.

On Sun, Nov 25, 2012 at 7:51 AM, Joshua Timberman joshua@opscode.comwrote:

Second, COOK-19531. This proposes the removal of all the source
compiling parts of the nginx cookbook to a new cookbook, "nginx_source."
This will help narrow the scope of nginx as a library-esque cookbook that
provides common default components that can be used no matter if nginx is
installed via package or from source - recipes, definitions, attributes,
etc.

I am against making a nginix_source cookbook when a nginix::source recipe
should be sufficient.

In terms of the "library cookbook" theres no reason you can't use
nginix::library recipe with no content. Then people can load that up and
do whatever they want.

Bigger discussion wrt library/app cooks, but IMO these goals can be
obtained in the same recipe.

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

Sorry last line should have read: " IMO these goals can be obtained in the
same cookbook "

On Sun, Nov 25, 2012 at 10:34 AM, Jesse Nelson spheromak@gmail.com wrote:

On Sun, Nov 25, 2012 at 7:51 AM, Joshua Timberman joshua@opscode.comwrote:

Second, COOK-19531. This proposes the removal of all the source
compiling parts of the nginx cookbook to a new cookbook, "nginx_source."
This will help narrow the scope of nginx as a library-esque cookbook that
provides common default components that can be used no matter if nginx is
installed via package or from source - recipes, definitions, attributes,
etc.

I am against making a nginix_source cookbook when a nginix::source recipe
should be sufficient.

In terms of the "library cookbook" theres no reason you can't use
nginix::library recipe with no content. Then people can load that up and
do whatever they want.

Bigger discussion wrt library/app cooks, but IMO these goals can be
obtained in the same recipe.

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

On Nov 24, 2012, at 5:35 PM, Jesse Nelson wrote:

Sorry last line should have read: " IMO these goals can be obtained in the same cookbook "

On Sun, Nov 25, 2012 at 10:34 AM, Jesse Nelson spheromak@gmail.com wrote:

On Sun, Nov 25, 2012 at 7:51 AM, Joshua Timberman joshua@opscode.com wrote:

Second, COOK-1953[1]. This proposes the removal of all the source
compiling parts of the nginx cookbook to a new cookbook, "nginx_source."
[1]: http://tickets.opscode.com/browse/COOK-1953

I am against making a nginix_source cookbook when a nginix::source recipe should be sufficient.

In terms of the "library cookbook" theres no reason you can't use nginix::library recipe with no content. Then people can load that up and do whatever they want.

Bigger discussion wrt library/app cooks, but IMO these goals can be obtained in the same recipe.

I disagree. The largest issue I see in having them in the same cookbook is the dependencies they carry. In a security or compliance sensitive environment I may not even want build-essentials on my Chef server, much less on my node (even if it isn't being used). I can see a compelling case for splitting cookbooks when there are large sets of dependencies that are not used by a piece that is useful to many people.

On 11/26/12 10:15 AM, Jeffrey Hulten wrote:

I disagree. The largest issue I see in having them in the same
cookbook is the dependencies they carry. In a security or compliance
sensitive environment I may not even want build-essentials on my Chef
server, much less on my node (even if it isn't being used). I can see
a compelling case for splitting cookbooks when there are large sets of
dependencies that are not used by a piece that is useful to many people.
dead code on a box won't make you fail an audit. you can show that
build-essential is not in the expanded run_list of any server that
matters, you can also write an anti-build-essential recipe that
uninstalls it all and show its presence in the expanded run_list on
those servers, plus you can audit your servers via "knife ssh ':' rpm
-q gcc" and such and hand that information over to the auditor. all that
should be more than enough proof that you have a working prevent
control, and that there's no nodes which need any remediation and
everything conforms to policy. beyond that, time is probably "better
spent" developing a detect control to alert in nagios or whatever if gcc
gets installed on a box rather than worrying about a dead chef recipe
copied down because of a depends line sitting on the server.

On 11/26/12 10:15 AM, Jeffrey Hulten wrote:

I can see a compelling case for splitting cookbooks when there are large

sets of dependencies that are not used by a piece that is useful to many
people.

We prefer clean cookbooks with low coupling. When we have an optional
feature that may require a different cookbook we use the "suggests"
metadata in the cookbook. This documents that you may require this other
cookbook but does not download the cookbook to the client automagically.

For example, several of our cookbooks optionally use authbind (which allows
you to bind to ports 0->512 without being root). However the cookbook may
not actually need the cookbook if you are bound to a port such as 11221. So
in most of these cookbooks we must explicitly add authbind to the runlist
if we decide to configure a port like 55 that requires the use of authbind.

--
Cheers,

Peter Donald

I could see 'suggests' downloading the cookbook if it exists, but not crashing if it doesn't...

Jeffrey Hulten
Principal Consultant at Automated Labs, LLC
jeffh@automatedlabs.com 206-853-5216
Skype: jeffhulten

On Nov 26, 2012, at 4:54 PM, Peter Donald wrote:

We prefer clean cookbooks with low coupling. When we have an optional feature that may require a different cookbook we use the "suggests" metadata in the cookbook. This documents that you may require this other cookbook but does not download the cookbook to the client automagically.