Hi, Sorry about the delayed update. I just reverted to a clean snapshot of my VMs and ran a fresh cluster deployment, and the issue isn’t present anymore. Seems it was related to a failure I had faced quite early on in the deployment phase.
Regards > On Oct 1, 2018, at 17:51, Daniel Comnea <comnea.d...@gmail.com> wrote: > > I suggest you open a github issue too. > > On Mon, Oct 1, 2018 at 10:05 AM Gaurav Ojha <gauravo...@gmail.com > <mailto:gauravo...@gmail.com>> wrote: > Basically facing two different issues. > > OpenShift Origin 3.10 keeps switching between the custom named certificate > deployed and the internal certificate being used. The web console randomly > reports Server Connection Interrupted, and then switches to the internal > certificate, but a fresh loading of the page serves the custom certificate. > Even though the publicMasterURL is configured, the browser still redirects to > the masterURL > oc v3.10.0+0c4577e-1 > kubernetes v1.10.0+b81c8f8 > features: Basic-Auth GSSAPI Kerberos SPNEGO > > Server https://lb.okd.cloud.rnoc.gatech.edu:8443 > <https://lb.okd.cloud.rnoc.gatech.edu:8443/> > openshift v3.10.0+fd501dd-48 > kubernetes v1.10.0+b81c8f8 > Steps To Reproduce > > Configure a publicMasterURL and a masterURL. In my case they are > publicMasterURL=okd-cluster.cloud.mydomain.com > <http://okd-cluster.cloud.mydomain.com/> and masterURL=lb.cloud.mydomain.com > <http://lb.cloud.mydomain.com/>. Note that here lb refers to the load > balancer of my multi-master cluster. > Deploy the certificates generated when installing through ansible. This works > fine, I can see in my master-config.yml the correct values. The value for > publicMasterURL points to okd-cluster.cloud.mydomain.com:8443 > <http://okd-cluster.cloud.mydomain.com:8443/> and masterURL to > lb.cloud.mydomain.com:8443 <http://lb.cloud.mydomain.com:8443/>. In the > servingInfo, the correct certificates are pointed to. The generated > certificate has a common name of lb.cloud.mydomain.com > <http://lb.cloud.mydomain.com/> and an alternative name of > okd-cluster.cloud.mydomain.com <http://okd-cluster.cloud.mydomain.com/>. > Access the web console. The certificate served is valid. > Here, okd-cluster.cloud.mydomain.com <http://okd-cluster.cloud.mydomain.com/> > is a CNAME to lb.cloud.mydomain.com <http://lb.cloud.mydomain.com/> > Current Result > > Even though I enter okd-cluster.cloud.mydomain.com:8443 > <http://okd-cluster.cloud.mydomain.com:8443/>, the browser redirects to > lb.cloud.mydomain.com:8443 <http://lb.cloud.mydomain.com:8443/>. I have > checked and nowhere does the publicMasterURL points to lb.cloud.mydomain.com > <http://lb.cloud.mydomain.com/> > When logged in, the console randomly throws an error saying Server Connection > Interrupted, and at times, refreshes and now reverts to the internal > certificate and serves it. This goes away if I close the browser and reload > the page. The correct certificate is again served, but again randomly reverts > to the internal certificate. > My expectation is that once deployed, accessing > okd-cluster.cloud.mydomain.com <http://okd-cluster.cloud.mydomain.com/> > should always use that address, and the certificate should be served > correctly always. > > Is it because comman name is same as the masterURL and the alternative name > holds the same value as the publicMasterURL ? I am not sure if this is the > case, but it would be great to get some retrospective on this problem I am > seeing. > > Regards > Gaurav > _______________________________________________ > users mailing list > users@lists.openshift.redhat.com <mailto:users@lists.openshift.redhat.com> > http://lists.openshift.redhat.com/openshiftmm/listinfo/users > <http://lists.openshift.redhat.com/openshiftmm/listinfo/users>
_______________________________________________ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
