Port 1-092_validate_workload_status_monitoring_alert-test to Ginkgo#1065
Conversation
|
/retest |
trdoyle81
force-pushed
the
GITOPS-7204-Port-1-092_validate_workload_status_monitoring_alert
branch
from
4259324 to
d1c9864
Compare
|
/retest |
|
/retest-required |
trdoyle81
force-pushed
the
GITOPS-7204-Port-1-092_validate_workload_status_monitoring_alert
branch
2 times, most recently
from
331f5e4 to
ae55337
Compare
|
/test v4.19-kuttl-sequential |
trdoyle81
force-pushed
the
GITOPS-7204-Port-1-092_validate_workload_status_monitoring_alert
branch
from
ae55337 to
a724573
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
trdoyle81
force-pushed
the
GITOPS-7204-Port-1-092_validate_workload_status_monitoring_alert
branch
from
a724573 to
45a510d
Compare
trdoyle81
force-pushed
the
GITOPS-7204-Port-1-092_validate_workload_status_monitoring_alert
branch
2 times, most recently
from
bd779a0 to
2722a2e
Compare
trdoyle81
force-pushed
the
GITOPS-7204-Port-1-092_validate_workload_status_monitoring_alert
branch
from
2722a2e to
48bad9c
Compare
test/openshift/e2e/ginkgo/sequential/1-092_validate_workload_status_monitoring_alert.go
Outdated
Show resolved
Hide resolved
test/openshift/e2e/ginkgo/sequential/1-092_validate_workload_status_monitoring_alert.go
Outdated
Show resolved
Hide resolved
trdoyle81
force-pushed
the
GITOPS-7204-Port-1-092_validate_workload_status_monitoring_alert
branch
from
48bad9c to
db1b776
Compare
|
/retest |
trdoyle81
force-pushed
the
GITOPS-7204-Port-1-092_validate_workload_status_monitoring_alert
branch
from
72233c8 to
1abd2ab
Compare
Signed-off-by: Triona Doyle <bot@example.com>
Signed-off-by: Triona Doyle <bot@example.com>
Signed-off-by: Triona Doyle <bot@example.com>
Signed-off-by: Triona Doyle <bot@example.com>
trdoyle81
force-pushed
the
GITOPS-7204-Port-1-092_validate_workload_status_monitoring_alert
branch
from
1abd2ab to
68de5ed
Compare
| err = k8sClient.Get(ctx, client.ObjectKeyFromObject(uwmConfigMap), existingCM) | ||
|
|
||
| DeferCleanup(func() { | ||
| _ = k8sClient.Delete(ctx, uwmConfigMap) |
There was a problem hiding this comment.
@trdoyle81 uwmConfigMap is something that already exists on the cluster right? Should we just revert the changes that was made instead of deleting it?
Maybe we can move the function below where the creation takes place? That way we can either revert the changes or delete the configmap it was created using the test step
|
|
||
| argocdFixture.Update(argoCDCluster, func(ac *argov1beta1api.ArgoCD) { | ||
| ac.Spec.ApplicationSet = &argov1beta1api.ArgoCDApplicationSet{Image: invalidImage} | ||
| ac.Spec.Monitoring = argov1beta1api.ArgoCDMonitoringSpec{Enabled: true, DisableMetrics: ptr.To(false)} |
There was a problem hiding this comment.
Do we need to set DisableMetrics?
| ac.Spec.Monitoring.DisableMetrics = ptr.To(true) | ||
| }) | ||
|
|
||
| Expect(k8sClient.Get(ctx, client.ObjectKeyFromObject(argoCDNamespaced), argoCDNamespaced)).To(Succeed()) |
There was a problem hiding this comment.
This is not needed IMO as we are going to delete this anyway
| ac.Spec.Monitoring.DisableMetrics = ptr.To(true) | ||
| }) | ||
|
|
||
| By("deleting cluster monitoring config") |
| ruleNamespaced := &monitoringv1.PrometheusRule{ | ||
| ObjectMeta: metav1.ObjectMeta{Name: prometheusRuleName, Namespace: nsNamespaced.Name}, | ||
| } | ||
| appSetDeplCluster := &appsv1.Deployment{ |
There was a problem hiding this comment.
This doesn't seem to be required as we are checking the appset directly
| Eventually(ruleNamespaced, "3m", "5s").Should(k8sFixture.ExistByName(), "PrometheusRule should be created in test namespace") | ||
|
|
||
| By("verifying the ApplicationSet deployments are present") | ||
| Eventually(appSetDeplCluster).Should(k8sFixture.ExistByName()) |
There was a problem hiding this comment.
We will need to add one for the namespace scoped appset pod as well
|
|
||
| By("verifying the workload degradation alerts are actively firing in Prometheus") | ||
| Eventually(func() bool { | ||
| cmd := exec.Command("oc", "exec", "-n", "openshift-monitoring", "prometheus-k8s-0", "-c", "prometheus", "--", "curl", "-s", "http://localhost:9090/api/v1/alerts") |
There was a problem hiding this comment.
Is there a way to parse is via jq or some other tool as discussed?
2 participants
What type of PR is this?
What does this PR do / why we need it:
Port the Kuttl test 1-092_validate_workload_status_monitoring_alert to Ginkgo. The test validates that the operator correctly manages Prometheus monitoring rules and alerts when enabled and verifies that alerts fire when an invalid image configuration causes a workload to degrade.
Moved tthe test to sequential from (kuttl) parallel test suite because it modifies shared cluster-wide resources. Running this test in parallel has caused race conditions and test flakes.
Have you updated the necessary documentation?
Which issue(s) this PR fixes:
Fixes #GITOPS-7204
Test acceptance criteria:
How to test changes / Special notes to the reviewer:
export GINKGO_TEST_SUITE="sequential"
export GINKGO_FOCUS="1-092_validate_workload_status_monitoring_alert"
./bin/ginkgo -v -focus $GINKGO_FOCUS -r ./test/openshift/e2e/ginkgo/$GINKGO_TEST_SUITE