Re: Annual patch support lifecycle

24 views
Skip to first unread message

Stephen Augustus

unread,
May 19, 2020, 7:15:47 PM5/19/20
to Roger Klorese, Tim Pepper, Kubernetes Release Team, Kubernetes developer/contributor discussion, kubernetes-sig-release
To be clear, this is NOT about minting LTS releases/enabling a direct upgrade for say 1.16 --> 1.20.

This KEP is about extending the support cycle of individual releases.

Please review the KEP and let us know if there's something that could use further clarification in the verbiage.

-- Stephen

On Tue, May 19, 2020, 19:08 Roger Klorese <roger....@suse.com> wrote:

I’m confused by the term “annual support” – some might interpret that as the ability to upgrade annually and not step through intervening releases. We’re talking about a 12-month (or 4-release? Does it depend on what we do with frequency?) support policy, right?

 

-- 

signature_232597712

 

Roger Klorese 
Senior Product Manager, SUSE CaaS Platform

 

SUSE

 

+1 206 217 7432 office
+1 425 444 5493 mobile

roger....@suse.com

 

255 King Street Suite 800
Seattle WA 98104 US

 

www.suse.com

GPG Key: 46D6 297E D349 0A68 9BB7 7362 9454 9852 704C 64CA

 

LinkedIn | Instagram | Twitter | YouTube

 

 

From: <kuberne...@googlegroups.com> on behalf of Stephen Augustus <steph...@agst.us>
Date: Tuesday, May 19, 2020 at 4:00 PM
To: Tim Pepper <tpe...@vmware.com>, Kubernetes Release Team <kubernetes-...@googlegroups.com>
Cc: Kubernetes developer/contributor discussion <kuberne...@googlegroups.com>, kubernetes-sig-release <kubernetes-...@googlegroups.com>
Subject: Re: Annual patch support lifecycle

 

I'm in favor of both officially starting annual support in 1.19 AND retroactively enabling it for Kubernetes 1.16 through 1.18.

 

Given we've set a lazy consensus timeout for Friday, which is after Enhancements Freeze, I'm also submitting this to the Release Team as an exception for the 1.19 cycle.

·         Enhancement name: Kubernetes Annual Support

·         Enhancement status (alpha/beta/stable): Stable -- policy-based KEP

·         SIG: Release

·         k/enhancements repo issue #: https://github.com/kubernetes/enhancements/issues/1498

·         PR #’s: https://github.com/kubernetes/enhancements/pull/1782

·         Additional time needed (in days): 3 days post-Enhancements Freeze (targeting implementable for Friday, May 22)

-- Stephen

 

On Tue, May 19, 2020 at 12:30 PM Tim Pepper <tpe...@vmware.com> wrote:

It’s been brought to my attention that there’s still a point of insufficient clarity here:

 

There are two topics for discussion so folks can express support or concern separately and still hopefully make progress on either or both without one possibly turning into a blocker for the other:

·      1.19 and newer receiving annual patch support

o  Provisional KEP -> implementable (link [1])

o  In discussion for 1.19 release milestone since January 2020

o  lazy consensus period ending a noon US Pacific time on Friday May 22, 2020

·      1.18, 1.17, 1.16 receiving annual patch support

o  k-dev discussion (link [2])

o  In discussions from April/May 2020 given new COVID-19 context

o  lazy consensus period ending a noon US Pacific time on Friday May 22, 2020

 

[1] https://github.com/kubernetes/enhancements/pull/1782

[2] https://groups.google.com/d/msg/kubernetes-dev/IVpiIOZ4WcM/I_LGDpNkAgAJ

 

-- 

Tim Pepper

Orchestration Lead

VMware Open Source Technology Center

 

From: <kuberne...@googlegroups.com> on behalf of Tim Pepper <tpe...@vmware.com>
Date: Friday, May 15, 2020 at 11:46 AM
To: "kuberne...@googlegroups.com" <kuberne...@googlegroups.com>
Subject: Annual patch support lifecycle

 

Following much discussion with SIGs and the community over the past nearly two years, WG LTS is proposing that the previously merged as "provisional" KEP:

https://github.com/kubernetes/enhancements/tree/master/keps/sig-release/1498-kubernetes-yearly-support-period

 

is indeed implementable ahead of the 1.19 enhancements freeze:

https://github.com/kubernetes/enhancements/pull/1782

 

As proposed, this is a tracked enhancement for the 1.19 milestone in keeping with an earlier intent to cover 1.19 and newer.

 

But...:

 

Additional more recent discussion on the k-dev list:

https://groups.google.com/d/msg/kubernetes-dev/IVpiIOZ4WcM/I_LGDpNkAgAJ

 

and subsequent discussion this week at the WG LTS meeting:

* video: https://youtu.be/lkDYaqPLRDM

* minutes: https://docs.google.com/document/d/1J2CJ-q9WlvCnIVkoEo9tAo19h08kOgUJAS3HxaSMsLA/edit#

 

aaand subsequent discussion this week on Slack:

https://kubernetes.slack.com/archives/CDTMPM75W/p1589381587015300

 

leads us to a place where WG LTS and SIG Release are also in support of retroactively extending planned support for 1.18, 1.17, and 1.16.  General consensus has been this is viable to attempt as a community, 1.16 marks a first point after some notable deprecation changes in favor of stable APIs, and in the context of operational complexities our project's downstream consumers are facing due to COVID-19 there is increased desire for less "must upgrade" pressure multiple times each year due to a release being end-of-support.

 

The 1.16 release would normally have reached end of patch support in June, so it may seem there isn't not an immediate pressure for a choice.  Still I would like to propose a lazy consensus period ending a noon US Pacific time on Friday May 22, 2020 to ensure a decision does not move forward without any possibly remaining major concerns having one more opportunity to be raised, and then also leaves time to communicate more broadly the decision for any operators looking at the need to move past 1.16 in the coming weeks.

 

(Note: Discussion regarding the number of releases per year can similarly continue on its own pace to eventual resolution.)

 

-- 

Tim Pepper

Orchestration Lead

VMware Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/08ED552B-7EDA-46F8-9B23-4094C7397E20%40vmware.com.

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/7A15D6BD-B4D6-45F5-BFF5-A9ABB6EDE084%40vmware.com.

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAOqU-DQhc0JTDFNn10WFatAYr-0dx9_yzhv67RV-5gb1mxs-ag%40mail.gmail.com.

Roger Klorese

unread,
May 19, 2020, 7:15:47 PM5/19/20
to Stephen Augustus, Tim Pepper, Kubernetes Release Team, Kubernetes developer/contributor discussion, kubernetes-sig-release

Stephen Augustus

unread,
May 19, 2020, 7:15:47 PM5/19/20
to Tim Pepper, Kubernetes Release Team, Kubernetes developer/contributor discussion, kubernetes-sig-release
I'm in favor of both officially starting annual support in 1.19 AND retroactively enabling it for Kubernetes 1.16 through 1.18.

Given we've set a lazy consensus timeout for Friday, which is after Enhancements Freeze, I'm also submitting this to the Release Team as an exception for the 1.19 cycle.
-- Stephen

On Tue, May 19, 2020 at 12:30 PM Tim Pepper <tpe...@vmware.com> wrote:

It’s been brought to my attention that there’s still a point of insufficient clarity here:

 

There are two topics for discussion so folks can express support or concern separately and still hopefully make progress on either or both without one possibly turning into a blocker for the other:

  • 1.19 and newer receiving annual patch support
    • Provisional KEP -> implementable (link [1])
    • In discussion for 1.19 release milestone since January 2020
    • lazy consensus period ending a noon US Pacific time on Friday May 22, 2020
  • 1.18, 1.17, 1.16 receiving annual patch support
    • k-dev discussion (link [2])
    • In discussions from April/May 2020 given new COVID-19 context

Taylor Dolezal

unread,
May 21, 2020, 5:23:34 PM5/21/20
to kubernetes-sig-release

Hello Roger and Stephen,


Thank you for submitting an exception request. We are APPROVING this request.


Please keep in mind the following deadlines as you continue to work on this enhancement:


  • Docs PRs must be ready for review by Monday, June 29th
  • Docs must be complete, all PRs reviewed and ready to merge by Thursday, July 9th


I hope you’re doing well, and thank you for all of your hard work in our community!


Regards,


Taylor Dolezal

1.19 Release Lead

To unsubscribe from this group and stop receiving emails from it, send an email to kuberne...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kuberne...@googlegroups.com.

Stephen Augustus

unread,
May 22, 2020, 9:38:01 AM5/22/20
to Taylor Dolezal, kubernetes-sig-release
Thanks Taylor!!

You received this message because you are subscribed to the Google Groups "kubernetes-sig-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-re...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-release/6703fc1d-48d3-4951-aa8c-e1ee7dd9a7e7%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages