Design / proposal for an nginx available site resource


#1

Hello chef-dev!

First, I’d like to introduce myself. My name is Steven Cummings, and I’m a software developer at Cerner Corporation. We have a corporate contributor agreement and I’ve recently been added to it. I start learning chef about 1.5 months ago, with a heavy emphasis towards:

  • leaning on community resources
  • writing wrapper cookbooks the berkshelf way
  • based on the above writing as little code as possible for my specific application

As a result of my approach I’m identifying the code that I end up writing which I think aligns with opportunities in the community cookbooks. My initial focuses have been on python and nginx. This message is about an idea that I have for the nginx cookbook. I have proposed the design here [1] as I wish to have some discussion about it before just taking the code that I have and “throwing it over the wall” on what might be a premature pull request.

The community cookbook is good for basic installation and configuration. However, in the nginx community there are conventions (which match those of apache httpd2) to have sites-available and sites-enabled config folders, whereby vhosts are made available in the first folder, and then activated by sym’linking them into the second folder. The resource I implemented is called “nginx_available_site” which takes attributes and generates the site-specific config. Generally, a “site” is for a specific host that is being listened on, and reasonable attributes for this resource might include things like the upstreams for load-balancing, server-specific locations and gzip options, etc.

If you agree that this resource might be worthy of the community cookbook, please go help discuss it’s design here [1]. If you would like to discuss whether it should be included at all, perhaps we do that here.

Thanks for your time!

[1] https://tickets.opscode.com/browse/COOK-4323

CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner’s corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.


#2

https://github.com/poise/poise-proxy might address some of your needs.

–Noah

On Feb 21, 2014, at 9:59 AM, “Cummings,Steven” Steven.Cummings@Cerner.com wrote:

Hello chef-dev!

First, I’d like to introduce myself. My name is Steven Cummings, and I’m a software developer at Cerner Corporation. We have a corporate contributor agreement and I’ve recently been added to it. I start learning chef about 1.5 months ago, with a heavy emphasis towards:
• leaning on community resources
• writing wrapper cookbooks the berkshelf way
• based on the above writing as little code as possible for my specific application
As a result of my approach I’m identifying the code that I end up writing which I think aligns with opportunities in the community cookbooks. My initial focuses have been on python and nginx. This message is about an idea that I have for the nginx cookbook. I have proposed the design here [1] as I wish to have some discussion about it before just taking the code that I have and “throwing it over the wall” on what might be a premature pull request.

The community cookbook is good for basic installation and configuration. However, in the nginx community there are conventions (which match those of apache httpd2) to have sites-available and sites-enabled config folders, whereby vhosts are made available in the first folder, and then activated by sym’linking them into the second folder. The resource I implemented is called “nginx_available_site” which takes attributes and generates the site-specific config. Generally, a “site” is for a specific host that is being listened on, and reasonable attributes for this resource might include things like the upstreams for load-balancing, server-specific locations and gzip options, etc.

If you agree that this resource might be worthy of the community cookbook, please go help discuss it’s design here [1]. If you would like to discuss whether it should be included at all, perhaps we do that here.

Thanks for your time!

[1] https://tickets.opscode.com/browse/COOK-4323
CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner’s corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.


#3

Yes, that looks very much in the spirit of what I want, but a bit more primitive on the site-config side and then maybe doing more than I’d expect in other areas (apache2 stuff, ssl stuff).

This could very much be input into the design of an ultimate thing, thought I still believe there’s room for a more narrowly targeted LWRP for what seems like a well-defined, general community need.

Oh, BTW, one important thing I left out of my introduction, I’m estebsitec on freenode, so some of you may have seen me starting to bring this up over the past week or so in #chef :stuck_out_tongue:


From: Noah Kantrowitz [noah@coderanger.net]
Sent: Friday, February 21, 2014 12:13 PM
To: Cummings,Steven
Cc: chef-dev@lists.opscode.com
Subject: Re: [chef-dev] Design / proposal for an nginx available site resource

https://github.com/poise/poise-proxy might address some of your needs.

–Noah

On Feb 21, 2014, at 9:59 AM, “Cummings,Steven” Steven.Cummings@Cerner.com wrote:

Hello chef-dev!

First, I’d like to introduce myself. My name is Steven Cummings, and I’m a software developer at Cerner Corporation. We have a corporate contributor agreement and I’ve recently been added to it. I start learning chef about 1.5 months ago, with a heavy emphasis towards:
• leaning on community resources
• writing wrapper cookbooks the berkshelf way
• based on the above writing as little code as possible for my specific application
As a result of my approach I’m identifying the code that I end up writing which I think aligns with opportunities in the community cookbooks. My initial focuses have been on python and nginx. This message is about an idea that I have for the nginx cookbook. I have proposed the design here [1] as I wish to have some discussion about it before just taking the code that I have and “throwing it over the wall” on what might be a premature pull request.

The community cookbook is good for basic installation and configuration. However, in the nginx community there are conventions (which match those of apache httpd2) to have sites-available and sites-enabled config folders, whereby vhosts are made available in the first folder, and then activated by sym’linking them into the second folder. The resource I implemented is called “nginx_available_site” which takes attributes and generates the site-specific config. Generally, a “site” is for a specific host that is being listened on, and reasonable attributes for this resource might include things like the upstreams for load-balancing, server-specific locations and gzip options, etc.

If you agree that this resource might be worthy of the community cookbook, please go help discuss it’s design here [1]. If you would like to discuss whether it should be included at all, perhaps we do that here.

Thanks for your time!

[1] https://tickets.opscode.com/browse/COOK-4323
CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner’s corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.