Bug 1975460

Summary: VMware console shows errors and also machines shows updated status in OCP webconsole
Product: OpenShift Container Platform Reporter: Ankita Kanekar <akanekar>
Component: Cloud ComputeAssignee: Michael McCune <mimccune>
Cloud Compute sub component: Other Providers QA Contact: sunzhaohua <zhsun>
Status: CLOSED NOTABUG Docs Contact:
Severity: low    
Priority: low CC: mimccune
Version: 4.7   
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
VMware vSphere OCP 4.6
Last Closed: 2021-06-30 19:11:49 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
screenshots none

Description Ankita Kanekar 2021-06-23 17:55:23 UTC 
Created attachment 1793576 [details]
screenshots

Description of problem:

1. OCP console shows events for machines as "Generated from vpshrecontroller"
2. VMware console shows events for VM being reconfigured.
3. Logs in machine-api controller shows reconciliation as :


2021-06-14T09:54:12.193016946Z I0614 09:54:12.192996       1 reconciler.go:275] ocp37hpd1-vx8fq-master-1: reconciling powerstate annotation
2021-06-14T09:54:12.195245707Z I0614 09:54:12.195215       1 reconciler.go:721] ocp37hpd1-vx8fq-master-1: Updating provider status
2021-06-14T09:54:12.199403958Z I0614 09:54:12.199372       1 machine_scope.go:102] ocp37hpd1-vx8fq-master-1: patching machine
2021-06-14T09:54:12.215632629Z I0614 09:54:12.215589       1 controller.go:170] ocp37hpd1-vx8fq-worker-bs9vb: reconciling Machine
2021-06-14T09:54:12.215632629Z I0614 09:54:12.215613       1 actuator.go:109] ocp37hpd1-vx8fq-worker-bs9vb: actuator checking if machine exists
2021-06-14T09:54:12.286714505Z I0614 09:54:12.285960       1 session.go:113] Find template by instance uuid: babe7508-8a91-4e8a-8bfc-0ebcd59a2832
2021-06-14T09:54:12.288169737Z I0614 09:54:12.288145       1 reconciler.go:179] ocp37hpd1-vx8fq-worker-bs9vb: already exists
2021-06-14T09:54:12.288169737Z I0614 09:54:12.288162       1 controller.go:278] ocp37hpd1-vx8fq-worker-bs9vb: reconciling machine triggers idempotent update

Version-Release number of selected component (if applicable):
OCP version: 4.6.22
VMware version, unknown

How reproducible:
NA

Steps to Reproduce:
1.
2.
3.

Actual results:
Machine keeps showing events frequently.

Expected results:
Machines should not show such alarms

Additional info:

Must gather for cluster can be found at:
https://drive.google.com/file/d/1x06deXxBeqIG1YuSgjkwDIXM_LJy2OOy/view?usp=sharing

Also, screenshot for VMware and OCP GUI are attached.
Comment 1 Michael McCune 2021-06-23 18:52:32 UTC 
@akanekar i'm curious to understand this better, is the issue here that the machine-api controller is sending events for each reconfigure that happens in vSphere, and that we should be parsing out those reconfiguration events?
Comment 3 Michael McCune 2021-06-24 20:34:22 UTC 
thanks for the update Ankita,

i have a feeling we could improve this at the machine-api controller level, but i am concerned that we will become more dependent on the specific message texts that are coming from the vSphere events. i also think it might be tough for us to know which events a user will want to see versus which one they don't.

i think this is a good request to bring before our cloud infrastructure team, but i am going to drop the severity/priority since this is not affecting functionality and is more a user experience issue.
Comment 4 Michael McCune 2021-06-30 19:11:49 UTC 
Ankita,

i have spoken with the team about this issue and we feel that this behavior is working as it is intended. the controller should read all updates from the vCenter and display them as logs/events. this may be causing excessive noise in the events console, but this behavior has existed in OpenShift for some time now.

we also discussed the idea of parsing those messages from the vCenter to see if we could remove them from the logs/events in OpenShift by analysing the contents of the messages. but, this would mean that we would need to know more detail about the messages coming from vCenter and would make us the arbitrator of which messages get relayed. the team felt that we should not be making decisions about which messages the user sees from the vCenter. in situations where a user only had access to the OpenShift events and could not access the vCenter, they would need to have this information from OpenShift.

i hope this helps to clear up the issue, i am going to mark this as closed/notabug. if you feel that this is incorrect, then i think it would be appropriate to make a feature request for the changes.