/sig-Planung

Hi @sparciii -- 1.18 Enhancements shadow hier. Ich wollte nachsehen und sehen, ob Sie glauben, dass diese Verbesserung in 1.18 in alpha|beta|stable graduiert wird?

Der aktuelle Veröffentlichungsplan ist:
Montag, 6. Januar – Der Veröffentlichungszyklus beginnt
Dienstag, 28. Januar EOD PST – Einfrieren der Verbesserungen
Donnerstag, 5. März, EOD PST – Code-Einfrieren
Montag, 16. März – Dokumente müssen ausgefüllt und überprüft werden
Dienstag, 24. März – Kubernetes 1.18.0 veröffentlicht

Um in die Freigabe aufgenommen zu werden, muss diese Erweiterung ein zusammengeführtes KEP im Status Implementierbar haben. Das KEP muss auch über Graduierungskriterien und einen definierten Testplan verfügen.
Wenn Sie diese Verbesserung einbeziehen möchten, listen Sie bitte alle relevanten k/k-PRs in dieser Ausgabe auf, sobald die Kodierung beginnt, damit sie ordnungsgemäß nachverfolgt werden können. 👍

Wir werden Verbesserungen hier verfolgen: http://bit.ly/k8s-1-18-enhancements
Danke!

Zur Erinnerung @sparciii :

Dienstag, 28. Januar EOD PST – Einfrieren der Verbesserungen

Enhancements Freeze ist in 7 Tagen. Wenn Sie die Aufnahme in 1.18 anstreben, aktualisieren Sie bitte wie oben gefordert.

Danke!

Danke @kikisdeliveryservice für die Erinnerung! Ich werde im Slack Channel und in den kommenden Bürozeiten nachfragen, um Feedback zu erhalten, ob diese KEP eine angemessene Anfrage ist.

Gemäß der Diskussion mit @Huang-Wei behalten wir dieses KEP und schließen https://github.com/kubernetes/kubernetes/pull/84405 zugunsten der Übermittlung an das Subrepo https://github.com/kubernetes- sigs/scheduler-plugins , wo der Code dem Scheduler-Framework entspricht.

@sparciii wirst du versuchen, 1.18 für Alpha zu machen? Lass es mich wissen, damit wir es verfolgen können.

Danke!

@kikisdeliveryservice nein. Es gehört zu einem Sub-Repo.

Eigentlich möchte ich eine allgemeine Frage stellen: Wenn das KEP auf ein Sub-Repo (kubernetes-sigs/xyz) abzielt, sollten wir dann k/enhancement verwenden, um das KEP zu hosten?

Hallo @Huang-Wei,

Sehen Sie zunächst hier nach: https://github.com/kubernetes/enhancements#is -my-thing-an-enhancement

Zweitens einige Fragen/Dinge, über die man bei Erweiterungen außerhalb von k/k nachdenken sollte: Werden sich Benutzer von k/k auf diese Funktion verlassen? Müssen Sie dies mitteilen / benötigen Sie Unterstützung vom Release-Team? Wird Ihre Arbeit den Veröffentlichungszyklen folgen und an diese gebunden sein?

Es scheint, dass diese Arbeit ein optionales Plug-in sein wird? Werden Sie Alpha-/Beta-/stabile Versionen durchlaufen?

Danke @kikisdeliveryservice . Ja, es ist eher ein optionales Plugin, das von k/k gehostet wird, ich denke, es sollte als Designdokument-Diskussion in https://github.com/kubernetes-sigs/scheduler-plugins verwaltet werden. Wir können jedoch die Gliederung der KEP-Vorlage nutzen.

cc/ @denkensk @alculquicondor

SGTM

Ausgaben veralten nach 90 Tagen Inaktivität.
Markieren Sie die Ausgabe mit /remove-lifecycle stale als neu.
Veraltete Ausgaben verrotten nach weiteren 30 Tagen Inaktivität und werden schließlich geschlossen.

Wenn Sie dieses Problem jetzt sicher schließen können, tun Sie dies bitte mit /close .

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

/nah dran

@sparciii Bitte zögern Sie nicht, ein Problem oder eine PR in https://github.com/kubernetes-sigs/scheduler-plugins zu öffnen, falls Sie dies noch nicht getan haben.

@alculquicondor : Dieses Problem wird geschlossen.