Bug 1683055 - service-ca operator config needs validation
Summary: service-ca operator config needs validation
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: apiserver-auth
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
: 4.2.0
Assignee: Sally
QA Contact: Wei Sun
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-02-26 07:54 UTC by Chuan Yu
Modified: 2019-10-16 06:27 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-16 06:27:41 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift service-ca-operator pull 64 0 None None None 2019-07-16 20:59:55 UTC
Red Hat Product Errata RHBA-2019:2922 0 None None None 2019-10-16 06:27:49 UTC

Description Chuan Yu 2019-02-26 07:54:26 UTC
Per: https://jira.coreos.com/browse/AUTH-211

Comment 3 Chuan Yu 2019-03-21 07:07:15 UTC
In the nightly build 4.0.0-0.nightly-2019-03-20-153904, the service-ca-operator still use the payload build in 201903141706, not included this PR.

Comment 4 Chuan Yu 2019-03-22 06:19:02 UTC
The issue still not fixed, leave comment in the Jira.

Comment 6 Sally 2019-04-01 21:29:20 UTC
The lack of comments in openshift/api/config/v1/types_cluster_operator.go  and lack of openshift/api/config/v1/types_servica.go results in the lack of description for serviceca clusteroperator.  The description comes directly from comments in the openshift/api/config/v1/types_*.go files.  Checking to see if this is a bug or can close.

Comment 7 Sally 2019-04-01 22:23:36 UTC
Service CA does not have anything to configure, so it needs no top level config (like these do: https://github.com/openshift/api/tree/master/config/v1) Opened this to get the nice descriptions: https://github.com/openshift/api/pull/276

Comment 11 Sally 2019-04-23 21:27:51 UTC
`oc explain` is functional again, but the PR above did not fix.  I've opened this: https://github.com/openshift/api/pull/296 I believe that will finally make the description comments appear.

Comment 12 Wei Sun 2019-04-29 08:54:09 UTC
The PR has been merged since 5 days ago,so move this bug to ON_QA for checking.

Comment 13 Chuan Yu 2019-04-30 06:54:52 UTC
Check with build 4.1.0-0.nightly-2019-04-28-064010, the issue still not fixed.

Comment 14 Sally 2019-05-01 17:49:31 UTC
Now that `oc explain` is working and I've checked all other clusteroperators, I see that any CO w/out a corresponding openshift/api/config/v1 type will return similar `oc explain` output:

try:
oc explain servicecatalogcontrollermanager
oc explain servicecatalogapiserver
oc explain openshiftapiserver
oc explain kubecontrollermanager
oc explain kubeapiserver

They all return no descriptions for spec/status, while anything that has a top-level config will return the nice descriptions.
(ingress, dns, authentication) 

Nothing is broken with this, not sure it's a bug, moving to 4.2 for now.

Comment 16 Sally 2019-06-17 13:35:30 UTC

*** This bug has been marked as a duplicate of bug 1712317 ***

Comment 17 Xingxing Xia 2019-07-16 02:40:13 UTC
This bug should be kept to track the issue instead of closed as DUP per bug 1712317#c16

Comment 20 Sally 2019-08-01 19:03:39 UTC
Please retry, the PR just merged, maybe wasn't in the nightly? Thanks!

I got this from cluster with 'Cluster version is 4.2.0-0.ci-2019-08-01-113614':

$ oc explain serviceca
KIND:     ServiceCA
VERSION:  operator.openshift.io/v1

DESCRIPTION:
     ServiceCA provides information to configure an operator to manage the
     service cert controllers

FIELDS:
   apiVersion	<string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/api-conventions.md#resources

   kind	<string>
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelCase. More info:
     https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds

   metadata	<Object>
     Standard object's metadata. More info:
     https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata

   spec	<Object> -required-
     spec holds user settable values for configuration

   status	<Object>
     status holds observed values from the cluster. They may not be overridden.

Comment 21 Chuan Yu 2019-08-07 00:42:15 UTC
Verified on 4.2.0-0.nightly-2019-08-06-072822

Comment 24 errata-xmlrpc 2019-10-16 06:27:41 UTC
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


Note You need to log in before you can comment on or make changes to this bug.