[Revert the revert] Change ingress fetching to be isolated per provider#116
Conversation
|
[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 DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
levikobi
left a comment
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.
|
/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 |
…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
…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?: