Bug 1820230 - Changes in node-exporter daemonset are persistent and does not get revert back to default configuration
Summary: Changes in node-exporter daemonset are persistent and does not get revert bac...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Monitoring
Version: 3.11.0
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
: 3.11.z
Assignee: Simon Pasquier
QA Contact: Junqi Zhao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-04-02 14:45 UTC by Aditya Deshpande
Modified: 2023-09-07 22:40 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-10 12:13:54 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 4980631 0 None None None 2020-04-10 14:24:56 UTC

Description Aditya Deshpande 2020-04-02 14:45:06 UTC
Description of problem:

In OCP 3.11, one of the customer is following the procedure as mentioned below to edit the daemonset of node-exporter in openshift-monitoring project and deleted one cipher-suite value. 

# oc edit ds node-exporter

deleted value from tls-cipher-suites arguent mentioned in kube-rbac-proxy container.
~~~
- --tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
~~~

Here, you can see the value TLS_RSA_WITH_AES_128_CBC_SHA256 is deleted.

After deletion and saving the changes, node-exporter pods were rolled out out with that configuration.

As observed, the node-exporter daemonset never changed and reconsiling to the default configuration never happened and the change made to daemonset is persistent which is strange.


Version-Release number of selected component (if applicable):
v3.11.170

Actual results:

Changes done in node-exporter daemonset becomes persistent which should not be the case.

Expected results:
Operator should revert back the default configuration of daemonset and the value which was deleted should reappear.

Additional info:
- Tried deleting the node-exporter daemonset and waited if the daemonset creates automatically but it did not get created automatically and brought up by `# oc create -f ds.yaml` from backup of daemonset yaml file which was taken.
- Attaching cluster-monitoring-operator pod logs while this activity happened.


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