@erictune fyi

@soltysh Auf welcher SIG kann ich diese Funktion besprechen? Ich möchte eine längere Diskussion über Ressourcen von Drittanbietern für diese Funktion führen und warum wir der Meinung sind, dass sie in den Kern integriert werden muss.

Lassen Sie uns vorerst SIG-Apps verwenden. Es gab dort nicht viele Diskussionen über Controller, die ich gesehen habe, aber lasst uns versuchen, zu sehen, wie es läuft.

Wird dies für den Ausschluss aus dem Kern in Betracht gezogen? Ich hatte gedacht, der Vorschlag sei bereits angenommen worden.

@gtaylor ist noch nichts entschieden. Derzeit wird es Teil der Alpha-Gruppe im Batch sein, was passiert, wenn dies zu stabileren migriert wird, ist noch nicht bekannt.

Mein Verständnis war, dass dies in Core akzeptiert wurde, während Job-Workflow für Core abgelehnt wurde. Eigentlich hatten wir ursprünglich geplant, es in 1.3 zu haben.

@davidopp mein Kommentar basierte auf der Diskussion, die wir zuvor mit @philips @erictune hier hatten . Obwohl ich persönlich es vorziehen würde, dass SJ im Kern bleibt :Sonnenbrille:

@soltysh Ich habe den Kommentar so interpretiert, dass er im Kern enthalten wäre (basierend auf der Erwähnung von Alpha / Beta und der Aussage "Wenn jemand eine Drittanbieterversion von ScheduledJob weit vor 1.4 produzieren und zeigen würde, dass dies vergleichbar nützlich ist , das wäre ein überzeugendes Argument für den letztgenannten Pfad", wobei der letztgenannte Pfad ThirdParty war).

@davidopp, dieser Kommentar wurde gemacht, als ich dachte, dass SJ in 1.4 Beta sein würde. Jetzt geht es in die Alpha in 1.4. Die Philosophie war, dass wir ein Alpha-Feature aus irgendeinem Grund abbrechen können, aber wir sollten eine ziemlich hohe Latte für das Abbrechen eines Beta-Features haben.

Außerdem an alle, die an SJ arbeiten: Wir sollten trotz des obigen Gesprächs mit Hochdruck weiterarbeiten. Ein Großteil der Arbeit wird in beide Richtungen zutreffen, und wir müssen den Benutzern eine Art von Funktion zur Verfügung stellen, damit sie Feedback geben können.

Alle SJ-Arbeiten laufen auf Hochtouren , das einzige verbleibende Problem besteht (hoffentlich) darin, https://github.com/kubernetes/kubernetes/pull/29187 zu haben. Ich hoffe, dieses Problem heute mit @smarterclayton oder über die Wochenende und lassen es zusammenführen, also sollten wir nächste Woche sehen, wie einer nach dem anderen SJ PRs zusammengeführt wird.

@soltysh : es sieht so aus, als ob #29187 zusammengeführt wurde, bedeutet das, dass die nächste 1.4-Alpha-Version SJ spielbereit haben wird?

@eghobo das ist der Plan.

Dies erfordert Dokumente in k8s.io, aber es sieht so aus, als ob Code enthalten ist. Großartig!

+100

@soltysh gelten die Dokumente als erledigt oder fügen Sie weitere Beispiele / Tutorials hinzu? Wenn die Dokumente fertig sind, können wir das Kontrollkästchen "Dokumente" aktivieren

@janetkuo Normalerweise markiere ich sie als erledigt, wenn sie zusammengeführt werden. In diesem Sinne habe ich den einen gegen Branch 1.4 überprüft, der andere wartet auf die Zusammenführung.

Da dies in CronJobs umbenannt wurde, werde ich den Titel aktualisieren, um diese Änderung ebenfalls widerzuspiegeln.

Wird das in der Beta für 1.5 sein?

@ConorNevin leider nicht, siehe die Beta-Anforderungen in der angehen müssen, um es in die Beta zu befördern. Entschuldigung :enttäuscht: Hilfe bei der Behebung dieser Probleme wird jedoch dringend empfohlen :smiley:

Es gibt immer noch https://github.com/wercker/cronetes , wenn man jetzt Cronjob-ähnliche Funktionen benötigt, ohne die Möglichkeit, Alpha-Funktionen auszuführen.

Würde das Feature höchstens laufen, wenn es in CronJobs implementiert ist?
Ich sehe, dass es nicht in der Alpha enthalten war - https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/scheduledjob.md#decision

@vinay-g irgendwann, ich denke schon, aber ich habe keine Ahnung, wann das sein wird. Hilfe ist aber immer willkommen :)

Diese Funktion ist immer noch an Meilenstein 1.4 angehängt, und die Kalkulationstabelle für Meilensteine ​​​​1.6 erwähnt nichts über Cron/ScheduledJobs.

Ist dies noch im Zeitplan für eine 1.6 Beta-Version? Als GKE-Kunde würde ich _liebe_, damit beginnen, alle unsere Out-of-Cluster-Crons in den Cluster selbst zu verschieben (ohne Cronetes zu verwenden).

In der Tat. Diese dringend benötigte Funktion hat sich seit Version 1.3 in die Länge gezogen, wenn ich mich nicht irre. Ich selbst bin in der gleichen Position - kann es kaum erwarten, bis es rüberkommt, damit ich die On-Premise-Jobs auf GKE ziehen kann.

Ich habe den Meilenstein auf den nächsten geändert, es ist noch einiges an Arbeit für CronJobs zu tun, um sie zu stabilisieren, ich würde es gerne aggressiver vorantreiben, aber leider ist der Zeitmangel der Hauptfaktor, den ich kann' t atm.

wird imagePullSecrets in der ChronJob-Vorlage unterstützt?

@soltysh danke für die Aktualisierung.

wird imagePullSecrets in der ChronJob-Vorlage unterstützt?

@avaranovich sollte sein, da wir einen Pod aus der Vorlage erstellen. Wenn dies nicht der Fall ist, füllen Sie bitte ein Problem aus und markieren Sie mich dort.

Hey @soltysh . Ich würde es gerne bald in dieser Beta sehen! Ich möchte helfen, bin mir aber nicht sicher, was hier erforderlich ist / der nächste Schritt. Können Sie die Checkliste bitte ein wenig verfeinern (evtl. relevante Themen/Dokumente erstellen/aufzeigen)? 🙂

@ApsOps vor der Beta müssen wir definitiv die serverseitige Entfernung implementieren, die Google App Engine und das Chronos-Format unterstützen und die Verwendung von Zeitzonen zulassen. Wahrscheinlich wäre es schön, die Bugs zu beseitigen, die mit CronJobs zusammenhängen. Ich bezweifle, dass es für 1.6 machbar ist, aber für die nächsten Releases ist es machbar. Am wichtigsten ist es, mich in jeder Ausgabe/PrP zu markieren, die Sie zu diesem Thema erstellen.

@soltysh

Ich denke, einige Leute verwenden CronJobs so, wie sie jetzt sind, und ich höre meistens "Wann wird es Beta sein", und nicht so viele Probleme mit Alpha.

Wenn wir glauben, dass wir serverseitige Entfernung, App-Engine und Chronos sowie Zeitzonen hinzufügen können, ohne die aktuelle API zu beschädigen, dann sehe ich keinen Grund, die Beta jetzt nicht zu verschieben und diese Dinge vor der GA hinzuzufügen.

+1 Für CronJobs-Beta. Sobald sie Beta sind und das Zurücksetzen des Clusters nicht erforderlich ist, wäre dies ein Killing-Feature für eine Reihe unserer Workflows hier.

Wir freuen uns darauf, dass diese Funktion in die Beta-Phase geht und wir hatten keine Probleme mit der Alpha.

Persönlich würde ich es vorziehen, zumindest den Entfernungsteil anzugehen, es gibt bereits jemanden, der daran arbeitet, konfigurierbare Grenzen für die Anzahl erfolgreicher und fehlgeschlagener Jobs hinzuzufügen, die zurückgelassen werden. Und die Entfernung ist ein Schlüsselelement, denke ich. Lassen Sie uns die Option besprechen, dies während des bevorstehenden sig-apps-Aufrufs für 1.6 oder 1.7 in die Beta zu verschieben. @michelleN kann das als Thema hinzugefügt werden?

@NiclasHedam wurden Ihre Probleme angegangen, gibt es offene Probleme, die ich nicht gesehen habe, können Sie mich darin öffnen / anpingen?

Sie wurden alle in 1.4.7 angesprochen

Gibt es einen Plan, dies GUI-Unterstützung hinzuzufügen? Aktuell sehe ich zum Beispiel folgendes:

[obatori<strong i="6">@obatori</strong>:~] >> kubectl get cronjobs
NAME         SCHEDULE      SUSPEND   ACTIVE    LAST-SCHEDULE
cron-hello   */1 * * * *   False     0         Tue, 25 Jul 2017 09:11:00 -0400
hello        0 22 * * *    False     0         <none>

In der GUI kann ich jedoch nur die historische Ausführung sehen, nicht die aktuellen Jobs und den damit verbundenen Zeitplan? Außerdem listet kubectl get cronjob / cronjobs als gültige Ressourcentypen auf, obwohl sie tatsächlich funktionieren.

Natürlich könnte mir etwas fehlen, aber eine gründliche Suche in den verschiedenen Teilen der GUI hat mir meine Jobs noch nicht gezeigt!

@oscarbatori Bitte öffnen Sie ein Problem im kubernetes/dashboard-Repository und fragen Sie nach dieser Verbesserung.

@luxas wird es tun, danke für Ihre schnelle Antwort.

@soltysh Können Sie bitte die k8s.io Docs PR für diese Funktion für die Version 1.8 hier hinzufügen: https://docs.google.com/spreadsheets/d/1AFksRDgAt6BGA3OjRNIiO3IyKmA-GU7CXaxbihy48ns/edit#gid =0

@soltysh Diese Funktion ist in der https://docs.google.com/spreadsheets/d/1AFksRDgAt6BGA3OjRNIiO3IyKmA-GU7CXaxbihy48ns/edit#gid =0, aber es ist kein Meilenstein von 1,8 zugewiesen.

Ist diese Funktion auf 1.8 ausgerichtet?

@idvoretskyi teilweise war die Beförderung zur Beta auf 1,8 ausgerichtet und fand in diesem Zeitrahmen statt. Dafür gibt es keinen Meilenstein, b/c gibt es noch keinen klaren Plan für den zukünftigen Aufstieg in den Stall.

@soltysh verstanden. Also, ich werde mit 1,8 Meilenstein markieren.

Vielen Dank!

@idvoretskyi Da es eine Funktion gibt ( Möglichkeit zum manuellen Starten von CronJobs ) werden wir versuchen, in die Version 1.9 zu CronJobs zu gelangen. Ich füge hier 1.9 Milstone hinzu, ist das in Ordnung? Ich möchte kein weiteres Problem erstellen, nur um dieses einzelne Element zu verfolgen.

Ich werde wahrscheinlich versuchen, die ursprüngliche Beschreibung zu aktualisieren, damit sie die eingeführten (auch geplanten) Änderungen für CronJob-bezogene Funktionen widerspiegelt.

@soltysh irgendwelche Fortschritte beim Update der Funktionsbeschreibung? :)

Bitte verwenden Sie die neue Vorlage - https://github.com/kubernetes/features/blob/master/ISSUE_TEMPLATE.md

@soltysh :wave: Bitte im 1.9 Feature Tracking Board angeben
ob diese Funktion eine Dokumentation benötigt. Wenn ja, öffnen Sie bitte

@idvoretskyi Da es eine Funktion gibt ( Möglichkeit zum manuellen Starten von CronJobs ) werden wir versuchen, in die Version 1.9 zu gelangen, die sich auf CronJobs bezieht, ich werde hier 1.9 Milstone hinzufügen

Diese spezielle Funktion wird es in 1.9 nicht geben. Sollen wir den Meilenstein auf 1.10 verschieben?

Für den Meilenstein 1.10 gibt es 3 Themen:

1. TimeZone-Unterstützung in CronJob (https://github.com/kubernetes/kubernetes/pull/47266) - @iterion siehe diesen Kommentar, um zu begründen, warum
2. Manuelle Instanziierung von CronJob (https://github.com/kubernetes/kubernetes/pull/53988) - @erhudy
3. (?) Schreiben Sie den Controller neu, um gemeinsam genutzte Informanten zu verwenden (https://github.com/kubernetes/kubernetes/issues/17130) - @soltysh

@soltysh und noch Beta, oder?

Stabile Anforderungen:

1. Geteilte Informanten im Controller (https://github.com/kubernetes/kubernetes/issues/17130)
2. Unterstützt verschiedene Zeitformate ( ISO 8601 , GCE-Zeitformat ).

Die @soltysh- Funktionsverfolgungstabelle zeigt an, dass Dokumentaktualisierungen erforderlich sind. Ist dies tatsächlich der Fall? Wenn ja, holen Sie bitte Ihre PR so schnell wie möglich ein (heute ist die Frist für die Dokumentation, aber ich war nicht gut darin, die Leute zu benachrichtigen). Wenn nicht, könnten Sie bitte die Tabelle aktualisieren? Vielen Dank!

@soltysh docs ping -- Frist für das Zusammenführen von Docs-PRs ist dieser Freitag, der 9. März. Siehe vorherigen Kommentar. Vielen Dank! /cc @idvoretskyi

@ Bradamant3 Entschuldigung für die Verzögerung, für diese Funktion ist kein Doc-Update erforderlich. Ich habe einen Kommentar in der verlinkten Tabelle hinzugefügt.

@soltysh
Gibt es Pläne dafür in 1.11?

Wenn dies der Fall ist, können Sie bitte sicherstellen, dass die Funktion mit den entsprechenden Informationen auf dem neuesten Stand ist:

• Beschreibung
• Meilenstein
• Bevollmächtigte(n)
• Etiketten:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

Gibt es Pläne dafür in 1.11?

Controller neu schreiben, um https://github.com/kubernetes/kubernetes/issues/17130 zu erfüllen, aber ich habe immer noch Probleme mit der Zeit. Das ist also eher Wunschdenken als konkrete Pläne :wink:

Okay cool. Ich werde den Meilenstein auf diesem verschieben.

Gibt es ein Update zu den Plänen, dies in den Stall zu bringen? Ich gehe davon aus, dass dies aufgrund fehlender Meilensteine ​​​​für 1.12 nicht passieren wird?

Gibt es ein Update zu den Plänen, dies in den Stall zu bringen? Ich gehe davon aus, dass dies aufgrund fehlender Meilensteine ​​​​für 1.12 nicht passieren wird?

@soltysh ^^

@spiffxp -- Ich habe vorhin mit

Hi
Diese Verbesserung wurde bereits nachverfolgt, daher würden wir gerne prüfen, ob es Pläne für diese Erweiterung der Phasen in Kubernetes 1.13 gibt. Diese Version soll "stabiler" sein und einen aggressiven Zeitplan haben. Bitte fügen Sie diese Erweiterung nur ein, wenn ein hohes Maß an Vertrauen besteht, dass die folgenden Fristen eingehalten werden:

• Docs (offene Platzhalter-PRs): 11/8
• Code-Slush: 11/9
• Code-Einfrieren beginnt: 11/15
• Vollständige und überprüfte Dokumente: 27.11

Bitte nehmen Sie sich einen Moment Zeit, um die Meilensteine ​​in Ihrem ursprünglichen Beitrag für die zukünftige Verfolgung zu aktualisieren und pingen Sie Tracking-Blatt für 1.13 Verbesserungen aufgenommen werden müssen

Vielen Dank!

@kacole2 Dies bewegt sich nirgendwohin, bis wir das größte Problem mit dem Cronjob-Controller behoben haben, bei dem es sich um geteilte Informanten handelt. Wir werden dieses Thema beim nächsten SIG-Apps-Call besprechen.

Die Probleme veralten nach 90 Tagen Inaktivität.
Markieren Sie das Problem mit /remove-lifecycle stale .
Veraltete Ausgaben verrotten nach weiteren 30 Tagen Inaktivität und werden schließlich geschlossen.

Wenn dieses Problem jetzt sicher geschlossen werden kann, tun Sie dies bitte mit /close .

Senden Sie Feedback an sig-testing, kubernetes/test-infra und/oder fejta .
/Lebenszyklus veraltet

Abgestandene Ausgaben verrotten nach 30 Tagen Inaktivität.
Markieren Sie das Problem mit /remove-lifecycle rotten .
Faule Probleme werden nach weiteren 30 Tagen Inaktivität geschlossen.

Wenn dieses Problem jetzt sicher geschlossen werden kann, tun Sie dies bitte mit /close .

Senden Sie Feedback an sig-testing, kubernetes/test-infra und/oder fejta .
/Lebenszyklus faul

Wie wäre es mit einem Präfix für Jobs wie 20190212T2157Z

/remove-lifecycle faul

/Lebenszyklus eingefroren

Erweiterungsprobleme, die in kubernetes/enhancements geöffnet wurden, sollten niemals als eingefroren markiert werden.
Besitzer von Erweiterungen können sicherstellen, dass die Erweiterungen aktuell bleiben, indem sie ihren Status über die Release-Zyklen hinweg konsistent aktualisieren.

/remove-lifecycle eingefroren

Hallo @soltysh , ich bin der Enhancement Lead für 1.15. Wird diese Funktion in 1.15 die Alpha-/Beta-/Stable-Phasen abschließen? Bitte lassen Sie es mich wissen, damit es richtig verfolgt und der Tabelle hinzugefügt werden kann. Wie üblich muss ein KEP zusammengeführt werden, bevor dies fortgesetzt werden kann.

Sobald die Codierung beginnt, listen Sie bitte alle relevanten k/k-PRs in dieser Ausgabe auf, damit sie ordnungsgemäß nachverfolgt werden können.

Als Benutzer nutze ich diese Ressourcenart seit langem erfolgreich. Ich habe keine größeren Probleme mit der API gesehen. Ist es an der Zeit, es als GA zu versenden?

Wir arbeiten an einem KEP für den Abschluss

Okay. Danke für das Update.

Hallo @kow3ns @soltysh , ich bin der 1.16 Enhancement Lead. Wird diese Funktion in 1.16 die Alpha-/Beta-/Stable-Phasen abschließen? Bitte lassen Sie es mich wissen, damit es der 1.16 Tracking-Tabelle hinzugefügt werden kann. Wenn dies nicht der Fall ist, werde ich es aus dem Meilenstein entfernen und das nachverfolgte Label ändern.

Wenn die Codierung beginnt oder bereits erfolgt ist, listen Sie bitte alle relevanten k/k-PRs in dieser Ausgabe auf, damit sie ordnungsgemäß nachverfolgt werden können.

Zur Erinnerung: Jede Verbesserung erfordert eine KEP in einem implementierbaren Zustand mit Abschlusskriterien, die die Anforderungen jeder Alpha-/Beta-/Stable-Phase erklären.

Meilensteintermine sind Enhancement Freeze 30.07. und Code Freeze 29.08.

Dankeschön.

Hallo @soltysh @kow3ns , 1.17 Verbesserungen Schatten hier. Ich wollte einchecken und sehen, ob diese Verbesserung Ihrer Meinung nach in 1.17 zu Alpha/Beta/Stable wird?

Der aktuelle Veröffentlichungsplan ist:

• Montag, 23. September - Der Release-Zyklus beginnt
• Dienstag, 15. Oktober, EOD PST - Verbesserungen einfrieren
• Donnerstag, 14. November EOD PST - Code Freeze
• Dienstag, 19. November – Dokumente müssen ausgefüllt und überprüft werden
• Montag, 9. Dezember – Kubernetes 1.17.0 veröffentlicht

Wenn Sie dies tun, füge ich es dem Tracking-Sheet 1.17 hinzu (https://bit.ly/k8s117-enhancement-tracking). Sobald die Codierung beginnt, listen Sie bitte alle relevanten k/k PRs in dieser Ausgabe auf, damit sie richtig verfolgt werden können. 👍

Vielen Dank!

Die Probleme veralten nach 90 Tagen Inaktivität.
Markieren Sie das Problem mit /remove-lifecycle stale .
Veraltete Ausgaben verrotten nach weiteren 30 Tagen Inaktivität und werden schließlich geschlossen.

Wenn dieses Problem jetzt sicher geschlossen werden kann, tun Sie dies bitte mit /close .

Senden Sie Feedback an sig-testing, kubernetes/test-infra und/oder fejta .
/Lebenszyklus veraltet

/Entferne-Lebenszyklus veraltet

Hallo @soltysh @kow3ns ,

1.18 Teammitglied für Verbesserungen hier. Ich wollte einchecken und sehen, ob diese Verbesserung Ihrer Meinung nach in 1.18 zu Alpha/Beta/Stable wird? Verbesserungen werden am 28. Januar eingefroren.

Wenn Sie dies tun, füge ich es dem Tracking-Sheet 1.18 hinzu (https://bit.ly/k8s-1-18-enhancements). Sobald die Codierung beginnt, listen Sie bitte alle relevanten k/k PRs in dieser Ausgabe auf, damit sie richtig verfolgt werden können. :+1:

Vielen Dank!

Der aktuelle Veröffentlichungsplan ist:

• Montag, 6. Januar - Release-Zyklus beginnt
• Dienstag, 28. Januar EOD PST - Verbesserungen einfrieren
• Donnerstag, 5. März, EOD PST - Code Freeze
• Montag, 16. März – Dokumente müssen ausgefüllt und überprüft werden
• Dienstag, 24. März – Kubernetes 1.18.0 veröffentlicht

Hey @palnabarun @

Danke @soltysh für die Updates. Ich vermute, dass die Verbesserung für die Veröffentlichung stabil sein soll. Ich aktualisiere das gleiche im Tracking-Sheet. Bitte lassen Sie es mich wissen, wenn es anders ist.

/bühnenstall

/Meilenstein v1.18

@barney-s Nur eine freundliche Erinnerung, wir sind nur noch 7 Tage bis zum Enhancement Freeze (Dienstag, 28. Januar).

Gibt es Neuigkeiten zum KEP?

Laut @mattfarina auf Slack wird dies in 1.18 nicht auf stabil übergehen. Ich werde es aus dem 1.18-Meilenstein entfernen und aus dem Release-Tracking-Sheet entfernen.

KEP-PR: https://github.com/kubernetes/enhancements/pull/978

/Meilenstein klar

Die Probleme veralten nach 90 Tagen Inaktivität.
Markieren Sie das Problem mit /remove-lifecycle stale .
Veraltete Ausgaben verrotten nach weiteren 30 Tagen Inaktivität und werden schließlich geschlossen.

Wenn dieses Problem jetzt sicher geschlossen werden kann, tun Sie dies bitte mit /close .

Senden Sie Feedback an sig-testing, kubernetes/test-infra und/oder fejta .
/Lebenszyklus veraltet

/Entferne-Lebenszyklus veraltet

Hallo @soltysh @kow3ns , 1.19 Verbesserungen Schatten hier. Ich wollte einchecken und sehen, ob diese Verbesserung Ihrer Meinung nach in 1.19 abgeschlossen wird?

Um diesen Teil der Veröffentlichung zu haben:

1. Die KEP PR muss in einem umsetzbaren Zustand zusammengeführt werden
2. Die KEP muss über Testpläne verfügen
3. Die KEP muss Abschlusskriterien haben.

Der aktuelle Veröffentlichungsplan ist:

• Montag, 13. April: Woche 1 - Release-Zyklus beginnt
• Dienstag, 19. Mai: Woche 6 – Einfrieren der Verbesserungen
• Donnerstag, 25. Juni: Woche 11 - Code Freeze
• Donnerstag, 9. Juli: Woche 14 – Dokumente müssen ausgefüllt und überprüft werden
• Dienstag, 4. August: Woche 17 - Kubernetes v1.19.0 veröffentlicht

Wenn Sie dies tun, füge ich es dem Tracking-Blatt 1.19 (http://bit.ly/k8s-1-19-enhancements) hinzu. Sobald die Codierung beginnt, listen Sie bitte alle relevanten k/k PRs in dieser Ausgabe auf, damit sie richtig verfolgt werden können. 👍

Vielen Dank!

Hey @soltysh / @kow3ns , ich v1.19 .

Haben Sie zufällig ein Update zu der Möglichkeit, dass dies in der Version v1.19 ?

Nochmals vielen Dank für Ihre Zeit und Beiträge. 🖖

Hey @soltysh / @kow3ns , ich v1.19 .

Haben Sie zufällig ein Update zu der Möglichkeit, dass dies in der Version v1.19 ?

Nochmals vielen Dank für Ihre Zeit und Beiträge. 🖖

Hey @soltysh / @kow3ns , gibt es Pläne für die Erweiterungen in v1.19 ? Bitte lassen Sie es mich wissen, damit ich das Tracking-Sheet aktualisieren kann, um den Aufnahmestatus anzuzeigen.

_ Einfrieren der Erweiterungen ist am 19. Mai _

Beachten Sie, dass sich das KEP-Format kürzlich geändert hat. Darüber hinaus wurde #1620 kürzlich zusammengeführt, wodurch der KEP-Vorlage Fragen zur Überprüfung der Produktionsbereitschaft hinzugefügt wurden.
Bitte nutzen Sie diese Gelegenheit, um Ihre KEP neu zu formatieren und beantworten Sie auch die Fragen, die der Vorlage in dieser PR hinzugefügt wurden.

Vielen Dank,
🖖

Hey @soltysh / @kow3ns , Leider ist die Frist für den 1.19 Enhancement Freeze abgelaufen und der KEP #978 ist noch im Flug. Vorerst wird dies aus dem Meilenstein- und 1.19-Tracking-Sheet entfernt . Wenn dies erforderlich ist, reichen Sie bitte eine Erweiterungsausnahme ein .

Die Probleme veralten nach 90 Tagen Inaktivität.
Markieren Sie das Problem mit /remove-lifecycle stale .
Veraltete Ausgaben verrotten nach weiteren 30 Tagen Inaktivität und werden schließlich geschlossen.

Wenn dieses Problem jetzt sicher geschlossen werden kann, tun Sie dies bitte mit /close .

Senden Sie Feedback an sig-testing, kubernetes/test-infra und/oder fejta .
/Lebenszyklus veraltet

/Lebenszyklus eingefroren

Erweiterungsprobleme, die in kubernetes/enhancements geöffnet wurden, sollten niemals als eingefroren markiert werden.
Besitzer von Erweiterungen können sicherstellen, dass die Erweiterungen aktuell bleiben, indem sie ihren Status über die Release-Zyklen hinweg konsistent aktualisieren.

/remove-lifecycle eingefroren

/Lebenszyklus eingefroren

Hallo @soltysh

Verbesserungen führen hierher. Gibt es Pläne dafür in 1.20?

Vielen Dank,
Kirsten

@kikisdeliveryservice ja, wir planen, dies langsam zu verschieben, siehe https://github.com/kubernetes/enhancements/pull/1996 für Vorschläge, also werden wir in 1.20 den neuen Controller als Alpha einführen. Ich habe gerade die anfängliche Beschreibung mit allen richtigen Links aktualisiert und an die aktuelle Vorlage angepasst.

/Meilenstein v1.20

@kikisdeliveryservice ja, wir planen, dies langsam

OK, ich habe das viel durchgelesen und bin etwas verwirrt 😄
Die KEP befindet sich in der Beta-Phase. Es wird in der Beta bleiben?? bis 1.21 GA?

# The target maturity stage in the current dev cycle for this KEP.
stage: beta

# The most recent milestone for which work toward delivery of this KEP has been
# done. This can be the current (upcoming) milestone, if it is being actively
# worked on.
latest-milestone: "v1.20"

# The milestone at which this feature was, or is targeted to be, at each stage.
milestone:
  alpha: "v1.4"
  beta: "v1.9"
  stable: "v1.21"

Es hört sich so an, als ob während 1.20 (neuer Controller usw.) Arbeit geleistet wird, um dies zu GA zu bringen, aber diese Arbeit kann eine Veröffentlichung oder 2 dauern, bis sie vor GA abgeschlossen ist? Habe ich es richtig gesagt? Das müsste also für die Version 1.20 nicht nachverfolgt werden?

(Bitte korrigiere mich wenn ich falsch liege!!)

Es hört sich so an, als ob während 1.20 (neuer Controller usw.) Arbeit geleistet wird, um dies zu GA zu bringen, aber diese Arbeit kann eine Veröffentlichung oder 2 dauern, bis sie vor GA abgeschlossen ist? Habe ich es richtig gesagt? Das müsste also für die Version 1.20 nicht nachverfolgt werden?

Das ist richtig. Wir zielen nicht auf 1.20 per se ab, aber ein wichtiger Teil der Arbeit (der neue Controller) wird in 1.20 landen. Deshalb denke ich, dass es für 1.20 nachverfolgt werden sollte, nicht wahr?

/Bühne Beta

@soltysh Macht Sinn, lass uns damit rollen :+1:

Für meine eigenen Aufzeichnungen warten wir nur darauf, dass die PR (die die Kriterien erfüllt) https://github.com/kubernetes/enhancements/pull/1996 bis zum 6. Oktober zusammengeführt wird

KEP fusioniert! :party_face:

Hey @soltysh !

Da Ihre Erweiterung für 1.20 geplant ist, denken Sie bitte an die wichtigen bevorstehenden Daten:
Freitag, 6. November: Woche 8 - PR-Deadline für Docs-Platzhalter
Donnerstag, 12. November: Woche 9 - Code Freeze

Zur Erinnerung: Verlinken Sie bitte alle Ihre k/k PR sowie docs PR mit dieser Ausgabe, damit wir sie verfolgen können.

Vielen Dank!
Kirsten

Hallo @soltysh , 1.20 Docs Shadow hier.
Sind für diese für 1.20 geplanten Erweiterungsarbeiten neue Dokumente oder Änderungen an bestehenden Dokumenten erforderlich?

Wenn ja, befolgen Sie bitte die hier beschriebenen Schritte, um eine PR gegen dev-1.20 Filiale im k/website Repo zu eröffnen. Diese PR kann derzeit nur ein Platzhalter sein und muss vor dem 6. November erstellt werden

Werfen Sie auch einen Blick auf Dokumentation für ein Release , um sich mit den Dokumentationsanforderungen für das Release vertraut zu machen.
Dankeschön!

Roger das :+1:

Hallo @soltysh
Die Frist für die Platzhalter für Dokumente ist fast da. Bitte stellen Sie sicher, dass Sie vor Ablauf der Frist dev-1.20 Zweig im k/website erstellen

Bitte beachten Sie auch die wichtigen nächsten Termine:

• Freitag, 6. November: Woche 8 - PR-Deadline für Docs-Platzhalter
• Donnerstag, 12. November: Woche 9 - Code Freeze
• Montag, 23. November: Woche 11 – Docs PR bereit zur Überprüfung
  Zur Erinnerung: Verlinken Sie bitte alle Ihre k/k PR sowie docs PR mit dieser Ausgabe, damit das Release-Team sie nachverfolgen kann.

• Controller-Implementierung – https://github.com/kubernetes/kubernetes/pull/93370
• Dokumentation - https://github.com/kubernetes/website/pull/24885

Hallo @soltysh !

Anscheinend ist kubernetes/kubernetes#93370 noch geöffnet, wird aber aktiv überprüft. Nur zur Erinnerung, dass Code Freeze in 2 Tagen am Donnerstag, den 12. November erscheint . Alle PRs müssen bis zu diesem Datum zusammengeführt werden, andernfalls ist eine Ausnahme erforderlich.

Am besten,
Kirsten

Ja, ich bin dabei, wenn wir die PR nicht innerhalb der nächsten Stunden zusammenführen, werden wir eine Ausnahme ausfüllen.

Es verschmolz! Fantastisch!!