Unknown Version Interoperability Proxy

[richabanker]

Enhancement Description

• One-line enhancement description (can be used as a release note): Allow a resource request to be served by the correct apiserver in the case when there are multiple apiservers at varied versions
• Kubernetes Enhancement Proposal: https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/4020-unknown-version-interoperability-proxy
• Discussion Link: https://docs.google.com/document/d/1x9RNaaysyO0gXHIr1y50QFbiL1x8OWnk2v3XnrdkT5Y/edit#bookmark=id.zh5gxrgo2ufp
• Primary contact (assignee): richabanker
• Responsible SIGs: api-machinery
• Enhancement target (which target equals to which milestone):
  • Alpha release target (x.y): 1.28
  • Beta release target (x.y):
  • Stable release target (x.y):
• Alpha
  • KEP (k/enhancements) update PR(s):
    • KEP-4020: Unknown Version Interoperability Proxy #4015
    • KEP-4020: Unknown Version Interoperability Proxy : Remove uvip acronym from metrics/headers #4074
    • KEP-4020: Unknown Version Interoperability Proxy : Update KEP status as 'implementable' #4091
  • Code (k/k) update PR(s):
    • Add servedVersions info in StorageVersion API kubernetes#118386
    • add list of served versions to storage version kubernetes#119272
    • Unknown Version Interoperability Proxy Impl kubernetes#117740
  • Docs (k/website) update PR(s):
    • Add MVP documentation website#42147
    • Add post-release blog article about MVP website#41723

Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently.

[richabanker]

/sig api-machinery

[deads2k]

/milestone v1.28
/label lead-opted-in

[Atharva-Shinde]

/stage alpha

[ruheenaansari34]

Hello @richabanker 👋, 1.28 Enhancements team here.

Just checking in as we approach enhancements freeze on 1:00 UTC on Friday 16th June 2023.

This enhancement is targeting for stage alpha for 1.28 (correct me, if otherwise)

Here's where this enhancement currently stands:

• KEP readme using the latest template has been merged into the k/enhancements repo.
• KEP status is marked as implementable for latest-milestone: 1.28
• KEP readme has a updated detailed test plan section filled out
• KEP readme has up to date graduation criteria
• KEP has a production readiness review that has been completed and merged into k/enhancements.

For this KEP, we would need to take care of:

• Merging KEP-4020: Unknown Version Interoperability Proxy #4015

The status of this enhancement is marked as at risk. Please keep the issue description up-to-date with appropriate stages as well. Thank you!

[Atharva-Shinde]

Hey @richabanker
With all the KEP requirements in place and merged into k/enhancements, this enhancement is all good for the upcoming enhancements freeze. 🚀

The status of this enhancement is marked as tracked. Please keep the issue description up-to-date with appropriate stages as well. Thank you!

[AdminTurnedDevOps]

Hey @richabanker

1.28 Docs Shadow here.

Does this enhancement work planned for 1.28 require any new docs or modification to existing docs?

If so, please follows the steps here to open a PR against dev-1.28 branch in the k/website repo. This PR can be just a placeholder at this time and must be created before Thursday 20th July 2023.

Also, take a look at Documenting for a release to get yourself familiarize with the docs requirement for the release.

Thank you!

[richabanker]

Thanks @AdminTurnedDevOps, added a placeholder PR kubernetes/website#41723

Edit: modified above PR to a blog PR, and created a new documentation PR here kubernetes/website#42147

[ruheenaansari34]

Hey again @richabanker 👋
Just checking in as we approach Code freeze at 01:00 UTC Friday, 19th July 2023.

I don't see any code (k/k) update PR(s) in the issue description so if there are any k/k related PR(s) that we should be tracking for this KEP please link them in the issue description above.

As always, we are here to help if any questions come up. Thanks!

[richabanker]

Hi @ruheenaansari34, thanks for the reminder. Updated the issue description.

[richabanker]

All code update PRs are merged for this feature.

[Atharva-Shinde]

Hey @richabanker 👋 Enhancements Lead here,
With kubernetes/kubernetes#118386,
kubernetes/kubernetes#119272 and
kubernetes/kubernetes#117740 merged as per the issue description, this enhancement is now tracked for v1.28 Code Freeze! Thanks

[Rishit-dagli]

Hello @richabanker wave: please take a look at Documenting for a release - PR Ready for Review to get your docs PR ready for review before Tuesday 25th July 2023. Thank you!

Ref: kubernetes/website#41723

[Ritikaa96]

I get the name was changed as per discussion here
Will the feature gate: UnknownVersionInteroperabilityProxy be renamed as well?

[richabanker]

I get the name was changed as per discussion here Will the feature gate: UnknownVersionInteroperabilityProxy be renamed as well?

I would prefer consistency across docs and code, so I think we should change the feature gate name as well. But since its code freeze right now, that change can happen after the freeze is lifted. @jpbetz what are your thoughts on this?

[jpbetz]

I get the name was changed as per discussion here Will the feature gate: UnknownVersionInteroperabilityProxy be renamed as well?

I would prefer consistency across docs and code, so I think we should change the feature gate name as well. But since its code freeze right now, that change can happen after the freeze is lifted. Joe Betz what are your thoughts on this?

I would also prefer the consistency.

But once 1.28.0 is published, we're forever stuck with the name for the 1.28 minor version. I'm also not convinced that renaming it to a more consistent name in 1.29 is a net benefit to users.

This ship may have already sailed.

[Ritikaa96]

I get the name was changed as per discussion here Will the feature gate: UnknownVersionInteroperabilityProxy be renamed as well?

I would prefer consistency across docs and code, so I think we should change the feature gate name as well. But since its code freeze right now, that change can happen after the freeze is lifted. Joe Betz what are your thoughts on this?

I would also prefer consistency.

But once 1.28.0 is published, we're forever stuck with the name for the 1.28 minor version. I'm also not convinced that renaming it to a more consistent name in 1.29 is a net benefit to users.

This ship may have already sailed.

Noted. FWIW if the feature gate and feature name are the same, it will be easier for a user to remember (and not confused in some rare cases) which feature gate they needed to enable when kube - apiserver is started. It might be a matter of user convenience. Though I understand the reasoning behind leaving it as is due to the code freeze.

[npolshakova]

/remove-label lead-opted-in

[salehsedghpour]

Hello 👋 1.30 Enhancements Lead here,

I'm closing milestone 1.28 now,
If you wish to progress this enhancement in v1.30, please follow the instructions here to opt in the enhancement and make sure the lead-opted-in label is set so it can get added to the tracking board and finally add /milestone v1.30. Thanks!

/milestone clear

[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

[jpbetz]

/remove-lifecycle stale

[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

[BenTheElder]

/remove-lifecycle stale

[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