Enhancements: Unterstützung von Snapshot/Restore-Volume für Kubernetes (CRD + externer Controller)

Erstellt am 24. Jan. 2017  ·  100Kommentare  ·  Quelle: kubernetes/enhancements

Funktionsbeschreibung

  • Einzeilige Funktionsbeschreibung (kann als Versionshinweis verwendet werden):
Snapshot / restore functionality for Kubernetes and CSI. This provides standardized APIs design (CRDs) and adds PV snapshot/restore support for CSI volume drivers.

Alte Beschreibung:

Expose the ability in the Kubernetes API to create,list, delete, and restore snapshots from an arbitrary underlying storage systems that support it.
kinfeature sistorage stagbeta stagstable trackeyes

Hilfreichster Kommentar

@kikislieferservice ,

https://github.com/kubernetes/kubernetes/pull/95282 ist genehmigt. Warte nur darauf, dass es zusammengeführt wird :).

Alle 100 Kommentare

Gouverneure / Gouverneure # 39657
Gouverneure / Gouverneure # 44172

/cc @skriss

@jingxu97 Ich denke, wir werden etwas in Alpha für 1.7 haben, können wir den Meilenstein bitte auf 1.7 setzen?

@kubernetes/sig-storage-feature-requests könnte jemand bitte die Problembeschreibung auf die neue Vorlage aktualisieren. Vielen Dank!

Ich werde daran arbeiten. Vielen Dank!

Am besten,
Jing

Am Donnerstag, den 4. Mai 2017 um 8:43 Uhr, caleb miles [email protected]
schrieb:

@kubernetes/sig-storage-feature-requests
https://github.com/orgs/kubernetes/teams/sig-storage-feature-requests
Könnte jemand bitte die Problembeschreibung auf die neue Vorlage aktualisieren.
Vielen Dank!


Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kubernetes/features/issues/177#issuecomment-299225105 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ASSNxR4fUmmxnJ4QQc-Fe0K5CKT5tRO9ks5r2fIcgaJpZM4Lrsji
.

--

  • Jing

Nein, das neue Angebotsdokument ist da
https://docs.google.com/document/d/17WS4Wk4MXRH24i-BpMpIFo5F-SNoRkm_KtkBMZEEoAo
Bitte lassen Sie es mich wissen, wenn Sie es nicht öffnen können. Vielen Dank!

Jing

Dimitrios Karagiannis am Di, 9. Mai 2017 um 7:34 Uhr <
[email protected]> schrieb:

Basiert dies auf dem Vorschlag hier: https://github.com/kubernetes/
community/blob/master/contributors/design-proposals/volume-snapshotting.md
?


Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kubernetes/features/issues/177#issuecomment-300184509 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ASSNxVKLqOq9lsJ72MrdqkNN-2pbfmtIks5r4HmQgaJpZM4Lrsji
.

--

  • Jing

@jingxu97 danke! Ich kann nicht darauf zugreifen, aber ich habe gerade Zugriff angefordert.

@jingxu97 Ich wollte hier einen wichtigen Hinweis zum Gesamtansatz hinzufügen. Ich bin nicht der richtige Ort, um dies zu platzieren, aber ich würde mich freuen, in das richtige Forum geleitet zu werden, um dies anzusprechen.

Da ich einen langen Hintergrund in oVirt und OSP habe, denke ich, dass es einen wichtigen Aspekt gibt, der diskutiert werden muss, nämlich der Besitz des Status von Snapshots (und der gesamten Volume-Metadaten) und die Auffindbarkeit dieser Metadaten.

In der Cloud und vor Ort bevorzugen Benutzer (Entwickler und Administratoren) möglicherweise die nativen Speicher-APIs gegenüber den Kube-APIs. Kube ist auch nicht derjenige, der den Snapshot erstellt, sondern der Cloud-Dienst oder der Speicher selbst, daher ist er nicht der Eigentümer dieser Metadaten.

In OSP haben sie diesen Fehler bereits mit Cinder gemacht, der Benutzer, die Snapshots verwenden möchten, zwingt, die Cinder-API zu durchlaufen, damit sie in der OSP-Umgebung verfügbar sind. Cinder kennt keinen Snapshot, der auf dem Speicher erstellt wurde, und wenn Sie den Cinder verlieren, verlieren Sie alles, da die Metadaten, die zählen, sich in seiner Stateful-DB befinden.

Was ich damit sagen möchte, ist, dass Kube nicht versucht, der Eigentümer der Volume-Metadaten zu sein, was bedeutet, dass regelmäßig überprüft wird, ob ein neuer Snapshot direkt über die Speicherdienst-API erstellt wurde oder ob die ID verwendet wurde für den Snapshot ist die Snapshot-ID des Speicherdienstes.

Es ist klar, dass Kube Snapshotting bereitstellen sollte, da es für den Container-Anwendungsfall sehr wichtig ist, aber es ist sehr wichtig, dass es nicht zu einem Speicherabstraktionsdienst wie Cinder wird. Wir möchten den Funktionen des Speicherdienstes nicht hinterherlaufen oder den Benutzer auf die Verwendung der Kube-API beschränken, dies sollte eine Option sein. Wir möchten auch die Erkennung von Volumes ermöglichen, unabhängig davon, wo sie erstellt wurden.

Wenn wir zu komplexeren Funktionen wie QOS und Überabonnement kommen, möchten wir beispielsweise die Bereitstellung und Wiederverwendung der Speicherdienstfunktionen ermöglichen, sie nicht ersetzen oder Benutzer daran hindern, sie über den Cloud-Dienst oder die Speicherverwaltungs-APIs zu verwenden.

@jingxu97 Fortschritte bei der Funktionsbeschreibung? @kubernetes/sig-storage-feature-requests

@mdelio @jingxu97 Bitte aktualisieren Sie die Funktionsbeschreibung mit der neuen Vorlage - https://github.com/kubernetes/features/blob/master/ISSUE_TEMPLATE.md

@idvoretskyi Ich habe den ursprünglichen Kommentar mit der neuen Vorlage aktualisiert. Diese Funktion liefert keine Bits im Kubernetes-Kern für v1.7 aus, daher habe ich sie nach next-milestone verschoben. Dies bedeutet, dass für 1.7 im Kubernetes-Kern keine Dokumentation usw. erforderlich ist. Ich werde die Funktion auch aus dem 1.7 Tracking Board entfernen.

@saad-ali irgendwelche Updates für 1.8? Ist diese Funktion noch auf dem richtigen Weg für die Veröffentlichung?

cc @tsmetana

@idvoretskyi das ist noch auf dem richtigen Weg: https://github.com/kubernetes-incubator/external-storage/pull/331

@jingxu97 @rootfs ein Update zu fehlenden Dokumenten dafür? PR ist heute fällig.

@jdumars Wir stellen das ins externe, gibt es noch eine Frist dafür?

Dies ist eine unabhängige Funktion außerhalb des spezifischen 1.8-Meilensteins.

Docs kann warten, bis Sie @jingxu97 separat vielen Dank, dass Sie es uns

Dies hat es nicht in 1.9 geschafft. Stochern auf 1,10

@saad-ali @kubernetes/sig-storage-feature-requests irgendwelche Fortschritte für 1.10?

Wir arbeiten an einem Vorschlag, um es in den Baum zu schieben. Werde den Status bald aktualisieren.

@jingxu97 @saad-ali @kubernetes/sig-storage-feature-requests Irgendwelche Pläne dafür in 1.11?

Wenn ja, 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

Irgendwelche Updates?? Irgendwelche Pläne, dies für v1.12 anzuvisieren??

@saad-ali -- Danke für das Update! Dies wurde dem 1.12 Tracking-Blatt hinzugefügt.

Zur Verdeutlichung erwähnt https://github.com/kubernetes/features/issues/543 die folgende Zeitleiste:

Alpha release target (x.y): 1.12
Beta release target (x.y): 1.13
Stable release target (x.y): 1.14

Können Sie das bestätigen?

/assign @xing-yang

@justaugustus : GitHub hat mir nicht erlaubt, die folgenden Benutzer zuzuweisen: xing-yang.

Beachten Sie, dass nur Kubernetes-Mitglieder und Repo-Mitarbeiter zugewiesen werden können.
Weitere Informationen finden Sie im Beitragsleitfaden

Als Antwort darauf :

/assign @xing-yang

Anleitungen zur Interaktion mit mir über PR-Kommentare finden Sie hier . Wenn Sie Fragen oder Vorschläge zu meinem Verhalten haben, reichen Sie bitte ein Problem gegen das

@justaugustus "Alpha-Release-Ziel 1.12..." ist korrekt. Die Prototyp-Snapshot-Unterstützung in "Externes Repo" wurde in 1.8 hinzugefügt.

Sie da! @jingxu97 Ich bin der Wrangler für die Docs in dieser Version. Besteht die Möglichkeit, dass Sie eine Docs-PR gegen den Zweig release-1.12 als Platzhalter öffnen? Das gibt uns mehr Vertrauen in die Funktionsauslieferung in dieser Version und gibt mir etwas, mit dem ich arbeiten kann, wenn wir mit der Überprüfung/Bearbeitung beginnen. Vielen Dank! Wenn für diese Funktion keine Dokumente erforderlich sind, könnten Sie bitte die Tabelle zur Funktionsverfolgung aktualisieren, um dies widerzuspiegeln?

@zparnold Platzhalter-Dokument-PR hinzugefügt https://github.com/kubernetes/website/pull/9948

Dankeschön!

Am Montag, den 20. August 2018 um 21:36 Uhr schrieb Xing Yang [email protected] :

@zparnold https://github.com/zparnold Platzhalter-Dokument PR hinzugefügt
kubernetes/website#9948 https://github.com/kubernetes/website/pull/9948


Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kubernetes/features/issues/177#issuecomment-414530549 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AE81SM80cpm_P_RyA84IJ4eBqconFlY1ks5uS3JCgaJpZM4Lrsji
.

@jingxu97 @xing-yang --
Gibt es ein Update zum Dokumentenstatus für diese Funktion? Planen wir immer noch, es für 1.12 zu landen?
Zu diesem Zeitpunkt steht der Code eingefroren und die Dokumente sind am 07.09. (2 Tage) fällig.
Wenn wir zu diesem Feature so schnell wie möglich nichts zurückgeben, müssen wir es aus dem Meilenstein entfernen.

cc: @zparnold @jimangel @tfogo

@justaugustus Code wurde zusammengeführt. Doc PR steht zur Überprüfung bereit: https://github.com/kubernetes/website/pull/9948

Danke für das Update!

Kubernetes 1.13 wird eine "stabile" Version sein, da der Zyklus nur 10 Wochen beträgt. Wir empfehlen keine großen Alpha-Funktionen und ziehen diese Funktion nur in Betracht, wenn Sie ein hohes Maß an Vertrauen haben, dass sie bis zum 11.09. Gibt es Pläne, diese Erweiterung innerhalb des Release-Zyklus 1.13 auf Alpha/Beta/Stable zu stufen? Wenn nicht, können Sie ihn bitte aus dem 1.12-Meilenstein entfernen oder zu 1.13 hinzufügen?

Wir ermutigen jetzt auch, dass jede neue Verbesserung mit einem KEP übereinstimmt . Wenn ein KEP erstellt wurde, verlinken Sie es bitte im Originalbeitrag. Bitte nutzen Sie die Gelegenheit, ein KEP . zu entwickeln

Tatsächlich ist diese Funktion in 1.12 Alpha. Wir planen keine Betaversion von 1.13. Es sollte wie folgt geändert werden:

External repo (x.y): 1.8
Alpha release target (x.y): 1.12
Beta release target (x.y): 1.14

Danke @xing-yang
/Meilenstein klar

@jingxu97 Hallo - Ich bin der prüfe dieses Problem, um zu sehen, welche Arbeiten (falls vorhanden) für die Version 1.14 geplant sind. Das Einfrieren der Erweiterungen ist am 29. Januar und ich möchte daran erinnern, dass alle Erweiterungen ein KEP haben müssen

Hallo @claurence - wir arbeiten an "Execution Hook" und "PV/PVC taints and tolerations" für 1.14. Brauchen wir dafür KEP? Wenn ja, reiche ich ein KEP für den Ausführungs-Hook ein. Jing arbeitet an einer Spezifikation für Flecken und Toleranzen.

@xing-yang Danke - allen Problemen sollte ein KEP zugeordnet sein, also füge bitte einen für dieses Problem hinzu. Haben Sie auch Links zu den PRs für die beiden oben genannten Punkte?

Ist Alpha immer noch die richtige Phase oder wird diese Funktion zur Beta?

@claurence Ja, es ist immer noch Alpha.
Wir arbeiten noch am KEP, daher ist es noch nicht eingereicht. Was ist die Frist für die Einreichung einer KEP?

@claurence hier ist der KEP auf ExecutionHook: https://github.com/kubernetes/enhancements/pull/705

@xing-yang bitte reichen Sie die KEP vor dem Einfrieren der Erweiterungen am 29. Januar ein, wenn für 1.14 Arbeit erwartet wird - wenn dies für 1.14 nicht im Rahmen ist, wird eine KEP für die Arbeit in 1.15 benötigt

Hallo @xing-yang, 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. Dies erfordert auch die Aufnahme eines KEP.

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

Hallo @kacole2 , die von diesem Problem verfolgte Snapshot-Funktion bleibt als Alpha. Ich werde ein weiteres Verbesserungsproblem erstellen, um die ExecutionHook-Funktion separat zu verfolgen.

Hallo @kacole2 , ein Verbesserungsproblem wird für ExecutionHook hier erstellt: https://github.com/kubernetes/enhancements/issues/962

Wir streben Beta für 1,16 . an

/Bühne Beta
/Meilenstein v1.16

@msau42 hier fehlt noch ein KEP. Ich werde es vorerst in das Tracking-Blatt eintragen.

@xing-yang kannst du dafür einen Kep erstellen? Ich bin mir nicht sicher, wie aktuell das ursprüngliche Designdokument war, aber wir können vom Kep darauf hinweisen

@msau42 @kacole2 Hier ist das ursprüngliche https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/csi-snapshot.md

Muss ich einen KEP erstellen und auf dieses Dokument verweisen?

Ja, alle Verbesserungen sollten jetzt durch keps gehen. Wenn das ursprüngliche Designdokument größtenteils aktuell ist, können Sie einfach einen Kep erstellen, der darauf verweist. Schauen Sie sich die Vorlage an und sehen Sie, ob die KEP-Abschnitte bereits im Designdokument enthalten sind oder nicht (nämlich Abschlusskriterien, Testplan, Implementierungshistorie usw.). Hier ist ein Beispiel für einen Speicherspeicher, der auf das ursprüngliche Designdokument verweist und fehlende Abschnitte hinzufügt: https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/20190124-csi-topology.md

Hey, @jingxu97 @xing-yang Ich bin der Versionsleiter von v1.16 docs.

Erfordert diese Verbesserung (oder die für v1.16) geplante Arbeit neue Dokumente (oder Änderungen)?

Nur eine freundliche Erinnerung, wir suchen eine PR gegen k/website (Zweig dev-1.16), die bis Freitag, den 23. August fällig ist. Es wäre toll, wenn es der Anfang der vollständigen Dokumentation wäre, aber selbst ein Platzhalter-PR ist akzeptabel. Lassen Sie es mich wissen, wenn Sie Fragen haben!

Hallo @simplytunde , wir müssen einige Stellen in der Dokumentation ändern, um von v1alpha1 zu v1beta1 zu wechseln, und geben auch die Änderung des Feature-Gates an. Werde demnächst eine Doc PR einreichen. Vielen Dank.

@xing-yang @jingxu97
Das Einfrieren der Verbesserung ist EOD 7/30. Dieses Problem erfordert immer noch, dass ein zusammengeführtes KEP als Teil der Version betrachtet wird. Dies wird als At Risk und wird aus dem Meilenstein entfernt, wenn er morgen nicht zusammengeführt wird. Vielen Dank.

@xing-yang freundliche Erinnerung daran, dass Donnerstag, der 29.08., ein k/k-Code-Freeze ist, um https://github.com/kubernetes/kubernetes/pull/80058 zusammenzuführen

Danke @kacole2 für die Erinnerung! Wir arbeiten daran.

@kacole2 Wir konnten heute keinen Code zusammenführen. Dies wird auf den 1.17 verschoben.

Hallo @xing-yang

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, listen Sie bitte nach Beginn der Codierung alle relevanten k/k-PRs in dieser Ausgabe auf, damit sie ordnungsgemäß nachverfolgt werden können. 👍

Vielen Dank!

Hallo @mrbobbytables Ja, wir planen, dieses Feature in 1.17 zur Beta zu bringen.

Großartig, danke! Ich mache weiter und füge es dem Tracking-Blatt hinzu :)

Hallo @xing-yang @jingxu97 Ich bin einer der v1.17 Docs Shadows.
Erfordert diese Erweiterung für (oder die für v1.17) geplante Arbeit neue Dokumente (oder Änderungen an bestehenden Dokumenten)? Wenn nicht, können Sie bitte das 1.17 Enhancement Tracker Sheet aktualisieren (oder lassen Sie es mich wissen und ich werde dies tun)

Wenn ja, nur eine freundliche Erinnerung, wir suchen eine PR gegen k/website (Zweig dev-1.17), die bis Freitag, den 8. November fällig ist, es kann zu diesem Zeitpunkt nur eine Platzhalter-PR sein. Lassen Sie es mich wissen, wenn Sie Fragen haben!

Danke @irvifa ! Ich werde bald ein Dokument einreichen.

@irvifa Doc PR wird hier eingereicht: https://github.com/kubernetes/website/pull/17233

Hallo @xing-yang. Ich bin einer der Verbesserungen Shadows für die Version 1.17. Code Freeze nähert sich schnell am 14. November, also wollte ich mit der Basis Kontakt aufnehmen und sehen, wie das läuft. Könnten Sie bitte auch auf k/k-PRs verlinken, an denen im Rahmen dieser Ausgabe gearbeitet wird? Wir haben nichts in der Tabelle für Verbesserungen nachverfolgt.

Vielen Dank!

Hallo @jeremyrickard , hier sind die PRs:

Vielen Dank @xing-yang! Ich werde die Tabelle aktualisieren.

Zwei weitere PRs wurden zusammengeführt. Hier der neue Status:

  • [Zusammengeführt] Verschieben Sie Snapshot-APIs in die Beta: kubernetes-csi/external-snapshotter#139
  • [Zusammengeführt] Aktualisieren Sie den externen Anbieter, um die neue Snapshot-Beta-API zu verwenden: kubernetes-csi/external-provisioner#335
  • [Zusammengeführt] Snapshot-Controller geteilter PR: kubernetes-csi/external-snapshotter#178
  • [Zusammengeführt] Aktualisierte Snapshot-in-tree-e2e-Tests mit Snapshot-Beta-APIs und Feature-Gate aktivieren: kubernetes/kubernetes#80058
  • [Zusammengeführt] Doc PR: kubernetes/website#17233

Also haben wir das Code-Freeze-Datum festgelegt. Die einzige erforderliche PR, die noch aussteht, ist die Doc PR, die überprüft wird.

Doc PR kubernetes/website#17233 wird ebenfalls zusammengeführt.

Hallo @xing-yang

Der aktuelle Veröffentlichungsplan ist:

Montag, 6. Januar – Veröffentlichungszyklus 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

Wenn Sie dies tun, listen Sie bitte nach Beginn der Codierung alle relevanten k/k-PRs in dieser Ausgabe auf, damit sie ordnungsgemäß nachverfolgt werden können. 👍

Vielen Dank!

Hallo @jeremyrickard , diese Funktion wird in der

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 @jingxu97 -- 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
  • Donnerstag, 20. August: Woche 19 - Release Retrospektive

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!

Hallo @msedzins , wir planen, in 1.19 Beta zu bleiben. Vielen Dank!

Hallo @xing-yang,

Danke für das Update!

/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

Wir planen, diese Funktion in 1.20 in GA einzuführen.

Hallo @kikisdeliveryservice ,

Können Sie dies bitte zum Tracking-Sheet der Version 1.20 hinzufügen? Vielen Dank!

Fertig :+1: Danke für das Update.

Hallo @xing-yang

Sieht so aus, als ob Ihre PR vollständig und bereit zum Zusammenführen ist: https://github.com/kubernetes/enhancements/pull/1994#issuecomment -701426142

Sie müssen nur die Sperre entfernen, damit sie am 6. Oktober bis zum Einfrieren zusammengeführt werden kann

:Lächeln:

Hallo @kikisdeliveryservice ,

Ich brauche nur Michelle zum Review und LGTM :).

Vielen Dank!

Hey @xing-yang!

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! :smile_cat:
Kirsten

Hallo @kikisdeliveryservice ,

Danke für die Erinnerung!

Hier ist der k/k-PR:
https://github.com/kubernetes/kubernetes/pull/95282

Xing

Hallo @xing-yang @jingxu97 :wave:, 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 Schritte hier , 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!

Danke @eagleusb ! Ich werde bald ein Platzhalterdokument einreichen.

Hallo @xing-yang :wave:

Danke für dein Update. In der Zwischenzeit ist die Frist für die Platzhalter für Dokumente 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:

Hallo @eagleusb ,

Danke für die Erinnerung! Doc PR wird hier eingereicht: https://github.com/kubernetes/website/pull/24849

Hallo @xing-yang

Anscheinend ist kubernetes/kubernetes#95282 noch geöffnet, wird aber aktiv bearbeitet. 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

Hallo @kikisdeliveryservice ,

Danke für die Erinnerung! Wir versuchen, die Rezensenten dazu zu bringen, die PR bis zum 12.11. zu überprüfen und zu genehmigen.

Xing

Dieser PR, der Snapshot-CRDs auf v1 für das Cluster-Addon aktualisiert, wird zusammengeführt: https://github.com/kubernetes/kubernetes/pull/96383
Wir rücken näher.

Groß! warten nur in den Gouverneuren / Gouverneuren # 95282

@kikislieferservice ,

https://github.com/kubernetes/kubernetes/pull/95282 ist genehmigt. Warte nur darauf, dass es zusammengeführt wird :).

Yay! Es ist fusioniert! Tracking-Blatt aktualisieren.

Herzlichen Glückwunsch! :Feuerwerk:

Danke @kikisdeliveryservice!

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

justinsb picture justinsb  ·  11Kommentare

wlan0 picture wlan0  ·  9Kommentare

saschagrunert picture saschagrunert  ·  6Kommentare

povsister picture povsister  ·  5Kommentare

prameshj picture prameshj  ·  9Kommentare