Skip to content

Conversation

@wking
Copy link
Member

@wking wking commented Jun 27, 2023

The PromQL approach is similar to what we used in c641333 (#2552), except:

  • I'm using the PerformanceProfiles resource.
  • I'm using apiserver_storage_objects instead of cluster:usage:resources:sum, to cut out one lossy layer of indirection.

Generated by writing the 4.13.0 declaration by hand, and then copying out to other 4.13 releases with:

$ curl -s 'https://api.openshift.com/api/upgrades_info/graph?channel=candidate-4.13' | jq -r '.nodes[].version' | grep '^4[.]13[.]' | grep -v '^4[.]13[.]0$' | while read V; do sed "s/4[.]13[.]0/${V}/g" blocked-edges/4.13.0-PerformanceProfilesCPUQuota.yaml > "blocked-edges/${V}-PerformanceProfilesCPUQuota.yaml"; done
$ git add blocked-edges/4.13.*PerformanceProfilesCPUQuota.yaml

@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Jun 27, 2023
@openshift-ci-robot
Copy link

openshift-ci-robot commented Jun 27, 2023

@wking: This pull request references OCPNODE-1705 which is a valid jira issue.

Details

In response to this:

The PromQL approach is similar to what we used in c641333 (#2552), except:

  • I'm using the PerformanceProfiles resource.
  • I'm using apiserver_storage_objects instead of cluster:usage:resources:sum, to cut out one lossy layer of indirection.

Generated by writing the 4.13.0 declaration by hand, and then copying out to other 4.13 releases with:

$ curl -s 'https://api.openshift.com/api/upgrades_info/graph?channel=candidate-4.13' | jq -r '.nodes[].version' | grep '^4[.]13[.]' | grep -v '^4[.]13[.]0$' | while read V; do sed "s/4[.]13[.]0/${V}/g" blocked-edges/4.13.0-PerformanceProfilesCPUQuota.yaml > "blocked-edges/${V}-PerformanceProfilesCPUQuota.yaml"; done
$ git add blocked-edges/4.13.*PerformanceProfilesCPUQuota.yaml

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 kubernetes/test-infra repository.

@wking wking force-pushed the PerformanceProfilesCPUQuota branch from d0953d3 to 002560f Compare June 27, 2023 17:13
@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 27, 2023
@wking wking force-pushed the PerformanceProfilesCPUQuota branch from 002560f to 6226284 Compare June 27, 2023 17:15
@wking
Copy link
Member Author

wking commented Jun 27, 2023

Testing out the PromQL, here's a cluster without any PerformanceProfiles, with the expected 0:

image

And here's simulating the presence of the exposing resource by substituting in clusterversions.config.openshift.io, with the expected 1:

image

And here's simulating apiserver_storage_objects scraping failing by substituting apiserver_storage_objectsX, with the expected No datapoints found:

image

The PromQL approach is similar to what we used in c641333
(blocked-edges/4.11.6: declare OVNNetworkPolicyLongName risk,
2022-09-27, openshift#2552), except:

* I'm using the PerformanceProfiles resource.
* I'm using apiserver_storage_objects instead of
  cluster:usage:resources:sum, to cut out one lossy layer of
  indirection [1].

Generated by writing the 4.13.0 declaration by hand, and then copying
out to other 4.13 releases with:

  $ curl -s 'https://api.openshift.com/api/upgrades_info/graph?channel=candidate-4.13' | jq -r '.nodes[].version' | grep '^4[.]13[.]' | grep -v '^4[.]13[.]0$' | while read V; do sed "s/4[.]13[.]0/${V}/g" blocked-edges/4.13.0-PerformanceProfilesCPUQuota.yaml > "blocked-edges/${V}-PerformanceProfilesCPUQuota.yaml"; done
  $ git add blocked-edges/4.13.*PerformanceProfilesCPUQuota.yaml

[1]: https://github.com/openshift/cluster-monitoring-operator/blob/70dd5c9a414448ace1d07090730510d5922b6b18/jsonnet/rules.libsonnet#L291-L292C20
@wking wking force-pushed the PerformanceProfilesCPUQuota branch from 6226284 to b573872 Compare June 28, 2023 18:31
@petr-muller
Copy link
Member

/test e2e

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jun 29, 2023
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jun 29, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: petr-muller, wking

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci-robot
Copy link

/retest-required

Remaining retests: 0 against base HEAD 40c8dc8 and 2 for PR HEAD b573872 in total

@petr-muller
Copy link
Member

openshift-release-dev/ocp-release with layer_digest sha256:a85a707d9f1238d8b214379958ac7de19eb2b5aa631057eb07bdf1b7bdc3eff9: request failed with status 500 Internal Server Error

sadge quay

@wking
Copy link
Member Author

wking commented Jun 29, 2023

I'm ok not waiting on Quay.

/override ci/prow/e2e

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jun 29, 2023

@wking: Overrode contexts on behalf of wking: ci/prow/e2e

Details

In response to this:

I'm ok not waiting on Quay.

/override ci/prow/e2e

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 kubernetes/test-infra repository.

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jun 29, 2023

@wking: all tests passed!

Full PR test history. Your PR dashboard.

Details

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 kubernetes/test-infra repository. I understand the commands that are listed here.

@openshift-merge-robot openshift-merge-robot merged commit aee56b4 into openshift:master Jun 29, 2023
@wking wking deleted the PerformanceProfilesCPUQuota branch June 29, 2023 14:42
wking added a commit to wking/cincinnati-graph-data that referenced this pull request Oct 6, 2023
…and 4.15.0-ec.0

The risk is for updating out of the impacted releases to hypothetical
future releases with the user change, e.g. from 4.14.0-rc.3 to 4.14.0.
But we're warning on * -> 4.14.0-rc.3 (and similar) to help folks
dodge the sticky updates entirely, because 4.14.0-rc.2 -> 4.14.0 are
not expected to ever have running-as-root webhook listeners.

Pattern-matching apiserver_storage_objects from b573872
(blocked-edges/4.13.*-PerformanceProfilesCPUQuota: Declare new risk,
2023-06-27, openshift#3786) and egressips.k8s.ovn.org from 894fab7
(blocked-edges/4.11.9-ovn-namespace: 4.11.9 does not fix the
regression, 2022-10-12, openshift#2628).

The risk is only for standalone (non-HyperShift) clusters, but we
haven't worked up PromQL for "I'm (not) HyperShift" yet, and it's just
prerelease versions, so I'm skipping over that detail for now and
declaring the risk for all OVN clusters (standalone and HyperShift)
thinking about updating into impacted releases.

Generated by manually writing the rc.e risk, and then copying it around with:

  $ for VERSION in 4.14.0-rc.4 4.15.0-ec.0; do sed "s/4.14.0-rc.3/${VERSION}/" blocked-edges/4.14.0-rc.3-OVNWebhookUserConflict.yaml > "blocked-edges/${VERSION}-OVNWebhookUserConflict.yaml"; done
wking added a commit to wking/cincinnati-graph-data that referenced this pull request Oct 6, 2023
…and 4.15.0-ec.0

The risk is for updating out of the impacted releases to hypothetical
future releases with the user change, e.g. from 4.14.0-rc.3 to 4.14.0.
But we're warning on * -> 4.14.0-rc.3 (and similar) to help folks
dodge the sticky updates entirely, because 4.14.0-rc.2 -> 4.14.0 are
not expected to ever have running-as-root webhook listeners.

Pattern-matching:

* apiserver_storage_objects from b573872
 (blocked-edges/4.13.*-PerformanceProfilesCPUQuota: Declare new risk,
 2023-06-27, openshift#3786),

* egressips.k8s.ovn.org from 894fab7
  (blocked-edges/4.11.9-ovn-namespace: 4.11.9 does not fix the
  regression, 2022-10-12, openshift#2628), and

* _id from 5cb2e93 (blocked-edges/4.11.*-KeepalivedMulticastSkew:
  Explicit _id="", 2023-05-09, openshift#3591).

Using cluster_installer with the hypershift invoker is new for this
commit, and in this case I'm using it to declare HyperShift clustres
not exposed to the risk.

Generated by manually writing the rc.e risk, and then copying it around with:

  $ for VERSION in 4.14.0-rc.4 4.15.0-ec.0; do sed "s/4.14.0-rc.3/${VERSION}/" blocked-edges/4.14.0-rc.3-OVNWebhookUserConflict.yaml > "blocked-edges/${VERSION}-OVNWebhookUserConflict.yaml"; done
wking added a commit to wking/cincinnati-graph-data that referenced this pull request Oct 6, 2023
…and 4.15.0-ec.0

The risk is for updating out of the impacted releases to hypothetical
future releases with the user change, e.g. from 4.14.0-rc.3 to 4.14.0.
But we're warning on * -> 4.14.0-rc.3 (and similar) to help folks
dodge the sticky updates entirely, because 4.14.0-rc.2 -> 4.14.0 are
not expected to ever have running-as-root webhook listeners.

Pattern-matching:

* apiserver_storage_objects from b573872
 (blocked-edges/4.13.*-PerformanceProfilesCPUQuota: Declare new risk,
 2023-06-27, openshift#3786),

* egressips.k8s.ovn.org from 894fab7
  (blocked-edges/4.11.9-ovn-namespace: 4.11.9 does not fix the
  regression, 2022-10-12, openshift#2628), and

* _id from 5cb2e93 (blocked-edges/4.11.*-KeepalivedMulticastSkew:
  Explicit _id="", 2023-05-09, openshift#3591).

Using cluster_installer with the hypershift invoker is new for this
commit, and in this case I'm using it to declare HyperShift clustres
not exposed to the risk.

Generated by manually writing the rc.e risk, and then copying it around with:

  $ for VERSION in 4.14.0-rc.4 4.15.0-ec.0; do sed "s/4.14.0-rc.3/${VERSION}/" blocked-edges/4.14.0-rc.3-OVNWebhookUserConflict.yaml > "blocked-edges/${VERSION}-OVNWebhookUserConflict.yaml"; done
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. lgtm Indicates that a PR is ready to be merged.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants