Re: OKD 3.10 keeps switching between the certificates

2018-10-01 Thread Gaurav Ojha 
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  wrote:
> 
> I suggest you open a github issue too.
> 
> On Mon, Oct 1, 2018 at 10:05 AM Gaurav Ojha  > 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 
> 
> 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 
>  and masterURL=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 
>  and masterURL to 
> 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 
>  and an alternative name of 
> okd-cluster.cloud.mydomain.com .
> Access the web console. The certificate served is valid.
> Here, okd-cluster.cloud.mydomain.com  
> is a CNAME to lb.cloud.mydomain.com 
> Current Result
> 
> Even though I enter okd-cluster.cloud.mydomain.com:8443 
> , the browser redirects to 
> lb.cloud.mydomain.com:8443 . I have 
> checked and nowhere does the publicMasterURL points to 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  
> 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 
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users 
> 

___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Re: OKD 3.10 keeps switching between the certificates

2018-10-01 Thread Daniel Comnea 
I suggest you open a github issue too.

On Mon, Oct 1, 2018 at 10:05 AM Gaurav Ojha  wrote:

> Basically facing two different issues.
>
>1. 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.
>2. 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
> openshift v3.10.0+fd501dd-48
> kubernetes v1.10.0+b81c8f8
>
> Steps To Reproduce
>
>1. Configure a publicMasterURL and a masterURL. In my case they are
>publicMasterURL=okd-cluster.cloud.mydomain.com and masterURL=
>lb.cloud.mydomain.com. Note that here lb refers to the load balancer
>of my multi-master cluster.
>2. 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
>and masterURL to 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 and an alternative name of
>okd-cluster.cloud.mydomain.com.
>3. Access the web console. The certificate served is valid.
>
> Here, okd-cluster.cloud.mydomain.com is a CNAME to lb.cloud.mydomain.com
> Current Result
>
>1. Even though I enter okd-cluster.cloud.mydomain.com:8443, the
>browser redirects to lb.cloud.mydomain.com:8443. I have checked and
>nowhere does the publicMasterURL points to lb.cloud.mydomain.com
>2. 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 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
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

OKD 3.10 keeps switching between the certificates

2018-10-01 Thread Gaurav Ojha 
Basically facing two different issues.

   1. 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.
   2. 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
openshift v3.10.0+fd501dd-48
kubernetes v1.10.0+b81c8f8

Steps To Reproduce

   1. Configure a publicMasterURL and a masterURL. In my case they are
   publicMasterURL=okd-cluster.cloud.mydomain.com and masterURL=
   lb.cloud.mydomain.com. Note that here lb refers to the load balancer of
   my multi-master cluster.
   2. 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
   and masterURL to 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 and an alternative name of
   okd-cluster.cloud.mydomain.com.
   3. Access the web console. The certificate served is valid.

Here, okd-cluster.cloud.mydomain.com is a CNAME to lb.cloud.mydomain.com
Current Result

   1. Even though I enter okd-cluster.cloud.mydomain.com:8443, the browser
   redirects to lb.cloud.mydomain.com:8443. I have checked and nowhere does
   the publicMasterURL points to lb.cloud.mydomain.com
   2. 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 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
http://lists.openshift.redhat.com/openshiftmm/listinfo/users