Hi @bexxmodd. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

/cc @LiorLieberman

/approve
Will leave lgtm to someone else

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bexxmodd, LiorLieberman

The full list of commands accepted by this bot can be found here.

The pull request process is described here

This is fixing one small bit of what seems to be a larger problem with the logic. What I found trying to run the 1.4 conformance tests was:

1. --all-features and --exempt-features didn't work together.
2. Even when I explictly asked for only the Mesh profile, and marked Gateway as exempt, I was getting Gateway tests trying to run (even after I separately fixed problem 1 in my local copy of conformance).

The combination makes me feel that we introduced a significant problem in the conformance logic, and I'd like to see all of that addressed. Off the top of my head, I'd say

• read from supportedFeatures if you're allowed to
• add features from explicitly stated profiles
• add all features if --all-features is set
• remove all features listed by --exempt-features (including all features that are part of exempted profiles)

in that order... and I may be wrong even there, but it feels right at the start.

Overall, I'm not a fan of this split between "inferred" and "manual" -- I found the long discussion we had on Slack, and summarized it in #3927 (comment). The above doesn't really depend on that, and I do think it makes sense to be able to read features from supportedFeatures; most of all, though, it must be possible to easily do a mesh-only test.

This is fix for the issue n.1 from #4154

Yeah, @bexxmodd, what I mean here is that it's a point fix: instead of systematically making sure that all the combinations will do sane things, you're addressing one specific failure. At this point, I think we're better served by taking a bit more time and doing a single PR where we've verified that a known set of flag combinations does sane things.