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

Support resourceMatchers in searchRules #182

Open
gabegorelick opened this issue Oct 26, 2021 · 1 comment
Open

Support resourceMatchers in searchRules #182

gabegorelick opened this issue Oct 26, 2021 · 1 comment
Labels
carvel accepted This issue should be considered for future work and that the triage process has been completed enhancement This issue is a feature request

Comments

@gabegorelick
Copy link

Describe the problem/challenge you have

The existing key matcher and value matcher are quite limited.

For example, let's say I have a ConfigMap with an image field:

apiVersion: v1
kind: ConfigMap
metadata:
  name: image-config
data:
  image: foo

You could use a key matcher to name: image and path: [data], but that would potentially catch other resources (ConfigMaps or otherwise) that you didn't mean to include.

Alternatively, you could use a value matcher, but that can also suffer from false positives and requires knowing the image name and/or repo ahead of time.

Describe the solution you'd like

Support resourceMatchers, similar to what kapp does: https://carvel.dev/kapp/docs/latest/config/#resource-matchers. This would allow targeting specific kinds (ConfigMap) and names.

Once the resource matcher filters down to the resource(s), I think you'd still need the ability to specify paths inside the resource though.

Anything else you would like to add:
https://kubernetes.slack.com/archives/CH8KCCKA5/p1635201137105000?thread_ts=1635197514.098700&cid=CH8KCCKA5


Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

@gabegorelick gabegorelick added carvel triage This issue has not yet been reviewed for validity enhancement This issue is a feature request labels Oct 26, 2021
@cppforlife cppforlife added carvel accepted This issue should be considered for future work and that the triage process has been completed and removed carvel triage This issue has not yet been reviewed for validity labels Oct 26, 2021
@johnSchnake
Copy link

I was just looking at kbld with respect to Sonobuoy and came across this same limitation. In my case, sonobuoy gen produces k8s types to put on the server; kbld resolves the main sonobuoy/sonobuoy image just fine.

However, the plugins we choose to run are actually not created as pods right away but launched later in the lifecycle of the application but their information is stored in a configmap.

It would be great to be able to automatically be able to detect and resolve those images as well.

The configmap looks like:

...
---
apiVersion: v1
data:
  plugin-0.yaml: |-
    sonobuoy-config:
      driver: Job
      plugin-name: e2e
      result-format: junit
    spec:
      command:
      - /run_e2e.sh
      ...
      image: k8s.gcr.io/conformance:v1.23.3
...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
carvel accepted This issue should be considered for future work and that the triage process has been completed enhancement This issue is a feature request
Projects
Status: To Triage
Development

No branches or pull requests

3 participants