GEP-1713: Standard Mechanism to Merge Multiple Gateways #1863
Conversation
k8s-ci-robot
added
kind/gep
k8s-ci-robot
added
the
size/L
Can you provide some examples that come to mind? Generally, I think a first step is to decide the expectations for gateway ports and listeners (within a single gateway) - #1842 Then this GEP should decide if merging across gateways allows us to relax some of those requirements. |
Just come to mind because we met this in istio, istio's gateway has server fields which is like listener here. If all the listners in one gateway, it can be validated at least. But if they are in at least two gateways, once they are created at the same time, we have no way to validate them. This is the mechanism of eventual consistence limitation, the only way is to detect any conflict on running |
I agree - I think when it comes to the scenario you mentioned I would suggest that if a child gateway cannot merge into a parent gateway then the child gateway status conditions |
|
Can folks take another look at the GEP - I hope to have addressed the topics in the discussions and I've flushed out a lot of the semantics. |
dprotaso
changed the title
There was a problem hiding this comment.
One of the teams I work with does some merging of Gateways which may be relevant here and I would be interested to have their review on the subject:
/cc @mlavacca @pmalek @rainest
If we could give a little bit of time for them to check this out they might have some good thoughts on the matter.
/hold
k8s-ci-robot
added
the
do-not-merge/hold
There was a problem hiding this comment.
No substiantial comments from my side but I just want to ask this to be sure: (maybe I've missed this in the comments somewhere):
Can a child attach to a parent in a different namespace? My gut tells me that this is not meant to be allowed but it wasn't explicitly mentioned here.
[updated Feb 7 2024] I added support for cross namespace |
|
@interpixelstudios your comment is sorta off topic for this PR. It might be better to create a discussion here - https://github.com/kubernetes-sigs/gateway-api/discussions |
|
|
||
| #### Policy Attachment | ||
|
|
||
| Policies attached to a parent Gateway apply to both the parent and all children listeners. |
There was a problem hiding this comment.
It would be nice to consider or rule out an alternative that is defined in a policy that could be attached to the parent Gateway.
There was a problem hiding this comment.
Can you elaborate what you mean? I don't understand.
Co-authored-by: Candace Holman <[email protected]>
… status condition section
|
Hey folks - feedback has been to change approaches in terms of the Gateway <> Gateway relationship this GEP proposed. Given the large # of comments and commits on this PR it didn't make sense to continue further revisions here. This PR has now been usurped by #3213 Going to close this out - please review the new PR when you get a chance. |
Note - this refactors out the 'merging' aspect of Gateways from #1757 - but tweaks the approach
What type of PR is this?
/kind gep
What this PR does / why we need it:
Outlines a mechanism to merge Gateways
Which issue(s) this PR fixes:
Fixes #1713
Does this PR introduce a user-facing change?: