Skip to content
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

Simplify custom resource state metrics API using CEL #2059

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

CatherineF-dev
Copy link
Contributor

What this PR does / why we need it: Simplify custom resource state metrics API

How does this change affect the cardinality of KSM: (increases, decreases or does not change cardinality) No

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #1978

@k8s-ci-robot k8s-ci-robot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels May 7, 2023
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: CatherineF-dev
Once this PR has been reviewed and has the lgtm label, please assign mrueg for approval. For more information see the Kubernetes Code Review Process.

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

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

@k8s-ci-robot
Copy link
Contributor

This issue is currently awaiting triage.

If kube-state-metrics contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

@k8s-ci-robot k8s-ci-robot added needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels May 7, 2023
version: "v1"
mode: for_loop # or merged
metrics:
- name: "ready_count"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how is the metrics type defined?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I presume we'll still need fields with hardcoded values, eg., type.

Copy link
Member

@rexagod rexagod Jun 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noting here that we still have non-path-based constructs, like so:

  • type (used to check OpenMetrics conformance, and if value field is applicable)
  • path (relative paths when used with labelsFrom*, these can be CEL expressions with the following subsections)
    • non-relative
    • relative
    • multi-relative (relative to different paths) (KSM does not support this right now)
  • commonLabels
  • list

Something we might want to persue under the configuration revamp is to keep such constructs to a minimum (and try to replace most of these using CEL, wherever possible), as we may find ourselves implementing custom logic and introducing complexity as such constructs grow over time.

type-a: 1
type-b: 3
conditions:
- name: a
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to have a configuration example using CEL that loops over this list and generates the following metrics?

ready_count{phase="Pending", condition="a"}  45
ready_count{phase="Pending", condition="b"}  66

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to add on to what Manuel asked, would it be possible to reproduce this example using CEL?

Copy link
Member

@rexagod rexagod left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for working on this!

## Goal

- Simplify 8 operations into one operation to reduce maintaining work.
- A complete API, so that can support more cases. For example, querying number of CRs under one CRD.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sure what a complete API means here? AFAICT the proposal targets redefining a subset of configuration constructs, specifically ones that work with path resolutions. Is that not the case?


| Existing operation | CEL |
| :--- | :--- |
| path: [status, sub] \n labelFromKey: type | x.status.sub.map(y, {"name": y}) |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you document what's x here? Is this a representation for all CRs that come under the specified GVK?

type-a: 1
type-b: 3
conditions:
- name: a
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to add on to what Manuel asked, would it be possible to reproduce this example using CEL?

version: "v1"
mode: for_loop # or merged
metrics:
- name: "ready_count"
Copy link
Member

@rexagod rexagod Jun 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noting here that we still have non-path-based constructs, like so:

  • type (used to check OpenMetrics conformance, and if value field is applicable)
  • path (relative paths when used with labelsFrom*, these can be CEL expressions with the following subsections)
    • non-relative
    • relative
    • multi-relative (relative to different paths) (KSM does not support this right now)
  • commonLabels
  • list

Something we might want to persue under the configuration revamp is to keep such constructs to a minimum (and try to replace most of these using CEL, wherever possible), as we may find ourselves implementing custom logic and introducing complexity as such constructs grow over time.

@k8s-triage-robot
Copy link

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

  • Mark this PR as fresh with /remove-lifecycle stale
  • Close this PR with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 20, 2024
@CatherineF-dev
Copy link
Contributor Author

/remove-lifecycle stale

@k8s-ci-robot k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 20, 2024
@rexagod
Copy link
Member

rexagod commented Jan 21, 2024

While this is easily one of the features we'd like to see implemented, tested, and polished enough throughout v2.x releases to finally make its way into v3, I just want to mention the primary concern around this, before we commit to the move, was if CEL could replace the existing native metrics. If we could verify the same first, I believe we could then move forward confidently which this change.



```
kind: CustomResourceStateMetricsV2
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
kind: CustomResourceStateMetricsV2
kind: CustomResourceStateMetrics
apiVersion: v2

I'd propose to use the common versioning keys :-) We could even provide conversion from the old to the new version if we want

@k8s-triage-robot
Copy link

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

  • Mark this PR as fresh with /remove-lifecycle stale
  • Close this PR with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 29, 2024
@CatherineF-dev
Copy link
Contributor Author

/remove-lifecycle stale

@k8s-ci-robot k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Simplify custom resource metrics API by leveraging jq/CEL
6 participants