Bug 1766738
| Summary: | Application Route does not work when launched via browser | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Vijay Bhadriraju <vbhadrir> |
| Component: | Multi-Arch | Assignee: | David Benoit <dbenoit> |
| Status: | CLOSED NOTABUG | QA Contact: | Barry Donahue <bdonahue> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 4.2.z | CC: | brueckner, cbaus, dbenoit, dgilmore, hannsj_uhl, Holger.Wolf, jpoulin, raja.sekhar |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | s390x | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-12-06 02:49:42 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1765215 | ||
|
Description
Vijay Bhadriraju
2019-10-29 18:42:33 UTC
Trying to folllow up on this blocking defect. Is there any progress on it ? Hi all, Sorry for the delay. In /etc/nginx/nginx.conf, the default port 80 should be unbound and a new route should be created to the cluster endpoint at point 80. Additionally, port 80 should be added to the hypervisor's firewalld public zone. The resulting file will look something like this: # For more information on configuration, see: # * Official English Documentation: http://nginx.org/en/docs/ # * Official Russian Documentation: http://nginx.org/ru/docs/ user nginx; worker_processes auto; error_log /var/log/nginx/error.log; pid /run/nginx.pid; # Load dynamic modules. See /usr/share/doc/nginx/README.dynamic. include /usr/share/nginx/modules/*.conf; events { worker_connections 1024; } http { log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; include /etc/nginx/mime.types; default_type application/octet-stream; # Load modular configuration files from the /etc/nginx/conf.d directory. # See http://nginx.org/en/docs/ngx_core_module.html#include # for more information. include /etc/nginx/conf.d/*.conf; } # BEGIN ANSIBLE MANAGED BLOCK stream { upstream openshift_console { server 192.168.122.28:443 max_fails=3 fail_timeout=10s; } server { listen 443; proxy_pass openshift_console; } upstream openshift_api { server 192.168.122.28:6443 max_fails=3 fail_timeout=10s; } server { listen 6443; proxy_pass openshift_api; } upstream openshift_http { server 192.168.122.28:80 max_fails=3 fail_timeout=10s; } server { listen 80; proxy_pass openshift_http; } } # END ANSIBLE MANAGED BLOCK Please let me know if this works for you. Can you be more specific with the name of the POD and node that the conf file - /etc/nginx/nginx.conf needed to be edited and also any instructions for port 80 to be added to the hypervisor's firewalld public zone. We are using KVM in this case ?? Thanks. Can you be more specific with the name of the POD and node that the conf file - /etc/nginx/nginx.conf needed to be edited and also any instructions for port 80 to be added to the hypervisor's firewalld public zone ? We are using KVM in this case. Thanks. (In reply to David Benoit from comment #2) > Hi all, > > Sorry for the delay. In /etc/nginx/nginx.conf, the default port 80 should > be unbound and a new route should be created to the cluster endpoint at > point 80. Additionally, port 80 should be added to the hypervisor's > firewalld public zone. The resulting file will look something like this: > > # For more information on configuration, see: > # * Official English Documentation: http://nginx.org/en/docs/ > # * Official Russian Documentation: http://nginx.org/ru/docs/ > > user nginx; > worker_processes auto; > error_log /var/log/nginx/error.log; > pid /run/nginx.pid; > > # Load dynamic modules. See /usr/share/doc/nginx/README.dynamic. > include /usr/share/nginx/modules/*.conf; > > events { > worker_connections 1024; > } > > http { > log_format main '$remote_addr - $remote_user [$time_local] "$request" ' > '$status $body_bytes_sent "$http_referer" ' > '"$http_user_agent" "$http_x_forwarded_for"'; > > access_log /var/log/nginx/access.log main; > > sendfile on; > tcp_nopush on; > tcp_nodelay on; > keepalive_timeout 65; > types_hash_max_size 2048; > > include /etc/nginx/mime.types; > default_type application/octet-stream; > > # Load modular configuration files from the /etc/nginx/conf.d directory. > # See http://nginx.org/en/docs/ngx_core_module.html#include > # for more information. > include /etc/nginx/conf.d/*.conf; > > } > > # BEGIN ANSIBLE MANAGED BLOCK > stream { > upstream openshift_console { > server 192.168.122.28:443 max_fails=3 fail_timeout=10s; > } > server { > listen 443; > proxy_pass openshift_console; > } > upstream openshift_api { > server 192.168.122.28:6443 max_fails=3 fail_timeout=10s; > } > server { > listen 6443; > proxy_pass openshift_api; > } > upstream openshift_http { > server 192.168.122.28:80 max_fails=3 fail_timeout=10s; > } > server { > listen 80; > proxy_pass openshift_http; > } > } > # END ANSIBLE MANAGED BLOCK > > > Please let me know if this works for you. This change should be made to /etc/nginx/nginx.conf and firewalld directly on the hypervisor. Sorry for the ambiguity. You can add the firewalld port using: firewall-cmd --zone=public --permanent --add-port=80/tcp Please let me know if there are any more questions. We are happy to help however we can. Here is the my edited nginx.conf file on the Hypervisor. I also ran the firewall-cmd --zone=public --permanent --add-port=80/tcp on the hypervisor that was successful. I deleted the old route and created a new route for the service of my application and the route still does not work with these changes. One thing not clear is how does the changes in the nginx.conf take effect without restarting any of OCP services. Am I missing something and are my nginx.conf file edits correct ? [root@zrkvmpf2 vbhadrir]# cat /etc/nginx/nginx.conf # For more information on configuration, see: # * Official English Documentation: http://nginx.org/en/docs/ # * Official Russian Documentation: http://nginx.org/ru/docs/ user nginx; worker_processes auto; error_log /var/log/nginx/error.log; pid /run/nginx.pid; # Load dynamic modules. See /usr/share/doc/nginx/README.dynamic. include /usr/share/nginx/modules/*.conf; events { worker_connections 1024; } http { log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; include /etc/nginx/mime.types; default_type application/octet-stream; # Load modular configuration files from the /etc/nginx/conf.d directory. # See http://nginx.org/en/docs/ngx_core_module.html#include # for more information. include /etc/nginx/conf.d/*.conf; } # server { # listen 80 default_server; # listen [::]:80 default_server; # server_name _; # root /usr/share/nginx/html; # Load configuration files for the default server block. # include /etc/nginx/default.d/*.conf; # location / { # } # error_page 404 /404.html; # location = /40x.html { # } # error_page 500 502 503 504 /50x.html; # location = /50x.html { # } # } # Settings for a TLS enabled server. # # server { # listen 443 ssl http2 default_server; # listen [::]:443 ssl http2 default_server; # server_name _; # root /usr/share/nginx/html; # # ssl_certificate "/etc/pki/nginx/server.crt"; # ssl_certificate_key "/etc/pki/nginx/private/server.key"; # ssl_session_cache shared:SSL:1m; # ssl_session_timeout 10m; # ssl_ciphers PROFILE=SYSTEM; # ssl_prefer_server_ciphers on; # # # Load configuration files for the default server block. # include /etc/nginx/default.d/*.conf; # # location / { # } # # error_page 404 /404.html; # location = /40x.html { # } # # error_page 500 502 503 504 /50x.html; # location = /50x.html { # } # } # BEGIN ANSIBLE MANAGED BLOCK stream { upstream openshift_console { server 192.168.122.28:443 max_fails=3 fail_timeout=10s; } server { listen 443; proxy_pass openshift_console; } upstream openshift_api { server 192.168.122.28:6443 max_fails=3 fail_timeout=10s; } server { listen 6443; proxy_pass openshift_api; } upstream openshift_http { server 192.168.122.28:80 max_fails=3 fail_timeout=10s; } server { listen 80; proxy_pass openshift_http; } } # END ANSIBLE MANAGED BLOCK This defect is a blocking defect for OCP on Z as any application deployed on OCP running on Linux on Z cannot be used even though it is exposed via a route. Are you able to curl the application endpoint from the hypervisor itself, after the /etc/hosts entry is added to the hypervisor? Sorry, I did not mean to reset the severity One more thing, could you try running `sudo setenforce 0; sudo systemctl restart nginx` on the hypervisor and let me know if that works? Depending on your RHEL settings, it is possible that SELinux is blocking nginx from binding. Setting SELinux to permissive mode like this would not be recommended in a production environment, but z/KVM is not going to be a supported configuration so it should be fine for internal development. If this is indeed the issue, it should not be seen in any z/VM deployments. SELinux is already disabled on my hypervisor. getenforce results in disabled. I ran sudo systemctl restart nginx, deleted the existing route and recreated the route and still not able to curl the route or launch in the browser. I am running curl from my client that oc CLI installed and logged into the cluster. root@x3650m5-12:/home/vbhadrir# curl https://megaweb-megabank.apps.cpo-ocpz-cluster.redhat.com curl: (6) Could not resolve host: megaweb-megabank.apps.cpo-ocpz-cluster.redhat.com Can you curl the application URL from the hypervisor after adding the /etc/hosts entry though? This step will help us identify whether or no the issue is routing through the hypervisor. Thanks, DB Oh, actually your latest post provides some key new insight I think! The issue may be with the /etc/hosts file. Since there is no DNS resolving these hostnames, you may need to add megaweb-megabank.apps.cpo-ocpz-cluster.redhat.com to you /etc/hosts on your laptop. This will be the case for all new routes created for the cluster. Please let me know if this works. I will make sure this step is clear in the next release of the documentation. I tried the above fix with 2 different applications and the route for both the application does not work. Here is copy of my /etc/hosts file on my client. megaweb-megabank.apps.cpo-ocpz-cluster.redhat.com and acmeair-megabank.apps.cpo-ocpz-cluster.redhat.com are the 2 routes hostnames I added to the /etc/hosts on my client. 192.168.12.117 is the IP address of the RHEL 8 KVM Hypervisor running OCP. root@x3650m5-12:/home/vbhadrir/minishift/minishift-1.34.1-linux-amd64# cat /etc/hosts 127.0.0.1 localhost #9.76.59.39 x3650m5-12.cpolab.ibm.com x3650m5-12 192.168.12.154 x3650m5-12.cpolab.ibm.com x3650m5-12 #192.168.12.155 zlxuicp1.cpolab.ibm.com zlxuicp1 192.168.12.182 zuicp002.ctl.local zuicp002 192.168.12.183 zuicp003.ctl.local zuicp003 #9.76.59.36 zlxuicp1.cpolab.ibm.com zlxuicp1 # The following lines are desirable for IPv6 capable hosts #::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters 192.168.12.154 mycluster.icp 192.168.12.154 mycluster.icp 192.168.13.117 bastion.cpo-ocpz-cluster.redhat.com api.cpo-ocpz-cluster.redhat.com console-openshift-console.apps.cpo-ocpz-cluster.redhat.com oauth-openshift.apps.cpo-ocpz-cluster.redhat.com megaweb-megabank.apps.cpo-ocpz-cluster.redhat.com acmeair-megabank.apps.cpo-ocpz-cluster.redhat.com Ok, this is good progress though. According to the email, you are now able to hit the endpoint of the cluster. The next step is to find out why the route is not working. Could you please post the list of commands and manifests you used to create the route? Thanks, DB It would be good to see the manifest used for the service too. Route Meta-Date
root@x3650m5-12:~/Downloads# cat route-megaweb.yaml
kind: Route
apiVersion: route.openshift.io/v1
metadata:
name: megaweb
namespace: megabank
selfLink: /apis/route.openshift.io/v1/namespaces/megabank/routes/megaweb
uid: e0f51fdf-04fc-11ea-a579-0a580a810028
resourceVersion: '5116271'
creationTimestamp: '2019-11-12T03:31:14Z'
labels:
app: megaweb
annotations:
openshift.io/host.generated: 'true'
spec:
host: megaweb-megabank.apps.cpo-ocpz-cluster.redhat.com
subdomain: ''
to:
kind: Service
name: megaweb
weight: 100
port:
targetPort: 9080-tcp
wildcardPolicy: None
status:
ingress:
- host: megaweb-megabank.apps.cpo-ocpz-cluster.redhat.com
routerName: default
conditions:
- type: Admitted
status: 'True'
lastTransitionTime: '2019-11-12T03:31:14Z'
wildcardPolicy: None
routerCanonicalHostname: apps.cpo-ocpz-cluster.redhat.com
Service Metadata
root@x3650m5-12:~/Downloads# cat service-megaweb.yaml
kind: Service
apiVersion: v1
metadata:
name: megaweb
namespace: megabank
selfLink: /api/v1/namespaces/megabank/services/megaweb
uid: b5d7b23c-04fc-11ea-afe5-525400da7041
resourceVersion: '5115927'
creationTimestamp: '2019-11-12T03:30:01Z'
labels:
app: megaweb
annotations:
openshift.io/generated-by: OpenShiftNewApp
spec:
ports:
- name: 9080-tcp
protocol: TCP
port: 9080
targetPort: 9080
- name: 9443-tcp
protocol: TCP
port: 9443
targetPort: 9443
selector:
app: megaweb
deploymentconfig: megaweb
clusterIP: 172.30.147.68
type: ClusterIP
sessionAffinity: None
status:
loadBalancer: {}
Can you try the following two commands to see if the app is routed as non-TLS? curl http://megaweb-megabank.apps.cpo-ocpz-cluster.redhat.com curl -k https://megaweb-megabank.apps.cpo-ocpz-cluster.redhat.com:80 Here are the results from the two curl commands root@x3650m5-12:~/Downloads# curl http://megaweb-megabank.apps.cpo-ocpz-cluster.redhat.com curl: (7) Failed to connect to megaweb-megabank.apps.cpo-ocpz-cluster.redhat.com port 80: No route to host root@x3650m5-12:~/Downloads# curl -k https://megaweb-megabank.apps.cpo-ocpz-cluster.redhat.com:80 curl: (7) Failed to connect to megaweb-megabank.apps.cpo-ocpz-cluster.redhat.com port 80: No route to host Can you post me the output of: oc get routes --all-namespaces oc get svc --all-namespaces Also, you are able to access the main openshift web console gui, right? root@x3650m5-12:~/Downloads# oc get routes --all-namespaces NAMESPACE NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD megabank acmeair acmeair-megabank.apps.cpo-ocpz-cluster.redhat.com acmeair 9080-tcp None megabank megaweb megaweb-megabank.apps.cpo-ocpz-cluster.redhat.com megaweb 9080-tcp None openshift-authentication oauth-openshift oauth-openshift.apps.cpo-ocpz-cluster.redhat.com oauth-openshift 6443 passthrough/Redirect None openshift-console console console-openshift-console.apps.cpo-ocpz-cluster.redhat.com console https reencrypt/Redirect None openshift-console downloads downloads-openshift-console.apps.cpo-ocpz-cluster.redhat.com downloads http edge/Redirect None openshift-monitoring alertmanager-main alertmanager-main-openshift-monitoring.apps.cpo-ocpz-cluster.redhat.com alertmanager-main web reencrypt/Redirect None openshift-monitoring grafana grafana-openshift-monitoring.apps.cpo-ocpz-cluster.redhat.com grafana https reencrypt/Redirect None openshift-monitoring prometheus-k8s prometheus-k8s-openshift-monitoring.apps.cpo-ocpz-cluster.redhat.com prometheus-k8s web reencrypt/Redirect None root@x3650m5-12:~/Downloads# oc get svc --all-namespaces NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE default kubernetes ClusterIP 172.30.0.1 <none> 443/TCP 15d default openshift ExternalName <none> kubernetes.default.svc.cluster.local <none> 15d kube-system kubelet ClusterIP None <none> 10250/TCP 15d megabank acmeair ClusterIP 172.30.247.250 <none> 9080/TCP,9443/TCP 15h megabank helloworld ClusterIP 172.30.217.130 <none> 8080/TCP,8888/TCP 16h megabank megaweb ClusterIP 172.30.147.68 <none> 9080/TCP,9443/TCP 18h openshift-apiserver-operator metrics ClusterIP 172.30.251.18 <none> 443/TCP 15d openshift-apiserver api ClusterIP 172.30.28.216 <none> 443/TCP 15d openshift-authentication-operator metrics ClusterIP 172.30.142.225 <none> 443/TCP 15d openshift-authentication oauth-openshift ClusterIP 172.30.247.228 <none> 443/TCP 15d openshift-cloud-credential-operator controller-manager-service ClusterIP 172.30.250.44 <none> 443/TCP 15d openshift-cluster-version cluster-version-operator ClusterIP 172.30.172.222 <none> 9099/TCP 15d openshift-console-operator metrics ClusterIP 172.30.143.170 <none> 443/TCP 15d openshift-console console ClusterIP 172.30.35.189 <none> 443/TCP 15d openshift-console downloads ClusterIP 172.30.9.231 <none> 80/TCP 15d openshift-controller-manager-operator metrics ClusterIP 172.30.166.39 <none> 443/TCP 15d openshift-controller-manager controller-manager ClusterIP 172.30.34.221 <none> 443/TCP 15d openshift-dns dns-default ClusterIP 172.30.0.10 <none> 53/UDP,53/TCP,9153/TCP 15d openshift-etcd etcd ClusterIP 172.30.120.96 <none> 2379/TCP,9979/TCP 15d openshift-etcd host-etcd ClusterIP None <none> 2379/TCP 15d openshift-image-registry image-registry ClusterIP 172.30.91.205 <none> 5000/TCP 15d openshift-ingress router-internal-default ClusterIP 172.30.221.67 <none> 80/TCP,443/TCP,1936/TCP 15d openshift-kube-apiserver-operator metrics ClusterIP 172.30.98.201 <none> 443/TCP 15d openshift-kube-apiserver apiserver ClusterIP 172.30.231.192 <none> 443/TCP 15d openshift-kube-controller-manager-operator metrics ClusterIP 172.30.224.5 <none> 443/TCP 15d openshift-kube-controller-manager kube-controller-manager ClusterIP 172.30.222.222 <none> 443/TCP 15d openshift-kube-scheduler-operator metrics ClusterIP 172.30.245.74 <none> 443/TCP 15d openshift-kube-scheduler scheduler ClusterIP 172.30.107.227 <none> 443/TCP 15d openshift-machine-api cluster-autoscaler-operator ClusterIP 172.30.72.32 <none> 443/TCP,8080/TCP 15d openshift-machine-api machine-api-operator ClusterIP 172.30.218.106 <none> 8080/TCP 15d openshift-marketplace certified-operators ClusterIP 172.30.87.124 <none> 50051/TCP 4d5h openshift-marketplace community-operators ClusterIP 172.30.128.132 <none> 50051/TCP 8h openshift-marketplace marketplace-operator-metrics ClusterIP 172.30.166.103 <none> 8383/TCP 15d openshift-marketplace redhat-operators ClusterIP 172.30.249.170 <none> 50051/TCP 8h openshift-monitoring alertmanager-main ClusterIP 172.30.153.28 <none> 9094/TCP 15d openshift-monitoring alertmanager-operated ClusterIP None <none> 9093/TCP,9094/TCP,9094/UDP 15d openshift-monitoring cluster-monitoring-operator ClusterIP None <none> 8080/TCP 15d openshift-monitoring grafana ClusterIP 172.30.203.77 <none> 3000/TCP 15d openshift-monitoring kube-state-metrics ClusterIP None <none> 8443/TCP,9443/TCP 15d openshift-monitoring node-exporter ClusterIP None <none> 9100/TCP 15d openshift-monitoring openshift-state-metrics ClusterIP None <none> 8443/TCP,9443/TCP 15d openshift-monitoring prometheus-adapter ClusterIP 172.30.54.153 <none> 443/TCP 15d openshift-monitoring prometheus-k8s ClusterIP 172.30.190.49 <none> 9091/TCP,9092/TCP 15d openshift-monitoring prometheus-operated ClusterIP None <none> 9090/TCP 15d openshift-monitoring prometheus-operator ClusterIP None <none> 8080/TCP 15d openshift-multus multus-admission-controller ClusterIP 172.30.212.141 <none> 443/TCP 15d openshift-operator-lifecycle-manager catalog-operator-metrics ClusterIP 172.30.46.66 <none> 8081/TCP 15d openshift-operator-lifecycle-manager olm-operator-metrics ClusterIP 172.30.10.126 <none> 8081/TCP 15d openshift-operator-lifecycle-manager v1-packages-operators-coreos-com ClusterIP 172.30.232.193 <none> 443/TCP 14d openshift-sdn sdn ClusterIP None <none> 9101/TCP 15d openshift-service-catalog-apiserver-operator metrics ClusterIP 172.30.200.69 <none> 443/TCP 15d openshift-service-catalog-controller-manager-operator metrics ClusterIP 172.30.132.99 <none> 443/TCP 15d openshift megaweb ClusterIP 172.30.65.152 <none> 9080/TCP,9443/TCP 18h root@x3650m5-12:~/Downloads# Yes, I am able to access the openshift web console gui. One other problem I am having is that I am not able to access the OpenShift internal registry to push my container images. To work around this, I am using the docker.io public docker hub registry to push my images and deploy the new-app using the image from docker hub. If you have any tips on how to access the OpenShift internal registry it would be helpful. Have got on a call with David and cbaus late last week and have this problem resolved. The resolution has some next steps to be taken that needs changes in the OCP for Z product. David is going to work on the next steps. The defect can be closed at this point. Hi all, I have spoken with several architects on the openshift team regarding the concerns over ease of configuration of routes, and after walking them through the cluster configuration we have provided you on z/VM and z/KVM, they have confirmed that either adding non-standard ports to the load balancer or creating services on ports 80 or 443 as demonstrated during the call is an expected administrative task for any UPI installation. This is not specific to s390x, and while perhaps not particularly simple to configure by hand, it was deemed by the OCP team as not a bug. Vijay, could you post the final yaml configuration of the working service and route? It may be of help to others who run into this configuration issue in the future. Thanks, DB Here is the working yaml of the route and service for the application that had issues with the out of the box route created by OCP. The original port 9080 on which the application listening was replaced with port 443 for https to port 80
[root@localhost ~]# oc get svc/megaweb -o yaml
apiVersion: v1
kind: Service
metadata:
annotations:
openshift.io/generated-by: OpenShiftNewApp
creationTimestamp: "2019-11-12T03:30:01Z"
labels:
app: megaweb
name: megaweb
namespace: megabank
resourceVersion: "6464614"
selfLink: /api/v1/namespaces/megabank/services/megaweb
uid: b5d7b23c-04fc-11ea-afe5-525400da7041
spec:
clusterIP: 172.30.147.68
ports:
- name: https
port: 443
protocol: TCP
targetPort: 9080
- name: 9443-tcp
port: 9443
protocol: TCP
targetPort: 9443
selector:
app: megaweb
deploymentconfig: megaweb
sessionAffinity: None
type: ClusterIP
status:
loadBalancer: {}
For the route tls: element was added. This was added to mimic how the OCP console route is exposed.
tls:
insecureEdgeTerminationPolicy: Redirect
termination: edge
[root@localhost ~]# oc get route/megaweb -o yaml
apiVersion: route.openshift.io/v1
kind: Route
metadata:
annotations:
openshift.io/host.generated: "true"
creationTimestamp: "2019-11-12T03:31:14Z"
labels:
app: megaweb
name: megaweb
namespace: megabank
resourceVersion: "6463510"
selfLink: /apis/route.openshift.io/v1/namespaces/megabank/routes/megaweb
uid: e0f51fdf-04fc-11ea-a579-0a580a810028
spec:
host: megaweb-megabank.apps.cpo-ocpz-cluster.redhat.com
port:
targetPort: https
subdomain: ""
tls:
insecureEdgeTerminationPolicy: Redirect
termination: edge
to:
kind: Service
name: megaweb
weight: 100
wildcardPolicy: None
status:
ingress:
- conditions:
- lastTransitionTime: "2019-11-12T03:31:14Z"
status: "True"
type: Admitted
host: megaweb-megabank.apps.cpo-ocpz-cluster.redhat.com
routerCanonicalHostname: apps.cpo-ocpz-cluster.redhat.com
routerName: default
wildcardPolicy: None
(In reply to David Benoit from comment #26) > Hi all, > > I have spoken with several architects on the openshift team regarding the > concerns over ease of configuration of routes, and after walking them > through the cluster configuration we have provided you on z/VM and z/KVM, > they have confirmed that either adding non-standard ports to the load > balancer or creating services on ports 80 or 443 as demonstrated during the > call is an expected administrative task for any UPI installation. This is > not specific to s390x, and while perhaps not particularly simple to > configure by hand, it was deemed by the OCP team as not a bug. > > Vijay, could you post the final yaml configuration of the working service > and route? It may be of help to others who run into this configuration > issue in the future. > > Thanks, > DB Here is the working yaml of the route and service for the application that had issues with the out of the box route created by OCP. The original port 9080 on which the application listening was replaced with port 443 for https to port 80 [root@localhost ~]# oc get svc/megaweb -o yaml apiVersion: v1 kind: Service metadata: annotations: openshift.io/generated-by: OpenShiftNewApp creationTimestamp: "2019-11-12T03:30:01Z" labels: app: megaweb name: megaweb namespace: megabank resourceVersion: "6464614" selfLink: /api/v1/namespaces/megabank/services/megaweb uid: b5d7b23c-04fc-11ea-afe5-525400da7041 spec: clusterIP: 172.30.147.68 ports: - name: https port: 443 protocol: TCP targetPort: 9080 - name: 9443-tcp port: 9443 protocol: TCP targetPort: 9443 selector: app: megaweb deploymentconfig: megaweb sessionAffinity: None type: ClusterIP status: loadBalancer: {} For the route tls: element was added. This was added to mimic how the OCP console route is exposed. tls: insecureEdgeTerminationPolicy: Redirect termination: edge [root@localhost ~]# oc get route/megaweb -o yaml apiVersion: route.openshift.io/v1 kind: Route metadata: annotations: openshift.io/host.generated: "true" creationTimestamp: "2019-11-12T03:31:14Z" labels: app: megaweb name: megaweb namespace: megabank resourceVersion: "6463510" selfLink: /apis/route.openshift.io/v1/namespaces/megabank/routes/megaweb uid: e0f51fdf-04fc-11ea-a579-0a580a810028 spec: host: megaweb-megabank.apps.cpo-ocpz-cluster.redhat.com port: targetPort: https subdomain: "" tls: insecureEdgeTerminationPolicy: Redirect termination: edge to: kind: Service name: megaweb weight: 100 wildcardPolicy: None status: ingress: - conditions: - lastTransitionTime: "2019-11-12T03:31:14Z" status: "True" type: Admitted host: megaweb-megabank.apps.cpo-ocpz-cluster.redhat.com routerCanonicalHostname: apps.cpo-ocpz-cluster.redhat.com routerName: default wildcardPolicy: None This is marked as urgent severity, and it appears to have been resolved (in terms of providing a working configuration). What remains to be done with this before we can complete it? Sounds like we'd need to document the working configuration and let QA verify the configuration. Dbenoit - any thoughts? Hi all, I will close this now. To summarize for anyone who runs into this in the future, Vijay's latest post is the correct configuration for this circumstance. One caveat to the UPI installation is that there is an external load balancer to the cluster. In the latest posted yaml manifest, the service forwards the default https port (443) to the pod's target port. Port 443 is already expected to be enabled in the external load balancer as part of the install instructions, so the service's route should then be resolvable. |