stephenrjohnson
Feature nginx
add basic nginx/unicorn support. nginx vhost is currently based on a template, not on nginx::resource:vhost. tested on centos 7.
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...
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
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
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?
I'm holding off merging this until you have made the changes, outlined above.
bastelfreak, exactly :+1:
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 :)
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?
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
tested this yesterday on several nodes together with @gavinrogers and we fixed two bugs. currently it is running fine on multiple production systems
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.
anybody with a bit of experience in writing tests around that could assist me? Maybe @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
@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
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
please please please write tests. I've no clue about that, would be awesome if you could contribute it.
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?
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?
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.
looks way better now, travis shows only three issues, all not based on this code.
The issues are caused by your merges not being clean this really needs rebasing on matser.
@stephenrjohnson would it be okay for you if I squash this into one commit before rebasing?