tetragon: group enable process ancestors flags

[t0x01]

This PR deprecates 5 enable-process-ancestors boolean flags added in PR 2938 and replaces them with a new --enable-ancestors flag for better UX. All 5 deprecated flags remain functional; the new --enable-ancestors flag will simply override them if both old and new flags are used.

Flags being deprecated:

• --enable-process-ancestors
• --enable-process-kprobe-ancestors
• --enable-process-tracepoint-ancestors
• --enable-process-uprobe-ancestors
• --enable-process-lsm-ancestors

Also, support for the new flag is added in the Tetragon Helm chart via a tetragon.processAncestors.enabled value.

tetragon: Deprecate enable-process-ancestors boolean flags
helm: Add tetragon.processAncestors.enabled value

[netlify]

✅ Deploy Preview for tetragon ready!

Name	Link
🔨 Latest commit	e8caab0
🔍 Latest deploy log	https://app.netlify.com/projects/tetragon/deploys/6834243006c44a0008676f32
😎 Deploy Preview	https://deploy-preview-3581--tetragon.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[mtardy]

Hey I didn't realized we added so many flags for one feature, would it be possible to group them under --enable-ancestors=kprobe,tracepoints,lsm etc, instead of boolean flags? This PR is fine but I would think that would be a better usability thing. You can use StringSlice in viper flags.

Would you think that would be better maybe? Since this is a recent feature, maybe it's fine to just change the flags. Not sure it's been released already or not, if yes we might need to deprecate them before removing next release.

[t0x01]

Hey.

I think it should be possible to group them, yes. This feature was released with version 1.4.0 not so long ago. I'll see what i can do about it. Should i submit another PR or extend this one?

[mtardy]

Hey.

I think it should be possible to group them, yes. This feature was released with version 1.4.0 not so long ago. I'll see what i can do about it. Should i submit another PR or extend this one?

I think it would be reasonable to merge this, and create another PR with two things:

1. deprecate existing flag and add the list one that groups them.
2. update the helm charts flag so that it uses the new group flag implem with a better UX.

OR

we can make the UX correct in helm and then change the underlying implem.

Any opinion @lambdanis ?

[ghost]

would it be possible to group them under --enable-ancestors=kprobe,tracepoints,lsm etc, instead of boolean flags?

I agree, this sounds like a better approach.

I would update this PR to introduce both a new flag and a Helm value like this:

tetragon:
  processAncestors:
    enabled: "base,kprobe,tracepoint,uprobe,lsm"

You can rename and reuse ParseMetricsLabelFilter function from pkg/option, and check how we use it to parse the metrics-label-filter option - it's also passed as a comma-separated list. I would expect the code logic to override the old flags if enable-ancestors is non-empty. Then we can deprecate the old flags (just make sure you add an upgrade note for that).

Speaking more generally, the Helm values don't have to be named exactly like the corresponding flags. If we can group related values or follow Helm conventions, then it makes sense to structure them slightly differently than the corresponding flags. As an alternative to the above, I think Helm values like this would make sense too:

tetragon:
  processAncestors:
    base:
      enabled: true
    kprobe:
      enabled: true
    tracepoint:
      enabled: true
    uprobe:
      enabled: true
    lsm:
      enabled: true

but then translating these to a comma-separated flag is not as straightforward, so if we're changing the flag format then it seems better to keep the Helm value format same.

[kkourt]

but then translating these to a comma-separated flag is not as straightforward, so if we're changing the flag format then it seems better to keep the Helm value format same.

I don't think we need to translate it into a comma-seperated flag. Using multiple flags (--enable-ancstors=kprobe --enable-ancestors=tracepoint) should also work. If we go down this road, I think we would also need a --disable-ancestors flag (?).

[mtardy]

I don't think we need to translate it into a comma-seperated flag. Using multiple flags (--enable-ancstors=kprobe --enable-ancestors=tracepoint) should also work.

Yes iirc viper parses both --flag=value1 --flag=value2 and --flag=value1,value2 by using StringSlice.

If we go down this road, I think we would also need a --disable-ancestors flag (?).

If the default is to be disabled, not sure we need a disable ancestor flags? Otherwise we need to resolve conflict etc, it sounds annoying and unnecessary.

[t0x01]

Hey @mtardy , @lambdanis

Thanks for the help. I added both new --enable-ancestors flag and tetragon.processAncestors.enabled helm value, as you suggested. I also added an upgrade note that indicates which flags are being deprecated. Let me know if these changes are ok.

[mtardy]

Hey thanks a lot for the PR, it looks really clean!

However I think you could simplify by reusing the old variables internally (it's fine to have these variables, I think the important part is just avoid the UX of having all those flags). Also you can reuse the viper.GetStringSlice and just do validation on the values.

[mtardy]

(I'll be out for 15 days from today, if you want to move this forward in the meantime you might want to ping someone else)

[t0x01]

(I'll be out for 15 days from today, if you want to move this forward in the meantime you might want to ping someone else)

I can wait. I really appreciate the help. Thank you.

[mtardy]

Thank you, looks good only a few comments. Sorry it was so complicated, I honestly thought it would be easier to do that!

[mtardy]

also please ignore the windows test failing, you can rebase if you want and it should disappear.

[mtardy]

(I'll be out for 15 days from today, if you want to move this forward in the meantime you might want to ping someone else)

I can wait. I really appreciate the help. Thank you.

thanks btw for waiting :)

[mtardy]

lgtm, sorry for the delay! I'll rerun the CI if there's an issue

[t0x01]

Had to resolve conflicts in go.mod again. No other changes.

[mtardy]

Had to resolve conflicts in go.mod again. No other changes.

sorry we removed deps last week, you'll need to rebase once again 😔

[mtardy]

Thank you for your patience and help!