Bug 1652844

Summary: Update one active silence would expire it and re-create another silence
Product: OpenShift Container Platform Reporter: Junqi Zhao <juzhao>
Component: MonitoringAssignee: Frederic Branczyk <fbranczy>
Status: CLOSED ERRATA QA Contact: Junqi Zhao <juzhao>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.1.0   
Target Milestone: ---   
Target Release: 4.1.0   
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: 2019-06-04 10:41:02 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
before update silence
none
the old silence becomes expired, and one new active silence is created after updating silence none

Description Junqi Zhao 2018-11-23 09:15:37 UTC 
Created attachment 1508235 [details]
before update silence

Description of problem:
This bug is cloned from https://jira.coreos.com/browse/MON-478
File it again for QE team to track the monitoring issue.

Update one active silence would expire it and re-create another active silence

see the attached before_update_silence.png,  there is one active KubeletTooManyPods silence, update the silence, the old silence becomes expired, and one new active silence is created. see the attached after_update_silence.png




Version-Release number of selected component (if applicable):
docker.io/grafana/grafana:5.2.4
docker.io/openshift/oauth-proxy:v1.1.0
docker.io/openshift/prometheus-alertmanager:v0.15.2
docker.io/openshift/prometheus-node-exporter:v0.16.0
docker.io/openshift/prometheus:v2.5.0
docker.io/openshift/prometheus:v2.5.0
quay.io/coreos/configmap-reload:v0.0.1
quay.io/coreos/kube-rbac-proxy:v0.4.0
quay.io/coreos/kube-state-metrics:v1.4.0
quay.io/coreos/prom-label-proxy:v0.1.0
quay.io/coreos/prometheus-config-reloader:v0.25.0
quay.io/coreos/prometheus-operator:v0.25.0
quay.io/openshift/origin-cluster-monitoring-operator:v4.0

How reproducible:
Always

Steps to Reproduce:
1. Update one active silence
2.
3.

Actual results:
The old silence becomes expired, and one new active silence is created.

Expected results:
The old silence should be updated, not becomes expired, and don't create another new active silence.

Additional info:
Comment 1 Junqi Zhao 2018-11-23 09:16:42 UTC 
Created attachment 1508238 [details]
the old silence becomes expired, and one new active silence is created after updating silence
Comment 2 Junqi Zhao 2018-11-23 09:18:50 UTC 
@Andy Pickering
Comment 3 Junqi Zhao 2018-11-26 00:34:16 UTC 
Same issue for the pending silence
Comment 4 Junqi Zhao 2018-11-26 01:36:23 UTC 
Please ignore Comment 3, no such issue for the pending silence
Comment 5 Frederic Branczyk 2018-11-26 12:56:33 UTC 
That is the correct behavior by Alertmanager, maybe we should adapt the UI a bit to make expired silences more distinct.
Comment 6 minden 2018-11-26 13:19:27 UTC 
Maybe instead of offering an "update" button, we could display an "expire & create new" button?
Comment 7 Junqi Zhao 2019-01-17 06:32:59 UTC 
Close this defect since the cloned one https://jira.coreos.com/browse/MON-478 is fixed
Comment 10 errata-xmlrpc 2019-06-04 10:41: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:0758