Mark SPDY transport for exec/portforward/attach deprecated

[smarterclayton]

Feature Description

• One-line feature description (can be used as a release note): We now have feature parity with websockets on all streaming protocols (exec/portforward/attach), and as SPDY itself is deprecated we should move clients down to supporting only a single streaming protocol in Kubernetes - websockets. This serves as the deprecation notice for all SPDY transports that they will not be added for new features and their use is discouraged.
• Primary contact (assignee): @smarterclayton
• Responsible SIGs: sig-api-machinery, sig-cli
• Design proposal link (community repo): SPDY is deprecated. Switch to HTTP/2. kubernetes#7452
• Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred: lavalamp, pwittrock
• Approver (likely from SIG/area to which feature belongs): lavalamp
• Feature target (which target equals to which milestone):
  • Announce deprecation in 1.12 for exec and attach of SPDY
  • Beta websocket protocol in 1.12 or 1.13
  • Remove exec and attach in 1.14

[smarterclayton]

This is past the deadline but it's not adding functionality (except that we would track as bugs anyway), it's marking it deprecated clearly so users can know to switch. For 1.8 we are committed to ensuring any gaps in streaming protocols are fixed and closed, and SPDY is considered deprecated.

[smarterclayton]

Work that may be required includes ensuring Kubernetes first-party clients use websockets instead of SPDY

[jdumars]

@smarterclayton thanks for providing a solid one-line description. I'm trying to get a feel for why some feature submissions came late. And, this is only in the interest of making our release process better next time. I assume that this feature has been in-progress for a while, and it was simply a missed step to get it into the features repo?

[smarterclayton]

This is more of an announcement than a feature. It's documenting that we are starting deprecation, which should be in public documentation and impacts end clients. But it doesn't involve implementation in code. The sig had mostly agreed to deprecate it, but it didn't get added to the repo until after the deadline.

…

On Wed, Aug 16, 2017 at 10:21 AM, Jaice Singer DuMars < ***@***.***> wrote: @smarterclayton <https://github.com/smarterclayton> thanks for providing a solid one-line description. I'm trying to get a feel for why some feature submissions came late. And, this is only in the interest of making our release process better next time. I assume that this feature has been in-progress for a while, and it was simply a missed step to get it into the features repo? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#384 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABG_pyE6fRCEXlKXlcLCEV1h_pupzekCks5sYvrzgaJpZM4Ot8rz> .

[pwittrock]

@smarterclayton Do we have an item in the release notes draft for this? Announcement about draft release notes here

[idvoretskyi]

@smarterclayton so, can you confirm that the actual changes will land in 1.8? If not, please, update the milestone (assigning the "next-milestone").

[smarterclayton]

We can mark it deprecated without having a replacement. There's no harm in giving users lead time to switch, even if all elements aren't delivered.

…

On Tue, Aug 29, 2017 at 8:37 AM, Ihor Dvoretskyi ***@***.***> wrote: @smarterclayton <https://github.com/smarterclayton> so, can you confirm that the actual changes will land in 1.8? If not, please, update the milestone (assigning the "next-milestone"). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#384 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABG_p2oR-46s4jm93_jcIJVt6lW5G0Bqks5sdAYSgaJpZM4Ot8rz> .

[pwittrock]

@smarterclayton Sorry I am not sure I understood your last comment. Should this be moved out of 1.8 or closed?

[smarterclayton]

We should mark the transport deprecated for exec and attach in 1.8 at a minimum. User should switch to web sockets. Portforward will require a new backend impl (what was implemented previously is not sufficient to handle multiple sockets), so we cannot mark it deprecated until that new backend gets implemented in 1.9

…

On Thu, Sep 7, 2017 at 1:17 PM, Phillip Wittrock ***@***.***> wrote: @smarterclayton <https://github.com/smarterclayton> Sorry I am not sure I understood your last comment. Should this be moved out of 1.8 or closed? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#384 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABG_px-fcpitQ6i7RMRkzrv-mEPqrcMSks5sgCTVgaJpZM4Ot8rz> .

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[wanghaoran1988]

/lifecycle frozen

[justaugustus]

@smarterclayton
Any plans for this in 1.11?

If so, can you please ensure the feature is up-to-date with the appropriate:

• Description
• Milestone
• Assignee(s)
• Labels:
  • stage/{alpha,beta,stable}
  • sig/*
  • kind/feature

cc @idvoretskyi

[justaugustus]

/remove-lifecycle frozen

[smarterclayton]

/lifecycle frozen

This still needs to get addressed.

[fejta-bot]

Feature issues opened in kubernetes/features should never be marked as frozen.
Feature Owners can ensure that features stay fresh by consistently updating their states across release cycles.

/remove-lifecycle frozen

[justaugustus]

This feature current has no milestone, so we'd like to check in and see if there are any plans for this in Kubernetes 1.12.

If so, please ensure that this issue is up-to-date with ALL of the following information:

• One-line feature description (can be used as a release note):
• Primary contact (assignee):
• Responsible SIGs:
• Design proposal link (community repo):
• Link to e2e and/or unit tests:
• Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred:
• Approver (likely from SIG/area to which feature belongs):
• Feature target (which target equals to which milestone):
  • Alpha release target (x.y)
  • Beta release target (x.y)
  • Stable release target (x.y)

Set the following:

• Description
• Assignee(s)
• Labels:
  • stage/{alpha,beta,stable}
  • sig/*
  • kind/feature

Once this feature is appropriately updated, please explicitly ping @justaugustus, @kacole2, @robertsandoval, @rajendar38 to note that it is ready to be included in the Features Tracking Spreadsheet for Kubernetes 1.12.

---

Please note that Features Freeze is tomorrow, July 31st, after which any incomplete Feature issues will require an Exception request to be accepted into the milestone.

In addition, please be aware of the following relevant deadlines:

• Docs deadline (open placeholder PRs): 8/21
• Test case freeze: 8/28

Please make sure all PRs for features have relevant release notes included as well.

Happy shipping!

P.S. This was sent via automation

[kacole2]

Hi
This enhancement has been tracked before, so we'd like to check in and see if there are any plans for this to graduate stages in Kubernetes 1.13. This release is targeted to be more ‘stable’ and will have an aggressive timeline. Please only include this enhancement if there is a high level of confidence it will meet the following deadlines:

• Docs (open placeholder PRs): 11/8
• Code Slush: 11/9
• Code Freeze Begins: 11/15
• Docs Complete and Reviewed: 11/27

Please take a moment to update the milestones on your original post for future tracking and ping @kacole2 if it needs to be included in the 1.13 Enhancements Tracking Sheet

Thanks!

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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.

[diemus]

is kubectl use websocket now ?

[g3rzi]

what about kubelet ? from my last check it uses SPDY.