kubernetes-sigs
GEP: TLSRoute
Although TLSRoute was created prior to GEPs, we are retroactively creating this issue to track the status of this resource.
I would love it if the TLSRoute were part of the standard offerings rather than the experimental offerings. Right now we can't use the managed Gateway API in GKE because of this.
I think that TLSRoute just needs more conformance tests to be graduated. @robscott ?
@robscott @youngnick I propose that we make no changes to the TLSRoute at the moment. Do we still need a GEP document if that is the case?
Hmm, good question, this is a weird situation because of the exception to the process TLSRoute has. We currently don't have any GEP documenting what TLSRoute is actually for. Feels like maybe we could use that going forward? @robscott, @shaneutt, any thoughts?
We have a deferred state which really seems to capture where we are at with this one. I'm in favor of marking it deferred for now so people understand that there's simply no motion on it. I would also be in favor of us adding a process so that deferred things eventually get deprecated if nobody comes along to pull them back out of deferred, as we have limited bandwidth and we're not serving our community or our users best if we have several bits that are all hanging around in various states of decay.
We have a deferred state which really seems to capture where we are at with this one. I'm in favor of marking it deferred for now so people understand that there's simply no motion on it. I would also be in favor of us adding a process so that deferred things eventually get deprecated if nobody comes along to pull them back out of deferred, as we have limited bandwidth and we're not serving our community or our users best if we have several bits that are all hanging around in various states of decay.
+1. We may probably want to use the same approach for https://github.com/kubernetes-sigs/gateway-api/issues/2645 and https://github.com/kubernetes-sigs/gateway-api/issues/2644?
We have a deferred state which really seems to capture where we are at with this one. I'm in favor of marking it deferred for now so people understand that there's simply no motion on it. I would also be in favor of us adding a process so that deferred things eventually get deprecated if nobody comes along to pull them back out of deferred, as we have limited bandwidth and we're not serving our community or our users best if we have several bits that are all hanging around in various states of decay.
@shaneutt As of yesterday, @robscott added this to https://github.com/orgs/kubernetes-sigs/projects/20/views/1 because I volunteered to take it on. It was deferred, but it is no longer deferred.
@youngnick I was hoping, because this is a relatively well documented component, that we could get away with out a GEP.
I'm gathering all the TLSRoute-related issues under an epic issue and I think that as a first step, we need to figure out this one. I agree with what @candita wrote here about moving on without a GEP given the current status of the API and our will to promote it in time for 1.2.
What do you think about it?
@robscott @shaneutt @youngnick
I hate to be the one pushing for something that might seem very ceremonial, but I personally would prefer that we have a GEP. If nothing else, just to document the history, progress and decisions over the years. There are benefits to this posterity:
- it can be easily found along with other features and APIs in the list of GEPs by any interested reader
- we have a legend which collects all the point-in-time context about the feature for us in one place
- nobody can say we didn't do it
After discussing in the Gateway API meeting, we agreed upon creating a simple GEP with the following:
- overview of the API
- the whys of having it and the differentiators from
TCPRoute - answers to the open questions we still have in the API (e.g., allowing
TerminatealongsidePassthrough)
@candita I'm going to assign myself to the issue and unassign you as we agreed on Slack and in the Gateway API meeting.
/assign /unassign @candita
@mlavacca we had an inquiry about TLSRoute today (as well as TCPRoute and UDPRoute) with IoT and similar resource form-factor use cases. E.g. OPC-UA (Industrial IoT ingest of data from machines), and camera/video feed routing.
@mlavacca we had an inquiry about TLSRoute today (as well as TCPRoute and UDPRoute) with IoT and similar resource form-factor use cases. E.g. OPC-UA (Industrial IoT ingest of data from machines), and camera/video feed routing.
Apologies for the terrible delay. I somehow lost track of this message. It's interesting, though. Is it still relevant? In that case, would you be able to provide some additional details about the expectations, etc.?
@mlavacca we had an inquiry about TLSRoute today (as well as TCPRoute and UDPRoute) with IoT and similar resource form-factor use cases. E.g. OPC-UA (Industrial IoT ingest of data from machines), and camera/video feed routing.
Apologies for the terrible delay. I somehow lost track of this message. It's interesting, though. Is it still relevant? In that case, would you be able to provide some additional details about the expectations, etc.?
It's a use case at Red Hat, we have a small form-factor cluster platform that is interested in integrating Gateway API, and asked about TLSRoute and other xRoutes. You can ignore this.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale