-
Notifications
You must be signed in to change notification settings - Fork 594
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
Rework handling of ingress.class annotation #767
Conversation
Refactor the class filter to have ternary modes of operation: * Required: the resource must have a class annotation, and it must match. * Lazy: the resource can have a class annotation, but if we use the default class annotation and the resource has none, accept the classless resource. * Ignored: the resource does not require a class annotation. We watch it always, and assume that it cannot be used unless some other resource that has Required or Lazy behavior pulls it in.
Current failure is
From kubernetes-ingress-controller/internal/ingress/controller/parser/parser_test.go Lines 1675 to 1727 in 4bf2405
Need to think over whether that's something the new system actually does wrong or a contrived test that shouldn't run that way in practice and needs adjusting. |
Tests now passing with the Left un-squashed for now because, assuming that there will be change requests, I want to keep the messy history for the benefit of my own memory when I address them. Apologies for the lack of commit atomicity for the PR; please rely on the file diff and assume it will be wrapped up into a single big "revamp class annotation" commit at the end. |
Went ahead and added several additional tasks around changing the default class handling to this by means of renaming and flipping the flag default, along with the new consumer class flag. The latter replaces some placeholder code here, and IMO that's good albeit at the cost of increasing the PR scope. That should also bring the to cover #731 and clear most of the major changes to class handling/matching--rest should be either relatively minor changes, effectively done by virtue of other changes, or expansion of docs&tests. Remaining tests related to that, I think those should probably be in a new PR before closing out those cards, as I'd like to get the lengthy history in this one squashed. |
Use both the default ingress class and an arbitrary non-default ingress class when testing annotations. This confirms that annotation handling has no special cases for the default class.
03fefa7 adds varied class tests for annotations, but not for the parser. fakestore (which the parser tests rely on) currently instantiates its store with a hard-coded class (which is the current default, It shouldn't be necessary to test a non-default class there, however, as any special behavior was either in the annotations code or REH filters. The former is tested independently. The latter no longer has any class filter, so I don't see much point in trying to test for special behavior there. CA Certificates currently have (non-special) behavior in the store, but it will go away as part of #739. Knative stuff is more of an issue: #731 (comment) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are skipClassless
and processClassless
in this patch.
This can lead to boolean logic bugs in the codebase and maintainers pay an additional tax on understanding the code.
Let's simplify. Please update to ensure that the code has only one construct, my preference is processClassless
.
{"kozel", true, "kozel", true}, | ||
{"", false, "killer", true}, | ||
{"custom", false, "kozel", false}, | ||
{"custom", true, "kozel", false}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This table is bad. We should always use named struct parameters. Not in scope for this PR but leaving a note.
Remaining skipClassless was missed in the rework, but obsoleted by 1bac620 for #767 (comment) |
What this PR does / why we need it:
This PR expands the controller's logic for handling the
ingress.class
annotation, introducing three handling modes:ingress.class
annotation (KongClusterPlugin and TCPIngress).ingress.class
, which fixes the bug that prevented the controller from following their updates.Which issue this PR fixes
Fix #733
Fix #734
Fix #735
Special notes for your reviewer:
This is a draft in part because it needs #751 and #764 merged first, and in part because I have some questions, primarily around what tests we need to add. Draft questions/comments go!
Implementation
Tests
I checked for existing similar coverage based on an unscientific run of
find ./ -name "*_test.go" | xargs grep -ni class
.Naming
I'm not super-fond of the naming I chose for the class handling system, and it's something that ultimately matters more how others interpret it, so please bikeshed with abandon as to whether the Require/Ignore/Lazy naming scheme (and some of its minor variants) makes sense for describing what those modes actually do.
Comments
Some of these still refer to the old system and need to be replaced. I'd like to handle that once the actual code/naming is finalized rather than trying to rewrite them in advance.