ListenerSet APIs + Generated Clients #3588
Conversation
k8s-ci-robot
added
the
do-not-merge/release-note-label-needed
k8s-ci-robot
added
cncf-cla: yes
|
I'm going to pull Into a separate PR |
|
/hold for #3589 |
dprotaso
changed the title
k8s-ci-robot
added
the
do-not-merge/work-in-progress
dprotaso
changed the title
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
apisx/v1alpha1/listenerset_types.go
Outdated
| // +kubebuilder:validation:XValidation:message="Listener name must be unique within the Gateway",rule="self.all(l1, self.exists_one(l2, l1.name == l2.name))" | ||
| // | ||
| // # TODO: Figure out how to allow empty port here | ||
| // #+kubebuilder:validation:XValidation:message="Combination of port, protocol and hostname must be unique for each listener",rule="self.all(l1, self.exists_one(l2, l1.port == l2.port && l1.protocol == l2.protocol && (has(l1.hostname) && has(l2.hostname) ? l1.hostname == l2.hostname : !has(l1.hostname) && !has(l2.hostname))))" |
There was a problem hiding this comment.
Ok this should become
self.all(l1,
!has(l1.port) || // Port is missing no conflict can ever occur
self.exists_one(l2,
has(l2.port) && // If L2 has no port than there can't be a conflict
// Regular check since both listeners have a port
l1.port == l2.port &&
l1.protocol == l2.protocol &&
(has(l1.hostname) && has(l2.hostname) ? l1.hostname == l2.hostname : !has(l1.hostname) && !has(l2.hostname))
)
)
|
/hold need to add the Gateway changes |
|
/hold cancel |
k8s-ci-robot
removed
the
do-not-merge/hold
k8s-ci-robot
added
the
do-not-merge/hold
Ok - I figured out there's a marker
So we could have a single clientset that has stable and experimental apis - let me know what people prefer |
| @@ -74,7 +74,7 @@ type ListenerNamespaces struct { | |||
| // * None: Only listeners defined in the Gateway's spec are allowed | |||
| // | |||
| // +optional | |||
| // +kubebuilder:default=Same | |||
There was a problem hiding this comment.
This PR seems to jump us all the way from provisional to experimental without hitting implementable. If we have consensus then there might not actually be anything wrong with that, but bare minimum we should update the GEP status accordingly here.
There was a problem hiding this comment.
Want me to split out the APIs in to a separate PR?
There was a problem hiding this comment.
No that's OK! I just think we should flag the status change here and then please feel free to consider this comment resolved.
I just realized another opportunity to update the GEP, but I'll create a separate comment.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: dprotaso The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
| type AllowedListeners struct { | ||
| // Namespaces defines which namespaces ListenerSets can be attached to this Gateway. | ||
| // While this feature is experimental, the default value is to allow no ListenerSets. | ||
| // | ||
| // +optional | ||
| // +kubebuilder:default={from: None} | ||
| Namespaces *ListenerNamespaces `json:"namespaces,omitempty"` | ||
| } |
There was a problem hiding this comment.
I love this part of the API, because I think it captures a very important use case for cluster admins: when they want a Gateway to operate more like a classic ingress-controller, in that there's a single LB for routes across many namespaces.
What occurs to me is that we should update the GEP, as it currently states cross-namespace as a "later goal" but it seems like we're already going for it, and I'm very much in favor of this being an immediate goal. Anything I'm missing? (if not, please just feel free to update the GEP to reflect the goal and then consider my comment resolved at your discretion)
Eventually I personally would like to take this a step further: I would like our documentation to be even more clear about a strong intention for this kind of use case as I anticipate it being a very common ask over time.
There was a problem hiding this comment.
I think overall we're heading in a good direction here, but I think we need to reiterate what feels like a more obvious question as I read more: "What is a Gateway after this, really?"
Personally I'll have to think on this quite a bit and come back around to it 🤔
k8s-ci-robot
added
the
needs-rebase
|
PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Part of #1713
Merge #3589 beforehand (to make this diff easier)
Note: this required two different client sets because if you try to generate a client set containing the stable group (
gateway.networking.k8s.io) and experimental(gateway.networking.k8s-x.io)client-gen usesgatewaypart from both api groups for naming in the client set and it creates a conflictRelease Note