Description of problem: Set up env, and start openshift-routing-daemon service. Scenarios 1: * Create a non-scalable app. Go to /opt/rh/nginx14/root/etc/nginx/conf.d, the following file is generated. # ls alias_pool_ose_php53app_jialiu_80_ha-php53app-jialiu.example.com.conf pool_ose_php53app_jialiu_80.conf server.conf # cat server.conf server { listen 80; # route_name=route_ose_php53app_jialiu location /php53app { proxy_pass http://pool_ose_php53app_jialiu_80; } } # cat pool_ose_php53app_jialiu_80.conf The config file is passing request to pool_ose_php53app_jialiu_80 downstream, while pool_ose_php53app_jialiu_80.conf is empty. If user is creating a non-scalable app, these config files does not take any effect, they are meaningless. openshift-routing-daemon should not create any config file when daemon detects the app is not a scaling app. Scenarios 2: * Create a scalable app. Go to /opt/rh/nginx14/root/etc/nginx/conf.d, the following file is generated. # ls alias_pool_ose_scaphp53app_jialiu_80_ha-scaphp53app-jialiu.example.com.conf pool_ose_scaphp53app_jialiu_80.conf server.conf # cat alias_pool_ose_scaphp53app_jialiu_80_ha-scaphp53app-jialiu.example.com.conf server { listen 80; server_name ha-scaphp53app-jialiu.example.com; location / { proxy_pass http://pool_ose_scaphp53app_jialiu_80; } } "alias_pool_ose_scaphp53app_jialiu_80_ha-scaphp53app-jialiu.example.com.conf" is always created even this app does not have any alias. After search code, it is using hard code to add "ha-" prefix for server name, but maybe user would never add such alias. This would confuse user (at least, it confuse me). And when I add a real alias for this app, a specified config for the real alias is created, so suggest do NOT create such alias config when app does not have any alias yet. Version-Release number of selected component (if applicable): rubygem-openshift-origin-routing-daemon-0.17.1.4-1.el6op.noarch How reproducible: Always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Thanks for testing this Johnny. The naming of the conf files are a bit weird, but the way it works is we create a pool file when the application is created even if there are no members in the pool yet. The alias file does not only represent an alias created with RHC, it's also the alias created for any ha app. These config files will be removed when the application is removed. Also, thanks for catching the hard-coded ha- prefix!
This is now fixed as part of https://github.com/openshift/enterprise-server/commit/f7043cae2dcac8631c8ee5319c82a433c9ac294b
Retest this bug with rubygem-openshift-origin-routing-daemon-0.20.2.3-1.el6op.noarch. The issue found in scenarios 1 is fixed now, when creating non-scalable app, no nginx config files are generated. The hard-coded ha- prefix issue found in scenarios 2 is not fixed yet, the prefix should be allow user to set it in /etc/openshift/routing-daemon.conf
There is no reason to have any nginx config files for non-scalable apps. I missed the ha-prefix hard coding that was mentioned. I'll fix that.
PR open upstream. Will merge to enterprise-server when it's ready
Verified this bug with rubygem-openshift-origin-routing-daemon-0.20.2.4-1.el6op.noarch, and PASS. The lines mentioned in comment 7 is removed now. The following config options are added in /etc/openshift/routing-daemon.conf: HA_DNS_PREFIX="ha-" After I change it to HA_DNS_PREFIX="hhh-" Then create a scalable app, the following config file is generated. # cat alias_pool_ose_scaruby18app_jialiu_80_hhh-scaruby18app-jialiu.example.com.conf server { listen 80; server_name hhh-scaruby18app-jialiu.example.com; location / { proxy_pass http://pool_ose_scaruby18app_jialiu_80; } } server { listen 443 ssl; #ssl_certificate_template #ssl_certificate_key_template server_name hhh-scaruby18app-jialiu.example.com; location / { proxy_pass http://pool_ose_scaruby18app_jialiu_80; } } The modified config option takes effect now.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2014-1979.html