OTA-1179: README: Clarify managed-cluster risk scoping #5289
Conversation
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
openshift-ci
bot
added
the
approved
wking
changed the title
|
@wking: This pull request references OTA-1179 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.17.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci-robot
added
the
jira/valid-reference
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: LalatenduMohanty, 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 |
The 4.17.z bug is Verified [1]. 4.17.41 changes list `OCPBUGS-61859: Override NMState service definition openshift#5289` [2]. [1]: https://issues.redhat.com/browse/OCPBUGS-61859 [2]: https://amd64.ocp.releases.ci.openshift.org/releasestream/4-stable/release/4.17.41
3 participants
Point at the fleet-scoped OCPBUGS /
UpgradeBlockerassessment 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 (#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. 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 (#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.