Bug 1738432 - Generic operator client blocks removing fields from observed config
Summary: Generic operator client blocks removing fields from observed config
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: kube-apiserver
Version: 4.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: 4.2.0
Assignee: Stefan Schimanski
QA Contact: Xingxing Xia
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-08-07 07:22 UTC by Standa Laznicka
Modified: 2019-10-16 06:35 UTC (History)
5 users (show)

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


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift cluster-kube-apiserver-operator pull 549 0 'None' 'closed' 'Bug 1738432: bump to include fix for generic client fields not being removed' 2019-12-05 10:44:01 UTC
Github openshift library-go pull 505 0 'None' 'closed' 'Bug 1738432: genericoperatorclient: only preserve fields outside of Operator{Spec,Status}' 2019-12-05 10:44:01 UTC
Red Hat Product Errata RHBA-2019:2922 0 None None None 2019-10-16 06:35:27 UTC

Description Standa Laznicka 2019-08-07 07:22:30 UTC
Description of problem:
When a source of information of an observed configuration for OpenShift/Kube-APIServer is removed, the respective field in `observedConfig` is kept and the logs and events of an operator which handles observing the configuration are flooded with messages containing diffs of the `observedConfiguration` field as the observer tries to update the resource over and over again. The actual update never happens though, as right before the API Update call the new object is merged with its old version (https://github.com/openshift/library-go/blob/master/pkg/operator/genericoperatorclient/dynamic_operator_client.go#L77), that causes the removed field to reappear.


Version-Release number of selected component (if applicable):
master

How reproducible:
always

Steps to Reproduce:
1. oc edit image.config
>> add the following to spec:
```
  allowedRegistriesForImport:
  - domainName: private-registry.corp.com
```
2. wait for the change to appear in the observedConfig field in kubeapiserver.operator
3. remove the configured field from image.config

Actual results:
The information in observedConfig field is kept and the log of kube-apiserver-operator deployment are filled with messages about the operator trying to change its config object.

Expected results:
The respective field in kubeapiserver.config object is removed.

Comment 1 Standa Laznicka 2019-08-07 07:30:52 UTC
The object in "Expected results" should be kubeapiserver.operator, ofc

Comment 2 Mike Dame 2019-08-08 16:52:53 UTC
This is part of the same issue we're also seeing in https://bugzilla.redhat.com/show_bug.cgi?id=1736795

Comment 4 Mike Dame 2019-08-13 17:54:59 UTC
This will need to be bumped into the operator to actually be verified. Bump PR here: https://github.com/openshift/cluster-kube-apiserver-operator/pull/549

Also setting to ASSIGNED so that the proper BZ label can be applied to the PR

Comment 6 zhou ying 2019-08-19 05:46:34 UTC
Confirmed with payload: 4.2.0-0.nightly-2019-08-18-222019, the issue has fixed:

Before remove:
[root@dhcp-140-138 ~]# oc get kubeapiservers.operator.openshift.io -o yaml 
apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: KubeAPIServer
  metadata:
....
  spec:
.....
      imagePolicyConfig:
        allowedRegistriesForImport:
        - domainName: private-registry.corp.com
        internalRegistryHostname: xxxx
      servicesSubnet: 172.30.0.0/16



After remove:
[root@dhcp-140-138 ~]# oc get kubeapiservers.operator.openshift.io -o yaml 
apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: KubeAPIServer
  metadata:
....
  spec:
    logLevel: ""
    managementState: Managed
    observedConfig:
....
      imagePolicyConfig:
        internalRegistryHostname: xxxx
      servicesSubnet: 172.30.0.0/16

Comment 7 errata-xmlrpc 2019-10-16 06:35:02 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.