Description of problem: `oc explain apiserver.spec.servingCerts` still explains defaultServingCertificate. Per the PRs [1] of https://bugzilla.redhat.com/show_bug.cgi?id=1728754 , the struct removed it. So oc explain should not show it either. [1] See https://github.com/openshift/api/pull/375/files Version-Release number of selected component (if applicable): 4.1.0-0.nightly-2019-07-18-023612 How reproducible: Always Steps to Reproduce: 1. oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.1.0-0.nightly-2019-07-18-023612 True False 5h55m Cluster version is 4.1.0-0.nightly-2019-07-18-023612 2. oc explain apiserver.spec.servingCerts oc explain apiserver.spec.servingCerts.defaultServingCertificate KIND: APIServer VERSION: config.openshift.io/v1 RESOURCE: defaultServingCertificate <Object> DESCRIPTION: defaultServingCertificate references a kubernetes.io/tls type secret containing the default TLS cert info for serving secure traffic. If no named certificates match the server name as understood by a client, this default certificate will be used. If defaultServingCertificate is not specified, then a operator managed certificate will be used. The secret must exist in the openshift-config namespace and contain the following required fields: - Secret.Data["tls.key"] - TLS private key. - Secret.Data["tls.crt"] - TLS certificate. FIELDS: name <string> name is the metadata.name of the referenced secret Actual results: 2. The commands still show defaultServingCertificate Expected results: 2. Should not show. Additional info:
Tested in 4.2.0-0.okd-2019-07-22-195548 and this seems to be fixed, do we want to backport to 4.1.z as well? I believe this was fixed in https://github.com/openshift/cluster-config-operator/pull/70/commits/5619a4030da17bb26b88253ed4fdf8903500d5ff#diff-0564744bb4a0a4f26e8a117917c9273eL66
PR to backport: https://github.com/openshift/cluster-config-operator/pull/75
Verified in 4.2.0-0.nightly-2019-07-24-000310 env. Issue fixed. (In reply to Mike Dame from comment #1) > do we want to backport to 4.1.z as well? It is fine to do that. Will check again once 4.1 PR merged. Thank you :)
Bugs should be first fixed in 4.2. This bug should be cloned and the cloned bug should have target release 4.1.z.
Cloned here: https://bugzilla.redhat.com/show_bug.cgi?id=1732934
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://access.redhat.com/errata/RHBA-2019:2922