[Revert the revert] Change ingress fetching to be isolated per provider #116
Conversation
k8s-ci-robot
added
the
kind/feature
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: LiorLieberman The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
cncf-cla: yes
k8s-ci-robot
added
the
size/XL
There was a problem hiding this comment.
/lgtm
/hold in case @mlavacca or @dpasiukevich have any further comments.
The only thing that is missed in my opinion is having a test that actually verifies the #109 bug doesn't happen anymore.
k8s-ci-robot
added
the
do-not-merge/hold
k8s-ci-robot
added
the
lgtm
|
/lgtm
+1 to the test, would be great to have to avoid similar regression in future. |
|
@mlavacca is off for a bit, and we agreed on slack that testing this would be slightly tricky because of the provider initialization. removing the hold /unhold |
k8s-ci-robot
removed
the
do-not-merge/hold
…er (kubernetes-sigs#116) * pass namespace in ProviderConf and make read from file account for namepsaces * move ingress-nginx to fetch its own ingresses * move Kong to fetch its own ingresses * Deprecate ingress fetching from the generic package Also added issue numbers for TODOs * add helper common functions for reading ingresses and extract them from file
Reverts #114 which is the revert of #112
I copy pasted the below PR description from #112
What type of PR is this?
/kind feature
What this PR does / why we need it:
Currently we fetch all the ingresses in the main package and we pass them to all the providers.
This is not only redundant (as every provider only cares about its own ingresses) but also creates some bugs. (#109)
This also increases consistency as we already fetch CRDs at the provider level and store them in a local storage.
Note: This PR is likely to yield some more issues and TODOs that wont be addressed in this PR.
For example changing
ToGatewayAPIinterface function signature that wont needi2gw.InputResourcesanymore.Another thing would be to revisit
i2gw.InputResourcesstruct and check if we need it or we will change it to just a list of Ingresses as it is the only things it holds now.I structured the commits to ease the review so you could review each commit independently
Which issue(s) this PR fixes:
Fixes #109
Does this PR introduce a user-facing change?: