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

Add new endpoint for fetching rule evaluations #2470

Merged
merged 2 commits into from
Mar 6, 2024

Conversation

evankanderson
Copy link
Member

Summary

Defines a new API for fetching rule evaluation results, rather than overloading GetProfileStatusByName. Does not provide an implementation, though hopefully the implementation is straightforward.

Change Type

Mark the type of change your PR introduces:

  • Bug fix (resolves an issue without affecting existing features)
  • Feature (adds new functionality without breaking changes)
  • Breaking change (may impact existing functionalities or require documentation updates)
  • Documentation (updates or additions to documentation)
  • Refactoring or test improvements (no bug fixes or new functionality)

Testing

make gen
make test
make build

Review Checklist:

  • Reviewed my own code for quality and clarity.
  • Added comments to complex or tricky code sections.
  • Updated any affected documentation.
  • Included tests that validate the fix or feature.
  • Checked that related changes are merged.

@evankanderson evankanderson requested a review from a team as a code owner March 1, 2024 01:05
dmjb
dmjb previously approved these changes Mar 1, 2024
Comment on lines 1172 to 1173
// If set, only return evaluation results for the named rules.
// If empty, return evaluation results for all rules
Copy link
Member

Choose a reason for hiding this comment

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

I guess it's not intentional but the comment here is the same as the next one

Copy link
Member Author

Choose a reason for hiding this comment

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

Oops, thanks, fixed!

Copy link
Contributor

@eleftherias eleftherias left a comment

Choose a reason for hiding this comment

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

Is this in preparation for label-based profiles? Or something else?

@JAORMX
Copy link
Contributor

JAORMX commented Mar 1, 2024

Is this in preparation for label-based profiles? Or something else?

yep

Copy link
Member Author

@evankanderson evankanderson left a comment

Choose a reason for hiding this comment

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

Are we gonna have labels be a fixed list of strings? or are we going to have labels be a keypair like k8s? This is something I'd like to get consensus on.

Yeah, that's exactl the sort of thing I wanted to highlight with this API proposal.

I was thinking bag-of-strings, but we could do keypairs if that seems more useful.

@JAORMX
Copy link
Contributor

JAORMX commented Mar 4, 2024

@evankanderson thinking about this further, I don't particularly have a use-case for key-value style labels. So, an array of strings is just as good in this case. We probably want to make them settable by users at some point though. Do you have thoughts on character validation for these labels?

@evankanderson
Copy link
Member Author

My first thought was to start with dns-style labels, but I'm wondering if that's too constricting.

@JAORMX
Copy link
Contributor

JAORMX commented Mar 4, 2024

My first thought was to start with dns-style labels, but I'm wondering if that's too constricting.

I'd say DNS + a minimal subset of characters like "/" and "-" should be fine to start with

rdimitrov
rdimitrov previously approved these changes Mar 5, 2024
@evankanderson evankanderson dismissed stale reviews from rdimitrov and dmjb via 4ddc12c March 5, 2024 19:17
@evankanderson
Copy link
Member Author

Okay, I updated the comments based on our discussion about K:V maps vs "bag of strings". We ended up going with the bag of strings approach because all our "values" ended up being singletons (e.g. "true" or "hidden", but no other value). Also clarified max size and allowed characters for the labels.

@evankanderson evankanderson merged commit 3efab73 into mindersec:main Mar 6, 2024
21 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants