Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1633371

Summary: [starter-ca-central-1] endpoints failing to update for cluster-monitoring-operator
Product: OpenShift Container Platform Reporter: Justin Pierce <jupierce>
Component: MasterAssignee: Michal Fojtik <mfojtik>
Status: CLOSED NOTABUG QA Contact: Xingxing Xia <xxia>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.11.0CC: aos-bugs, jokerman, mmccomas
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-09-27 15:33:55 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
endpoint is not being updated none

Description Justin Pierce 2018-09-26 19:55:47 UTC
Created attachment 1487456 [details]
endpoint is not being updated

Description of problem:
Endpoint failing to update. Running pod cluster-monitoring-operator-xyz should be selected by service, but it is not ultimately receiving an endpoint entry.
See listings for more detail.

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

Additional information:
- Deleted endpoint
- Added random label to service/cluster-monitoring-operator to force an update
- Endpoint was recreated, but still no IP
- Restarting controllers had no effect
- Deleting the pod did not fix the issue (new pod started, but endpoint was not updated)
- Completely deleting and recreating the service did not fix the endpoint

Comment 2 Justin Pierce 2018-09-27 15:33:55 UTC
maszulik pointed me to: https://kubernetes.io/docs/concepts/services-networking/service/#headless-services

which explains that if ClusterIP is not set on the service, the endpoint IP must be setup manually. That explains the observations and means that the problem exists with the monitoring playbooks which setup this endpoint.