-
Notifications
You must be signed in to change notification settings - Fork 209
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(route-monitor-operator): add console monitor [OSD-5499] #736
chore(route-monitor-operator): add console monitor [OSD-5499] #736
Conversation
/assign @jeremyeder |
It doesn't need a separate owner. |
/lgtm |
/hold |
There should be an owners file with a
Do we have a process for selecting these? Will alerts be raised based off this, or just a metric? cc @dofinn |
Co-authored-by: Rick Rackow <[email protected]>
Who needs that if it can't go in without "approved" anyway? Yes alerts is what route monitor operator does |
Because change to MCC should be reviewed by subject matter experts in addition to leads. |
So you need me to tell you it's ok, so you can approve? Not very efficient imho |
We have nothing in stone that helps us define initial values for SLOs. |
/hold need to rework alerts in RMO, they are currently based on |
/unhold @RiRa12621 can you give a final /lgtm? |
/lgtm |
as @NautiluX suggeste, changed NS and need a lgtm becuase of it |
tested on stage (I can replace my routemonitor with this one, but outcome should be similar) |
changing to the current CR still works and is scraped, only future concern is the message naming, which should be solved in the RMO code itself (the value of the breach is 1 and not a good indication to how long the alert is firing) |
@@ -8,4 +8,4 @@ spec: | |||
name: console | |||
namespace: openshift-console | |||
slo: | |||
targetAvailabilityPercent: "99.5" | |||
targetAvailabilityPercent: "99.95" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why now 99.95? According to the SLO doc it should be 99.5? Probably I miss some discussion here...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
turns out this was confused with the API server SLA. We'll change it back to 99.5.
Will this automatically merge once #771 is resolved? |
@wgordon17 If I get a +1 for this then yes |
@georgettica Consider this a ➕ 1 from PM if it helps :) Not sure if you need plus one's from others ¯_(ツ)_/¯ |
@georgettica LGTM, but as previously commented, needs an
|
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cblecker, georgettica, RiRa12621 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
I have 2 questions for this PR:
.spec.targetAvailabilityPercent
be?