-
Notifications
You must be signed in to change notification settings - Fork 590
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
do not treat kong as a special class #731
Comments
AFAIK implementing #732 does this. With the addition of fb3ab86 to #767 that's the case. To try and check this, I changed instances of kubernetes-ingress-controller/internal/ingress/annotations/annotations_test.go Lines 35 to 44 in fc5de5c
kong expected success cases in there if we like.
|
ListKnativeIngresses is one exception because it uses a special validKnativeIngressClass function that hard-codes lazy/allow empty matching if using the default class, which I think does violate the spirit of #731 if not the letter (who cares if we change the default class and it's special behavior for for "mycoolnewdefault" instead of "kong"?), so that probably needs to change. Do we care if that's controlled with a flag and/or preserves the default behavior (always allow empty if using the default class)? I'd like to use annotations validity function and the value of the Ingress matching flag, i.e. if you set |
The current behavior treats “kong” as a special ingress.class: if controller is configured with ingress class as “kong”, it will also satisfy all ingress resources which don’t have an Ingress class defined. If an ingress class is not specified in the controller and an ingress resource has “kong” as its ingress class, then the controller takes control of the resource.
The scope of the work:
kong
be default.For more details see the doc in #690.
The text was updated successfully, but these errors were encountered: