Bug 1806478 - ValidatingWebhookConfiguration version is not match with that in API server
Summary: ValidatingWebhookConfiguration version is not match with that in API server
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Monitoring
Version: 4.4
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: 4.5.0
Assignee: Sergiusz Urbaniak
QA Contact: Junqi Zhao
URL:
Whiteboard:
Depends On:
Blocks: 1800430
TreeView+ depends on / blocked
 
Reported: 2020-02-24 10:03 UTC by Lili Cosic
Modified: 2020-08-04 18:02 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1800430
Environment:
Last Closed: 2020-08-04 18:02:00 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:2409 0 None None None 2020-08-04 18:02:04 UTC

Description Lili Cosic 2020-02-24 10:03:43 UTC
+++ This bug was initially created as a clone of Bug #1800430 +++

Description of problem:
error "expected type *v1.ValidatingWebhookConfiguration, but watch event object had type *v1beta1.ValidatingWebhookConfiguration" in kube-state-metrics, and checked the version should be v1 
# oc -n openshift-monitoring logs kube-state-metrics-bd8f6d6cf-twnw7 -c kube-state-metrics
......
E0207 02:29:59.868343       1 reflector.go:368] k8s.io/kube-state-metrics/internal/store/builder.go:346: expected type *v1.ValidatingWebhookConfiguration, but watch event object had type *v1beta1.ValidatingWebhookConfiguration
E0207 02:29:59.910091       1 reflector.go:368] k8s.io/kube-state-metrics/internal/store/builder.go:346: expected type *v1.ValidatingWebhookConfiguration, but watch event object had type *v1beta1.ValidatingWebhookConfiguration
E0207 02:30:49.573248       1 reflector.go:368] k8s.io/kube-state-metrics/internal/store/builder.go:346: expected type *v1.ValidatingWebhookConfiguration, but watch event object had type *v1beta1.ValidatingWebhookConfiguration
........

# oc explain ValidatingWebhookConfiguration
KIND:     ValidatingWebhookConfiguration
VERSION:  admissionregistration.k8s.io/v1

DESCRIPTION:
     ValidatingWebhookConfiguration describes the configuration of and admission
     webhook that accept or reject and object without changing it.

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/sig-architecture/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/sig-architecture/api-conventions.md#types-kinds

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

   webhooks	<[]Object>
     Webhooks is a list of webhooks and the affected resources and operations.


Version-Release number of selected component (if applicable):
4.4.0-0.nightly-2020-02-06-230833

How reproducible:
always

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

--- Additional comment from Lili Cosic on 2020-02-07 11:35:33 UTC ---

Thanks for catching this! I could reproduce this in fork and upstream, will do a PR in upstream to fix it.

Comment 1 Lili Cosic 2020-02-24 11:23:16 UTC
This fix is in master, the PR -> https://github.com/openshift/kube-state-metrics/pull/25


@junqi I noticed some other problems in the logs, can you verify this bug and possibly open bugzillas for anything else you find. Feel free to do it in one bugzilla, will fix all together. Thanks!

Comment 2 Junqi Zhao 2020-02-24 11:44:04 UTC
(In reply to Lili Cosic from comment #1)
> This fix is in master, the PR ->
> https://github.com/openshift/kube-state-metrics/pull/25
> 
> 
> @junqi I noticed some other problems in the logs, can you verify this bug
> and possibly open bugzillas for anything else you find. Feel free to do it
> in one bugzilla, will fix all together. Thanks!

no available OCP 4.5 build now, postpone the verification

Comment 3 Junqi Zhao 2020-02-28 09:55:56 UTC
Tested with 4.5.0-0.ci-2020-02-28-043432, no error in the logs
# oc -n openshift-monitoring logs kube-state-metrics-688ff64c7-2br6b -c kube-state-metrics
I0228 08:19:28.466385       1 main.go:86] Using default collectors
I0228 08:19:28.466513       1 main.go:98] Using all namespace
I0228 08:19:28.466536       1 main.go:139] metric white-blacklisting: blacklisting the following items: kube_secret_labels
W0228 08:19:28.466552       1 client_config.go:543] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
I0228 08:19:28.469016       1 main.go:186] Testing communication with server
I0228 08:19:28.479491       1 main.go:191] Running with Kubernetes cluster version: v1.17+. git version: v1.17.1. git tree state: clean. commit: 0ef478f. platform: linux/amd64
I0228 08:19:28.479517       1 main.go:193] Communication with server successful
I0228 08:19:28.479653       1 main.go:227] Starting metrics server: 127.0.0.1:8081
I0228 08:19:28.479914       1 metrics_handler.go:96] Autosharding disabled
I0228 08:19:28.481028       1 main.go:202] Starting kube-state-metrics self metrics server: 127.0.0.1:8082
I0228 08:19:28.482325       1 builder.go:156] Active collectors: certificatesigningrequests,configmaps,cronjobs,daemonsets,deployments,endpoints,horizontalpodautoscalers,ingresses,jobs,limitranges,mutatingwebhookconfigurations,namespaces,networkpolicies,nodes,persistentvolumeclaims,persistentvolumes,poddisruptionbudgets,pods,replicasets,replicationcontrollers,resourcequotas,secrets,services,statefulsets,storageclasses,validatingwebhookconfigurations,volumeattachments

Comment 6 errata-xmlrpc 2020-08-04 18:02:00 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 (OpenShift Container Platform 4.5 image release 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-2020:2409


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