GEP: Backend Protocol Selection

[dprotaso]

/kind gep

This is an attempt to separate out the backend protocol selection from GEP-1282. This is similar to how TLS use-cases are being split out into GEP-1897

What would you like to be added:

The ability to express the protocols supported by backends.

Why this is needed:

Not all implementation support automatic protocol selection. Even in some cases protocols are disabled without an explicit opt-in (ie. websockets). Thus application developers need the ability specify the protocol of their applications.

[dprotaso]

/assign @dprotaso

[dprotaso]

For those following GEP PR is out - #1979

[shaneutt]

Since the GEP already exists and because it's a GEP it seems reasonable to consider this accepted:

/triage accepted

However, it doesn't seem clear to me that this is something we must sort out prior to GA (though I invite arguments to the contrary) so at least for now we wont consider this a blocker for GA and it will have a lower priority than GA-oriented work:

/priority backlog

[dprotaso]

@shaneutt the GA backlog has #1282 - you could say this GEP and #1897 are part the fallout of that original GEP

[shaneutt]

ACK

Ultimately it's just not clear that this is something we must have for GA 🤔

Since you're working on it anyway, let's go ahead and track it on the board. But we should probably take another look at what it's gonna take to implement and do some planning and prioritization then.

[robscott]

Leaving this open until this GEP either graduates to standard or is removed from the API.

/kind gep
/reopen

[k8s-ci-robot]

@robscott: Reopened this issue.

In response to this:

Leaving this open until this GEP either graduates to standard or is removed from the API.

/kind gep
/reopen

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/test-infra repository.

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[k8s-triage-robot]

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/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was 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

[aviallon]

/close
Implemented by #1979

[k8s-ci-robot]

@aviallon: Closing this issue.

In response to this:

/close
Implemented by #1979

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.