Details
-
Page
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
16: Autoscaling/PE/Docs
-
1
Description
From the values.yaml for Helm we have the following:
# TLS Certs that will be used to encrypt traffic between operator and couchbase
|
tls:
|
# enable to auto create certs
|
generate: false
|
# Expiry time of CA in days for generated certs
|
expiration: 365
|
|
We need to explain this bit better, when customer set this to true, the Operator will actually go through the process of creating the certs (https://docs.couchbase.com/operator/current/tutorial-tls.html#creating-a-client-certificate) and then create and config the secrets (https://docs.couchbase.com/operator/current/howto-tls.html) for the cluster.
This causes an issue with upgrade as noted in https://issues.couchbase.com/browse/K8S-1900 because with Operator 2.1 requires an extra SAN
```
DNS:host.${cluster}.${namespace}.svc.cluster.local
```
Without this, when upgrading the Operator will report this error:
{"level":"error","ts":1611102051.5212724,"logger":"cluster","msg":"Reconciliation failed","cluster":"default/demo","error":"certificate cannot be verified for zone: x509: certificate is valid for localhost, *.demo-couchbase-cluster.default.svc, *.demo-couchbase-cluster.default, *.demo-couchbase-cluster, *.demo-couchbase-cluster-srv.default.svc, *.demo-couchbase-cluster-srv.default, *.demo-couchbase-cluster-srv, demo-couchbase-cluster-srv.default.svc, demo-couchbase-cluster-srv.default, demo-couchbase-cluster-srv, *.demo-couchbase-cluster-srv.default.svc.cluster.local, host.demo-couchbase-cluster.default.svc.cluster.local, not host.demo
|
We need to document the workaround, which is to regenerate the secrets using the values.yaml with the 2.1 chart
```
helm template demo --values values.yaml couchbase/couchbase-operator > secretsdemo.yaml
```
Then replace the secrets, after this we can then proceed to upgrade the Operator.
Draft Documentation
- Added Auto-Generated Certificates section that describes the workaround in
K8S-1900/K8S-1955.
Attachments
Issue Links
Activity
Field | Original Value | New Value |
---|---|---|
Description |
From the values.yaml for Helm we have the following:
# TLS Certs that will be used to encrypt traffic between operator and couchbase tls: # enable to auto create certs generate: false # Expiry time of CA in days for generated certs expiration: 365 We need to explain this bit better, when customer set this to true, the Operator will actually go through the process of creating the certs (https://docs.couchbase.com/operator/current/tutorial-tls.html#creating-a-client-certificate) and then create and config the secrets (https://docs.couchbase.com/operator/current/howto-tls.html) for the cluster. This causes an issue with upgrade as noted in https://issues.couchbase.com/browse/K8S-1900 because with Operator 2.1 requires an extra SAN ``` DNS:host.${cluster}.${namespace}.svc.cluster.local ``` Without this, when upgrading the Operator will report this error: {noformat} {"level":"error","ts":1611102051.5212724,"logger":"cluster","msg":"Reconciliation failed","cluster":"default/demo","error":"certificate cannot be verified for zone: x509: certificate is valid for localhost, *.demo-couchbase-cluster.default.svc, *.demo-couchbase-cluster.default, *.demo-couchbase-cluster, *.demo-couchbase-cluster-srv.default.svc, *.demo-couchbase-cluster-srv.default, *.demo-couchbase-cluster-srv, demo-couchbase-cluster-srv.default.svc, demo-couchbase-cluster-srv.default, demo-couchbase-cluster-srv, *.demo-couchbase-cluster-srv.default.svc.cluster.local, host.demo-couchbase-cluster.default.svc.cluster.local, not host.demo {noformat} We need to document the workaround, which is to regenerate the secrets using the values.yaml with the 2.1 chart ``` helm template demo --values values.yaml couchbase/couchbase-operator > secretsdemo.yaml ``` Then replace the secrets, after this we can then proceed to upgrade the Operator. |
From the values.yaml for Helm we have the following:
{noformat} # TLS Certs that will be used to encrypt traffic between operator and couchbase tls: # enable to auto create certs generate: false # Expiry time of CA in days for generated certs expiration: 365 {noformat} We need to explain this bit better, when customer set this to true, the Operator will actually go through the process of creating the certs (https://docs.couchbase.com/operator/current/tutorial-tls.html#creating-a-client-certificate) and then create and config the secrets (https://docs.couchbase.com/operator/current/howto-tls.html) for the cluster. This causes an issue with upgrade as noted in https://issues.couchbase.com/browse/K8S-1900 because with Operator 2.1 requires an extra SAN ``` DNS:host.${cluster}.${namespace}.svc.cluster.local ``` Without this, when upgrading the Operator will report this error: {noformat} {"level":"error","ts":1611102051.5212724,"logger":"cluster","msg":"Reconciliation failed","cluster":"default/demo","error":"certificate cannot be verified for zone: x509: certificate is valid for localhost, *.demo-couchbase-cluster.default.svc, *.demo-couchbase-cluster.default, *.demo-couchbase-cluster, *.demo-couchbase-cluster-srv.default.svc, *.demo-couchbase-cluster-srv.default, *.demo-couchbase-cluster-srv, demo-couchbase-cluster-srv.default.svc, demo-couchbase-cluster-srv.default, demo-couchbase-cluster-srv, *.demo-couchbase-cluster-srv.default.svc.cluster.local, host.demo-couchbase-cluster.default.svc.cluster.local, not host.demo {noformat} We need to document the workaround, which is to regenerate the secrets using the values.yaml with the 2.1 chart ``` helm template demo --values values.yaml couchbase/couchbase-operator > secretsdemo.yaml ``` Then replace the secrets, after this we can then proceed to upgrade the Operator. |
Rank | Ranked higher |
Rank | Ranked higher |
Component/s | helm [ 15332 ] | |
Assignee | Simon Murray [ simon.murray ] | Tommie McAfee [ tommie ] |
Labels | candidate-for-cao-2.2 |
Fix Version/s | 2.2.0 [ 17035 ] | |
Labels | candidate-for-cao-2.2 |
Rank | Ranked higher |
Sprint | 16: Documentation [ 1503 ] |
Rank | Ranked higher |
Assignee | Tommie McAfee [ tommie ] | Patrick Stephens [ JIRAUSER25332 ] |
Status | Open [ 1 ] | In Progress [ 3 ] |
Resolution | Fixed [ 1 ] | |
Status | In Progress [ 3 ] | Resolved [ 5 ] |
Assignee | Patrick Stephens [ JIRAUSER25332 ] | Arunkumar Senthilnathan [ arunkumar ] |
Description |
From the values.yaml for Helm we have the following:
{noformat} # TLS Certs that will be used to encrypt traffic between operator and couchbase tls: # enable to auto create certs generate: false # Expiry time of CA in days for generated certs expiration: 365 {noformat} We need to explain this bit better, when customer set this to true, the Operator will actually go through the process of creating the certs (https://docs.couchbase.com/operator/current/tutorial-tls.html#creating-a-client-certificate) and then create and config the secrets (https://docs.couchbase.com/operator/current/howto-tls.html) for the cluster. This causes an issue with upgrade as noted in https://issues.couchbase.com/browse/K8S-1900 because with Operator 2.1 requires an extra SAN ``` DNS:host.${cluster}.${namespace}.svc.cluster.local ``` Without this, when upgrading the Operator will report this error: {noformat} {"level":"error","ts":1611102051.5212724,"logger":"cluster","msg":"Reconciliation failed","cluster":"default/demo","error":"certificate cannot be verified for zone: x509: certificate is valid for localhost, *.demo-couchbase-cluster.default.svc, *.demo-couchbase-cluster.default, *.demo-couchbase-cluster, *.demo-couchbase-cluster-srv.default.svc, *.demo-couchbase-cluster-srv.default, *.demo-couchbase-cluster-srv, demo-couchbase-cluster-srv.default.svc, demo-couchbase-cluster-srv.default, demo-couchbase-cluster-srv, *.demo-couchbase-cluster-srv.default.svc.cluster.local, host.demo-couchbase-cluster.default.svc.cluster.local, not host.demo {noformat} We need to document the workaround, which is to regenerate the secrets using the values.yaml with the 2.1 chart ``` helm template demo --values values.yaml couchbase/couchbase-operator > secretsdemo.yaml ``` Then replace the secrets, after this we can then proceed to upgrade the Operator. |
From the values.yaml for Helm we have the following:
{noformat} # TLS Certs that will be used to encrypt traffic between operator and couchbase tls: # enable to auto create certs generate: false # Expiry time of CA in days for generated certs expiration: 365 {noformat} We need to explain this bit better, when customer set this to true, the Operator will actually go through the process of creating the certs ([https://docs.couchbase.com/operator/current/tutorial-tls.html#creating-a-client-certificate]) and then create and config the secrets ([https://docs.couchbase.com/operator/current/howto-tls.html]) for the cluster. This causes an issue with upgrade as noted in https://issues.couchbase.com/browse/K8S-1900 because with Operator 2.1 requires an extra SAN ``` DNS:host.${cluster}.${namespace}.svc.cluster.local ``` Without this, when upgrading the Operator will report this error: {noformat}{"level":"error","ts":1611102051.5212724,"logger":"cluster","msg":"Reconciliation failed","cluster":"default/demo","error":"certificate cannot be verified for zone: x509: certificate is valid for localhost, *.demo-couchbase-cluster.default.svc, *.demo-couchbase-cluster.default, *.demo-couchbase-cluster, *.demo-couchbase-cluster-srv.default.svc, *.demo-couchbase-cluster-srv.default, *.demo-couchbase-cluster-srv, demo-couchbase-cluster-srv.default.svc, demo-couchbase-cluster-srv.default, demo-couchbase-cluster-srv, *.demo-couchbase-cluster-srv.default.svc.cluster.local, host.demo-couchbase-cluster.default.svc.cluster.local, not host.demo {noformat} We need to document the workaround, which is to regenerate the secrets using the values.yaml with the 2.1 chart ``` helm template demo --values values.yaml couchbase/couchbase-operator > secretsdemo.yaml ``` Then replace the secrets, after this we can then proceed to upgrade the Operator. h1. Draft Documentation [*Manage. Helm.* *_Helm Deployment_*|https://docs-staging.couchbase.com/operator/current/helm-setup-guide.html] * Added [Auto-Generated Certificates|https://docs-staging.couchbase.com/operator/current/helm-setup-guide.html#auto-generated-certificates] section that describes the workaround in |
Remote Link | This issue links to "Page (Couchbase, Inc. Wiki)" [ 22103 ] |
Status | Resolved [ 5 ] | Closed [ 6 ] |
Remote Link | This issue links to "Page (Couchbase, Inc. Wiki)" [ 22706 ] |
Remote Link | This issue links to "Page (Couchbase, Inc. Wiki)" [ 22103 ] |