Configurable ingressClassName and ingress access type#2409
Configurable ingressClassName and ingress access type#2409AryanP123 wants to merge 1 commit intoskupperproject:mainfrom
Conversation
AryanP123
requested review from
c-kruse,
fgiorgetti,
nluaces and
pwright
as code owners
AryanP123
force-pushed
the
ingress-class
branch
from
ef288ea to
882e647
Compare
fgiorgetti
left a comment
fgiorgetti
left a comment
There was a problem hiding this comment.
One minor comment, but it seems to work.
Not sure, though, how it is effectively going to work, since we do not set controller specific settings for ssl-passthrough other than nginx.
| } | ||
|
|
||
| // routerAccessSettingsMerge copies existing RouterAccess settings, then applies | ||
| // site.spec.settings.ingressClassName when that key is present (non-empty sets, |
There was a problem hiding this comment.
If the ingressClassName is provided through a RouterAccess and through the Site, the one provided through the Site resource is overwriting this one. Is this the desired behavior?
There was a problem hiding this comment.
My thought process was that we still want users to configure it on the Site (with linkAccess), so we copy Site.spec.settings.ingressClassName into the controller-managed RouterAccess. Without that, the Site field would have no effect on the Ingress. When the key is absent on the Site, we don’t change whatever is already on RouterAccess. Let me know your thoughts.
2 participants
Fixes #2397