-
-
Notifications
You must be signed in to change notification settings - Fork 18
Better filtering options for exporting traces #63
Copy link
Copy link
Open
Labels
AstronomerapiChanges or improvements to the API or CRDsChanges or improvements to the API or CRDscliIssues with the skctl CLIIssues with the skctl CLIsk-tracerIssues with the Kubernetes tracerIssues with the Kubernetes tracer
Metadata
Metadata
Assignees
Labels
AstronomerapiChanges or improvements to the API or CRDsChanges or improvements to the API or CRDscliIssues with the skctl CLIIssues with the skctl CLIsk-tracerIssues with the Kubernetes tracerIssues with the Kubernetes tracer
Type
Fields
Give feedbackNo fields configured for issues without a type.
Description
Currently, when exporting a trace, you can filter in one of three ways:
This doesn't really provide the level of flexibility that we want. We should really have some sort of allow/deny rules for namespaces and label selectors, and excluding daemonsets just doesn't even make sense anymore (originally when we were just tracking pods, it made sense because we didn't want simulated copies of the daemonset objects running on the simulated nodes).
I think this requires a bit of thought before writing code. Can we include in this issue a proposal for the various filtering mechanisms that we want? E.g., allow by default vs deny by default, are namespaces and label selectors enough granularity, what happens if we "deny a namespace but include a label selector in that namespace", etc. I think there is some prior art we can look at for guidance here, e.g., how does iptables do this?
See also #68
When making any changes to the tracer API, please read Making API changes.