Consistency between carvel tools for filtering

[jorgemoralespou]

Describe the problem/challenge you have Carvel tool users have to learn filtering capabilities in some of the tools in the suite. The most prominent one is ytt where users have to learn filtering in the matchers. When a user goes to kapp, he finds a plethora of options to filter the resources which:

• are not aligned with the ones in ytt
• have like a gazillion different cli options to filter by many different fields

This is the output from the CLI help:

Resource Filter Flags:
      --filter string                                        Set filter (example: {"and":[{"not":{"resource":{"kinds":["foo%"]}}},{"resource":{"kinds":["!foo"]}}]})
      --filter-age string                                    Set age filter (example: 5m, 500h+, 10m-)
      --filter-kind strings                                  Set kinds filter (example: Pod) (can repeat)
      --filter-kind-name strings                             Set kind-name filter (example: Pod/controller) (can repeat)
      --filter-kind-ns strings                               Set kind-namespace filter (example: Pod/, Pod/knative-serving) (can repeat)
      --filter-kind-ns-name strings                          Set kind-namespace-name filter (example: Deployment/knative-serving/controller) (can repeat)
      --filter-name strings                                  Set name filter (example: controller) (can repeat)
      --filter-ns strings                                    Set namespace filter (example: knative-serving) (can repeat)

Describe the solution you'd like What I would expect is consistency between the tools so that a user that learns how to use one tool can leverage that expertise on the following one.

I would expect something like:

Resource Filter Flags:
      --filter string                                        Set filter (example: {"metadata":{"namespace":"foo"}})

cc/ @GrahamDumpleton

---

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.

[cppforlife]

@jorgemoralespou interesting suggestion. we'll definitely have to chew on it collectively.

personally i think we have to be careful about over optimizing for consistency where it may not make sense. im not sure in this case it's appropriate to try to make them "same" because one tool (ytt) is designed to give you fine grained way of doing selection that's independent of k8s (generic) against yaml docs; other tool (kapp) is optimized for common k8s interactions -- e.g. "kapp inspect -a foo --filter-kind Pod" etc. is quick and easy CLI experience where you are dissecting production data quickly.

i could imagine adding a flag to kapp along the lines "--filter-ytt-matcher" (and possibly find a single letter shorthand for it) that would allow ytt expression (e.g. matcher.subset({...}) or matcher.and_op(...)) where ytt matching is actually used underneath. this could unlock more advanced cases specified via ytt lang without removing quick and easy shorthands.

[jorgemoralespou]

I agree about over-optimizing. Nevertheless this issue can serve to think about the way to optimize the experience through carvel tools.