Add risks for OPNET-479 #4903
Merged
Add risks for OPNET-479 #4903
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
openshift-ci
bot
added
the
approved
cblecker
force-pushed
the
add-risks-for-OPNET-479
branch
from
2673590 to
969271c
Compare
wking
reviewed
Mar 8, 2024
cblecker
force-pushed
the
add-risks-for-OPNET-479
branch
from
969271c to
f357682
Compare
cblecker
force-pushed
the
add-risks-for-OPNET-479
branch
from
f357682 to
ca5795c
Compare
Contributor
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cblecker, wking The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This was referenced Mar 8, 2024
wking
added a commit
to wking/cincinnati-graph-data
that referenced
this pull request
May 23, 2024
Point at the fleet-scoped OCPBUGS / UpgradeBlocker assessment process, because we don't want managed to declare risks without having that all-fleet assessment (even if the all-fleet assessment happens after a managed-specific risk declaration). If an all-fleet risk is declared, any managed-specific risk in that space can be removed. If an all-fleet risk is not declared, service-delivery graph-data admins can make their own call about what to do with a managed-specific risk. Also point out the possibility of customer-managed admins being confused by managed-specific risks. For example, ca5795c (Adding update risk for OPNET-479, 2024-03-08, openshift#4903) was an ARO-specific declaration, but the message said "clusters running on Azure with Accelerated Networking" which nominally includes non-ARO Azure clusters. Some of those cluster admins asked about why the risk wasn't matching their clusters, and it's because we saw no evidence of non-ARO clusters being bit by the race [1]. The guidelines I'm adding will hopefully reduce the chance of future managed-specific risk declarations causing similar customer-managed admin confusion. I'm also adding _id="" to the queries as a pattern to support HyperShift and other systems that could query the cluster's data out of a PromQL engine that stored data for multiple clusters. More context in 5cb2e93 (blocked-edges/4.11.*-KeepalivedMulticastSkew: Explicit _id="", 2023-05-09, openshift#3591). And I'm also adding ARO-specific PromQL. Maybe someday ARO will join the other managed flavors in using sre:telemetry:managed_labels, but they haven't yet. [1]: https://issues.redhat.com/browse/OPNET-479?focusedId=24366396&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-24366396
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.