Feature nginx

[bastelfreak]

add basic nginx/unicorn support. nginx vhost is currently based on a template, not on nginx::resource:vhost. tested on centos 7.

[bastelfreak]

Hey stephenrjohnson, could you take a look at the code?

[stephenrjohnson]

I'll get to this on the weekend, sorry about the delay.

[gavinrogers]

I'm interested in having this merged as well please @stephenrjohnson

[bastelfreak]

Hey @stephenrjohnson
possible for you to take a look at this?

[arenstar]

epel offers python-gunicorn.. ? why compile it?

i think there should be an option to use a local package - i try to avoid compiling on production machines where i can...

[bastelfreak]

Well, unicorn isn't the same as gunicorn. In general I noticed that the rpms are most of the time outdated so I prefer gems. Also unicorn isn't available via base/epel/extras repos on CentOS7

[arenstar]

bastelfreak - i just actually just realised my error there. yep..
Sorry bout that..

Is it possible to have the option of using a package instead though?
ill often build my own packages and distribute them for my systems

[bastelfreak]

So an option to swtich between the gem or an rpm and the option to specifiy the name of the rpm? Can I assume that the rpm is available via any configured repository? would this suit your needs?

[stephenrjohnson]

I'm holding off merging this until you have made the changes, outlined above.

[arenstar]

bastelfreak, exactly 👍

in my situation id simply like to offer a rpm package name, which would avoid installing and building using gcc - etc.

Soo setting the package_name

it would also be important to set

installpath - https://github.com/stephenrjohnson/puppetmodule/pull/74/files#diff-85eb9f3c6e80aebeebc8c583f5afd80bR5

and i noticed you arent using the puppet_passenger_port -> https://github.com/stephenrjohnson/puppetmodule/pull/74/files#diff-d52434b9535ec86f061db077733da1fbR23

there are other modules out there which manage repository management.
Lets assume that the rpm should just be available to the system :)

[bastelfreak]

Can I assume that the binary is always available in your $PATH? Your do you want to specify the complete path to the binary?

I will try to add the changes later this week. are you able to write some unit/rspec tests?

[bastelfreak]

hey @stephenrjohnson could you please take a look at this? implemented the mentioned stuff from @arenstar

let me know if I should rebase it into one commit

[bastelfreak]

tested this yesterday on several nodes together with @gavinrogers and we fixed two bugs. currently it is running fine on multiple production systems

[stephenrjohnson]

I know why this has been done but it's a backwards breaking change so we are going to have to make this a major version release.

[stephenrjohnson]

The last think we need is some tests as this is a massive change. Have a look in spec/acceptance/ and we don't have any spec tests to test both branches of the webserver tree or even any for the unicorn class.

[bastelfreak]

anybody with a bit of experience in writing tests around that could assist me? Maybe @gavinrogers ?

[gavinrogers]

@stephenrjohnson i've started working on spec tests etc. i was curious about the acceptance tests, i noticed that one of the targets is centos7, but i haven't yet found a way to install passenger on centos7, where is the package coming from? i've got it working fine on that platform using the unicorn class, let me get the tests done

[bastelfreak]

You're writing the tests? Awesome! thanks!

[stephenrjohnson]

@gavinrogers If you look at the spec_helper_acceptance

if osfamily == 'RedHat'
on host, puppet('module', 'install', 'stahnma-epel'), { :acceptable_exit_codes => [0,1] }
on host, puppet('apply', '-e', '"class {epel:}"'), { :acceptable_exit_codes => [0] }
#passenger repo
shell("rpm -iv http://yum.theforeman.org/releases/latest/el#{osrelease}/x86_64/foreman-release.rpm")
end

[benfairless]

Extremely interested in this option. The rest of our stack runs on Nginx & Unicorn/Gunicorn so this would sit within that perfectly.

Obviously the progress on this change has been slow lately. Is there anything I can do to assist in merging it in? Happy to assist with puppet code, testing etc

[bastelfreak]

please please please write tests. I've no clue about that, would be awesome if you could contribute it.

[benfairless]

Is that the only change necessary? I'd like to see the vhost for nginx setup using jfryman/nginx. Can do that too if you'd like?

[bastelfreak]

I can take a look again and try to create a vhost config via jfryman/nginx. Do you know a bit about selinux and can maybe improve the current settings?

[benfairless]

I've merged all the upstream code and fixed all existing tests (other than ones not passing upstream). Whilst writing unit tests for unicorn though I noticed that none of the parameters for puppet::unicorn have default values at this point. I might have to make some more significant modifications to get it working in a sane manner.

[bastelfreak]

looks way better now, travis shows only three issues, all not based on this code.

[stephenrjohnson]

The issues are caused by your merges not being clean this really needs rebasing on matser.

[bastelfreak]

rebase is on its way!

[bastelfreak]

@stephenrjohnson would it be okay for you if I squash this into one commit before rebasing?

[stephenrjohnson]

Not the best but sure it's fine.

[bastelfreak]

Did a huge squash and then rebased against your master

[stephenrjohnson]

Why is this still breaking the tests that work before the merge.

[bastelfreak]

hey @stephenrjohnson, could you have a look again? Did a new rebase and fixed the two travis issues (trailing whitespace and missing variable scope). Can you tell me why travis is failling?