@erictune fyi

@soltysh Sur quel SIG puis-je discuter de cette fonctionnalité ? Je veux avoir une discussion plus longue sur les ressources tierces pour cette fonctionnalité et pourquoi nous pensons qu'elle doit être intégrée au noyau.

Utilisons SIG-Apps pour le moment. Il n'y a pas eu beaucoup de discussions sur les contrôleurs là-bas, ce que j'ai vu, mais essayons de voir comment cela se passe.

Est-ce que cela est envisagé pour l'exclusion du noyau? Je pensais que la proposition était déjà acceptée.

@gtaylor rien n'a encore été décidé. Actuellement, il fera partie du groupe alpha par lots, ce qui se passera lorsque cela migrera vers plus stable n'est pas encore connu.

D'après ce que j'ai compris, cela a été accepté dans le noyau, tandis que le flux de travail du travail a été rejeté pour le noyau. En fait, nous avions initialement prévu de l'avoir en 1.3.

@davidopp mon commentaire était basé sur la discussion que nous avons eue précédemment avec @philips @erictune ici . Bien que, personnellement, je préférerais que SJ reste dans le noyau :lunettes de soleil:

@soltysh J'ai interprété le commentaire comme impliquant qu'il serait dans le noyau (basé sur la mention d'alpha/beta et la déclaration "Si quelqu'un devait produire une version tierce de scheduleJob, bien avant 1.4, et montrer que c'était comparable utile , ce serait un argument persuasif pour ce dernier chemin" où ce dernier chemin était ThirdParty).

@davidopp ce commentaire a été fait quand je pensais que SJ serait bêta dans 1.4. Maintenant, il va à Alpha en 1.4. La philosophie était que nous pouvons annuler une fonctionnalité alpha pour une raison quelconque, mais nous devrions avoir une barre assez haute pour annuler une fonctionnalité bêta.

Aussi, à tous ceux qui travaillent sur SJ : nous devons continuer à travailler à plein régime, malgré la conversation ci-dessus. Une grande partie du travail s'appliquera dans les deux cas, et nous devons proposer une sorte de fonctionnalité aux utilisateurs afin qu'ils puissent donner leur avis.

Tout le travail SJ est à pleine vitesse, le seul problème restant (espérons-le) est d'avoir https://github.com/kubernetes/kubernetes/pull/29187 . J'espère discuter de ce problème avec @smarterclayton aujourd'hui ou au cours de la week-end et le faire fusionner afin que la semaine prochaine, nous devrions voir l'un après l'autre SJ PR fusionner.

@soltysh : il semble que #29187 ait été fusionné, cela signifie-t-il que la prochaine version alpha 1.4 aura SJ prêt à jouer ?

@eghobo c'est le plan.

Cela nécessite des documents dans k8s.io, mais il semble que le code soit dedans. Génial !

+100

@soltysh est-ce que les documents sont considérés comme terminés ou ajoutez-vous plus d'exemples/tutoriels ? Si les documents sont terminés, nous pouvons cocher la case documents

@janetkuo Je les marque généralement comme terminés une fois qu'ils fusionnent. Dans cet esprit, j'ai vérifié l'un par rapport à la branche 1.4, l'autre attendra la fusion.

Étant donné que cela a été renommé en CronJobs, je mettrai à jour le titre pour refléter également ce changement.

Est-ce que ça va être en bêta pour 1.5 ?

@ConorNevin malheureusement pas, voir les exigences bêta dans la description du problème ce que nous devons d'abord traiter pour le promouvoir en version bêta. Désolé :déçu: L'aide pour les corriger est fortement encouragée :smiley:

Il y a toujours https://github.com/wercker/cronetes , si l'on a besoin de fonctionnalités de type cronjob maintenant sans la possibilité d'exécuter des fonctionnalités alpha.

Est-ce que la fonctionnalité s'exécuterait au plus une fois implémentée dans CronJobs ?
Je vois qu'il n'était pas inclus dans l'alpha - https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/scheduledjob.md#decision

@vinay-g finalement, je suppose, mais je n'ai aucune idée de quand cela arrivera. L'aide est toujours la bienvenue cependant :)

Cette fonctionnalité est toujours attachée au jalon 1.4, et la feuille de calcul du jalon 1.6 ne mentionne rien à propos de Cron/ScheduledJobs.

Est-ce toujours prévu pour une version bêta 1.6 ? En tant que client GKE, j'adorerais commencer à déplacer tous nos crons hors cluster sur le cluster lui-même (sans utiliser de cronetes).

En effet. C'est une fonctionnalité indispensable qui traîne depuis la version 1.3 si je ne me trompe pas. Moi-même, je suis dans la même position - je ne peux pas attendre qu'il se présente pour pouvoir commencer à extraire les tâches sur site sur GKE.

J'ai modifié le jalon au suivant, il y a encore beaucoup de travail à faire pour que CronJobs les stabilise, j'aimerais le pousser plus agressivement, mais malheureusement le manque de temps est le principal facteur que je peux' au guichet automatique.

imagePullSecrets est-

@soltysh merci pour la mise à jour.

imagePullSecrets est-il pris en charge dans le modèle ChronJob ?

@avaranovich devrait l'être, puisque nous créons un Pod à partir du modèle. Si ce n'est pas le cas, remplissez un problème et identifiez-moi là-bas.

Salut @soltysh . J'aimerais voir dans cette bêta bientôt! Je veux aider, mais je ne sais pas ce qui est requis/la prochaine étape ici. Pouvez-vous s'il vous plaît affiner un peu la liste de contrôle (peut-être créer/indiquer les problèmes/documents pertinents) ? ??

@ApsOps avant la version bêta, nous devons absolument implémenter la suppression côté serveur, prendre en charge le moteur d'application Google et le format chronos, et autoriser l'utilisation des fuseaux horaires. Ce serait probablement bien de balayer les bogues qui sont sur moi et qui sont liés à CronJobs. Je doute que ce soit faisable pour la 1.6, mais pour les prochaines versions c'est faisable. Plus important encore, taguez-moi dans chaque numéro/publication que vous créez par rapport à ce sujet.

@soltysh

Je pense que pas mal de gens utilisent CronJobs comme ils le sont maintenant, et j'entends surtout "quand sera-ce la version bêta", un problème moins important avec l'alpha.

Si nous pensons que nous pouvons ajouter la suppression côté serveur, le moteur d'application, les chronos et les fuseaux horaires sans casser l'API actuelle, alors je ne vois aucune raison de ne pas déplacer la version bêta maintenant et d'ajouter ces éléments avant GA.

+1 pour la version bêta de CronJobs. Dès qu'ils sont en version bêta et que la réinitialisation du cluster n'est pas nécessaire, ce serait une fonctionnalité fatale pour un certain nombre de nos flux de travail ici.

Nous attendons avec impatience que cette fonctionnalité passe en version bêta et nous n'avons eu aucun problème avec l'alpha.

Personnellement, je préférerais aborder au moins la partie suppression, il y a déjà quelqu'un qui travaille déjà sur l'ajout de limites configurables pour le nombre de travaux réussis et échoués laissés pour compte. Et la suppression est un élément clé, je pense. Discutons de l'option de passer à la version bêta pour 1.6 ou 1.7 lors du prochain appel sig-apps. @michelleN ça vous dérange d'ajouter ça comme sujet ?

@NiclasHedam vos problèmes ont-ils été résolus, y a-t-il des problèmes ouverts que je n'ai pas vus, cela vous dérange de m'ouvrir/me faire un ping ?

Ils ont tous été traités dans la 1.4.7

Est-il prévu d'ajouter la prise en charge de l'interface graphique ? Par exemple, je peux actuellement voir ce qui suit :

[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>

Cependant, dans l'interface graphique, je ne peux voir que l'exécution historique, pas les travaux en cours et le calendrier qui leur est associé ? De plus, kubectl get ne répertorie pas cronjob / cronjobs comme types de ressources valides, bien qu'ils fonctionnent effectivement.

Naturellement, il se peut que je passe à côté de quelque chose, mais une recherche exhaustive des différentes parties de l'interface graphique ne m'a pas encore montré mes emplois !

@oscarbatori Veuillez ouvrir un problème dans le référentiel kubernetes/dashboard et demander cette amélioration.

@luxas fera l'affaire, merci pour votre réponse rapide.

@soltysh Pouvez-vous s'il vous plaît ajouter le PR Docs k8s.io pour cette fonctionnalité pour la version 1.8 ici : https://docs.google.com/spreadsheets/d/1AFksRDgAt6BGA3OjRNIiO3IyKmA-GU7CXaxbihy48ns/edit#gid =0

@soltysh cette fonctionnalité est répertoriée dans la feuille de calcul de suivi des fonctionnalités - https://docs.google.com/spreadsheets/d/1AFksRDgAt6BGA3OjRNIiO3IyKmA-GU7CXaxbihy48ns/edit#gid =0, mais n'a pas de jalon 1,8 assigné.

Cette fonctionnalité cible-t-elle 1.8 ?

@idvoretskyi partiellement, la promotion en version bêta était ciblée pour 1,8 et s'est déroulée dans ce laps de temps. Il n'y a pas de jalon défini pour cela, car il n'y a pas encore de plan clair pour la future promotion en stable.

@soltysh a compris. Donc, je vais marquer avec 1,8 jalon.

Merci!

@idvoretskyi puisqu'il y a une fonctionnalité ( possibilité de démarrer CronJobs manuellement ), nous allons essayer d'entrer dans la version 1.9 liée à CronJobs, j'ajouterai 1.9 milstone ici, est-ce que ça va? Je ne veux pas créer un autre problème juste pour suivre cet élément unique.

Je vais probablement essayer de mettre à jour la description initiale afin qu'elle reflète les modifications introduites (également prévues) pour les fonctionnalités liées à CronJob.

@soltysh des progrès avec la mise à jour de la description des fonctionnalités ? :)

Veuillez utiliser le nouveau modèle - https://github.com/kubernetes/features/blob/master/ISSUE_TEMPLATE.md

@soltysh :wave: Veuillez indiquer dans le tableau de suivi des fonctionnalités 1.9
si cette fonctionnalité a besoin de documentation. Si oui, veuillez ouvrir un PR et ajouter un lien vers la feuille de calcul de suivi. Merci d'avance!

@idvoretskyi puisqu'il existe une fonctionnalité ( possibilité de démarrer CronJobs manuellement ), nous

Cette fonctionnalité spécifique ne sera pas dans la 1.9. Devons-nous déplacer le jalon à 1,10 ?

Pour le jalon 1.10, il y a 3 sujets :

1. Prise en charge de TimeZone dans CronJob (https://github.com/kubernetes/kubernetes/pull/47266) - @iterion voir ce commentaire pour expliquer pourquoi
2. Instanciation manuelle de CronJob (https://github.com/kubernetes/kubernetes/pull/53988) - @erhudy
3. (?) Réécrivez le contrôleur pour utiliser des informateurs partagés (https://github.com/kubernetes/kubernetes/issues/17130) - @soltysh

@soltysh et toujours en version bêta, n'est-ce pas ?

Exigences stables :

1. Informateurs partagés dans le contrôleur (https://github.com/kubernetes/kubernetes/issues/17130)
2. Prend en charge différents formats d'heure ( ISO 8601 , format d'heure GCE ).

La feuille de calcul de suivi des fonctionnalités la feuille de calcul ? Merci!

@soltysh docs ping -- la date limite pour la fusion des docs PR est ce vendredi 9 mars. Voir le commentaire précédent. Merci! /cc @idvoretskyi

@Bradamant3 désolé pour le retard, aucune mise à jour de la documentation n'est nécessaire pour cette fonctionnalité. J'ai ajouté un commentaire dans la feuille de calcul liée.

@soltysh
Des plans pour cela dans 1.11?

Si tel est le cas, pouvez-vous vous assurer que la fonctionnalité est à jour avec les éléments appropriés :

• La description
• Jalon
• Cessionnaire(s)
• Étiquettes:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

Des plans pour cela dans 1.11?

Réécriture du contrôleur pour satisfaire https://github.com/kubernetes/kubernetes/issues/17130 mais j'ai toujours du mal avec le temps. Il s'agit donc plus d'un vœu pieux que de plans réels :wink:

D'accord cool. Je vais pousser le jalon là-dessus.

une mise à jour sur les plans pour amener cela à stable? Je suppose qu'en raison du manque de jalon, cela ne se produira pas pour la 1.12 ?

une mise à jour sur les plans pour amener cela à stable? Je suppose qu'en raison du manque de jalon, cela ne se produira pas pour la 1.12 ?

@soltysh ^^

@spiffxp -- J'ai parlé avec @soltysh plus tôt. Rien de prévu pour le 1.12.

salut
Cette amélioration a déjà fait l'objet d'un suivi, nous aimerions donc vérifier s'il est prévu que cela gradue les étapes dans Kubernetes 1.13. Cette version est destinée à être plus « stable » et aura un calendrier agressif. Veuillez n'inclure cette amélioration que si vous êtes sûr qu'elle respectera les délais suivants :

• Docs (espace réservé PRs ouvert) : 11/8
• Code Slush : 11/9
• Début du gel du code : 15/11
• Documents terminés et révisés : 27/11

Veuillez prendre un moment pour mettre à jour les jalons de votre message d'origine pour un suivi futur et envoyer un ping à feuille de suivi des améliorations 1.13

Merci!

@kacole2 cela ne bouge nulle part jusqu'à ce que nous résolvions le plus gros problème avec le contrôleur cronjob, qui est les informateurs partagés. Nous discuterons de ce sujet lors du prochain appel SIG-Apps.

Les problèmes deviennent obsolètes après 90 jours d'inactivité.
Marquez le problème comme récent avec /remove-lifecycle stale .
Les problèmes périmés pourrissent après 30 jours supplémentaires d'inactivité et finissent par se fermer.

Si ce problème peut être résolu en toute sécurité maintenant, veuillez le faire avec /close .

Envoyez vos commentaires à sig-testing, kubernetes/test-infra et/ou fejta .
/cycle de vie périmé

Les problèmes périmés pourrissent après 30 jours d'inactivité.
Marquez le problème comme récent avec /remove-lifecycle rotten .
Les problèmes pourris se ferment après 30 jours supplémentaires d'inactivité.

Si ce problème peut être résolu en toute sécurité maintenant, veuillez le faire avec /close .

Envoyez vos commentaires à sig-testing, kubernetes/test-infra et/ou fejta .
/cycle de vie pourri

Que diriez-vous d'un préfixe aux emplois tels que 20190212T2157Z

/remove-lifecycle pourri

/cycle de vie gelé

Les problèmes d'amélioration ouverts dans kubernetes/enhancements ne doivent jamais être marqués comme gelés.
Les propriétaires d'améliorations peuvent s'assurer que les améliorations restent à jour en mettant constamment à jour leurs états au cours des cycles de publication.

/remove-lifecycle gelé

Bonjour @soltysh , je suis le responsable de l'amélioration de la 1.15. Cette fonctionnalité va-t-elle passer les étapes alpha/bêta/stable dans la version 1.15 ? S'il vous plaît laissez-moi savoir afin qu'il puisse être suivi correctement et ajouté à la feuille de calcul. Comme d'habitude, un KEP devra être fusionné avant que cela puisse progresser.

Une fois le codage commencé, veuillez répertorier tous les PR k/k pertinents dans ce numéro afin qu'ils puissent être suivis correctement.

En tant qu'utilisateur, j'utilise avec succès ce type de ressource depuis longtemps maintenant. Je n'ai pas vu de problèmes majeurs avec l'API. Est-il temps de l'expédier en tant que GA ?

Nous travaillons sur un KEP pour l'obtention du diplôme

D'accord. Merci pour la mise à jour.

Salut @kow3ns @soltysh , je suis le responsable de l'amélioration 1.16. Cette fonctionnalité va-t-elle passer les étapes alpha/beta/stable dans la version 1.16 ? Veuillez me le faire savoir afin qu'il puisse être ajouté à la feuille de calcul de suivi 1.16 . Si ce n'est pas le cas, je le supprimerai du jalon et modifierai l'étiquette suivie.

Une fois le codage commencé ou s'il l'a déjà fait, veuillez répertorier tous les PR k/k pertinents dans ce numéro afin qu'ils puissent être suivis correctement.

Pour rappel, chaque amélioration nécessite un KEP dans un état implémentable avec des critères d'obtention du diplôme expliquant les exigences de chaque étape alpha/bêta/stable.

Les dates clés sont Enhancement Freeze 7/30 et Code Freeze 8/29.

Merci.

Salut @soltysh @kow3ns , ombre des améliorations 1.17 ici. Je voulais vérifier et voir si vous pensez que cette amélioration passera à alpha/beta/stable en 1.17 ?

Le calendrier de diffusion actuel est le suivant :

• Lundi 23 septembre - Début du cycle de publication
• Mardi 15 octobre, EOD PST - Gel des améliorations
• Jeudi 14 novembre, EOD PST - Gel du code
• Mardi 19 novembre - Les documents doivent être complétés et révisés
• Lundi 9 décembre - Sortie de Kubernetes 1.17.0

Si vous le faites, je l'ajouterai à la feuille de suivi 1.17 (https://bit.ly/k8s117-enhancement-tracking). Une fois le codage commencé, veuillez répertorier tous les PR k/k pertinents dans ce numéro afin qu'ils puissent être suivis correctement. ??

Merci!

Les problèmes deviennent obsolètes après 90 jours d'inactivité.
Marquez le problème comme récent avec /remove-lifecycle stale .
Les problèmes périmés pourrissent après 30 jours supplémentaires d'inactivité et finissent par se fermer.

Si ce problème peut être résolu en toute sécurité maintenant, veuillez le faire avec /close .

Envoyez vos commentaires à sig-testing, kubernetes/test-infra et/ou fejta .
/cycle de vie périmé

/supprimer le cycle de vie périmé

Salut @soltysh @kow3ns ,

1.18 Membre de l'équipe d'améliorations ici. Je voulais vérifier et voir si vous pensez que cette amélioration passera à alpha/beta/stable en 1.18 ? Les améliorations seront gelées le 28 janvier.

Si vous le faites, je l'ajouterai à la feuille de suivi 1.18 (https://bit.ly/k8s-1-18-enhancements). Une fois le codage commencé, veuillez répertorier tous les PR k/k pertinents dans ce numéro afin qu'ils puissent être suivis correctement. :+1:

Merci!

Le calendrier de diffusion actuel est le suivant :

• Lundi 6 janvier - Début du cycle de publication
• Mardi 28 janvier EOD PST - Gel des améliorations
• Jeudi 5 mars, EOD PST - Gel du code
• Lundi 16 mars - Les documents doivent être complétés et révisés
• Mardi 24 mars - Sortie de Kubernetes 1.18.0

Hé @palnabarun @barney-s travaille à la fermeture du KEP à temps, la mise en œuvre se poursuivra.

Merci @soltysh pour les mises à jour. Je suppose que l'amélioration est ciblée pour être stable pour la version. Je mets à jour la même chose dans la feuille de suivi. Merci de me dire s'il en est autrement.

/écurie d'étape

/jalon v1.18

@barney-s Juste un rappel amical, nous ne sommes qu'à 7 jours du gel des améliorations (mardi 28 janvier).

Avez-vous des mises à jour sur le KEP?

Selon @mattfarina sur Slack, cela ne passera pas à stable en 1.18. Je vais le supprimer du jalon 1.18 et le supprimer de la feuille de suivi des versions.

RP KEP : https://github.com/kubernetes/enhancements/pull/978

/jalon clair

Les problèmes deviennent obsolètes après 90 jours d'inactivité.
Marquez le problème comme récent avec /remove-lifecycle stale .
Les problèmes périmés pourrissent après 30 jours supplémentaires d'inactivité et finissent par se fermer.

Si ce problème peut être résolu en toute sécurité maintenant, veuillez le faire avec /close .

Envoyez vos commentaires à sig-testing, kubernetes/test-infra et/ou fejta .
/cycle de vie périmé

/supprimer le cycle de vie périmé

Salut @soltysh @kow3ns , 1.19 Améliorations ombre ici. Je voulais vérifier et voir si vous pensez que cette amélioration sera diplômée en 1.19 ?

Pour avoir cette partie de la version :

1. Le KEP PR doit être fusionné dans un état implémentable
2. Le KEP doit avoir des plans de test
3. Le KEP doit avoir des critères d'obtention du diplôme.

Le calendrier de diffusion actuel est le suivant :

• Lundi 13 avril : Semaine 1 - Début du cycle de publication
• Mardi 19 mai : Semaine 6 - Gel des améliorations
• Jeudi 25 juin : Semaine 11 - Gel du code
• Jeudi 9 juillet : Semaine 14 - Les documents doivent être complétés et révisés
• Mardi 4 août : Semaine 17 - Sortie de Kubernetes v1.19.0

Si vous le faites, je l'ajouterai à la feuille de suivi 1.19 (http://bit.ly/k8s-1-19-enhancements). Une fois le codage commencé, veuillez répertorier tous les PR k/k pertinents dans ce numéro afin qu'ils puissent être suivis correctement. ??

Merci!

Salut @soltysh / @kow3ns , je fais suite à ma précédente mise à jour sur cette amélioration faisant partie de la version v1.19 .

Avez-vous une mise à jour sur la possibilité que cela soit inclus dans la version v1.19 ?

Merci encore pour votre temps et vos contributions. ??

Salut @soltysh / @kow3ns , je fais suite à ma précédente mise à jour sur cette amélioration faisant partie de la version v1.19 .

Avez-vous une mise à jour sur la possibilité que cela soit inclus dans la version v1.19 ?

Merci encore pour votre temps et vos contributions. ??

Hé @soltysh / @kow3ns , des plans pour que les améliorations soient incluses dans v1.19 ? S'il vous plaît laissez-moi savoir afin que je puisse mettre à jour la feuille de suivi pour montrer l'état d'inclusion.

_ Le gel des améliorations est le 19 mai _

Notez que récemment le format KEP a changé. De plus, #1620 a récemment fusionné, ajoutant des questions d'examen de la préparation à la production au modèle KEP.
Veuillez saisir cette occasion pour reformater votre KEP et également répondre aux questions ajoutées au modèle dans ce PR.

Merci,
??

Hé @soltysh / @kow3ns , Malheureusement, la date limite pour le gel de l'amélioration 1.19 est passée et le KEP #978 est toujours en vol. Pour l'instant, cela est supprimé du jalon et de la feuille de suivi 1.19 . S'il est nécessaire de l'introduire, veuillez déposer une exception d'amélioration .

Les problèmes deviennent obsolètes après 90 jours d'inactivité.
Marquez le problème comme récent avec /remove-lifecycle stale .
Les problèmes périmés pourrissent après 30 jours supplémentaires d'inactivité et finissent par se fermer.

Si ce problème peut être résolu en toute sécurité maintenant, veuillez le faire avec /close .

Envoyez vos commentaires à sig-testing, kubernetes/test-infra et/ou fejta .
/cycle de vie périmé

/cycle de vie gelé

Les problèmes d'amélioration ouverts dans kubernetes/enhancements ne doivent jamais être marqués comme gelés.
Les propriétaires d'améliorations peuvent s'assurer que les améliorations restent à jour en mettant constamment à jour leurs états au cours des cycles de publication.

/remove-lifecycle gelé

/cycle de vie gelé

Salut @soltysh

Les améliorations mènent ici. Des plans pour ça dans la 1.20 ?

Merci,
Kirsten

@kikisdeliveryservice oui, nous prévoyons d'avancer lentement, voir https://github.com/kubernetes/enhancements/pull/1996 pour une proposition, donc 1.20 est le moment où nous présenterons le nouveau contrôleur en tant qu'alpha. Je viens de mettre à jour la description initiale avec tous les liens appropriés et pour correspondre au modèle actuel.

/jalon v1.20

@kikisdeliveryservice oui, nous prévoyons d'avancer lentement, voir #1996 pour la proposition, donc la 1.20 est la date à laquelle nous allons introduire le nouveau contrôleur en tant qu'alpha. Je viens de mettre à jour la description initiale avec tous les liens appropriés et pour correspondre au modèle actuel.

D'accord, j'ai lu beaucoup de choses et je suis un peu confus 😄
Le KEP est en version bêta. Il restera en bêta ?? jusqu'à 1.21 AG ?

# 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"

Il semble que des travaux seront effectués pendant la version 1.20 (nouveau contrôleur, etc.) Ai-je bien compris? Cela n'aurait donc pas besoin d'être suivi pour la version 1.20 ?

(Corrigez-moi si j'ai tort, s'il-vous plait!!)

Il semble que des travaux seront effectués pendant la version 1.20 (nouveau contrôleur, etc.) Ai-je bien compris? Cela n'aurait donc pas besoin d'être suivi pour la version 1.20 ?

C'est exact. Nous ne visons pas la 1,20 en soi, mais une partie importante du travail (le nouveau contrôleur) atterrira dans la 1,20. C'est pourquoi je pense qu'il devrait être suivi pour 1,20, non ?

/étape bêta

@soltysh C'est logique, allons-y :+1:

Pour ma part, nous attendons juste que le PR (qui répond aux critères) https://github.com/kubernetes/enhancements/pull/1996 fusionne d'ici le 6 octobre

KEP a fusionné ! :partying_face:

Salut @soltysh !

Étant donné que votre amélioration est prévue pour la version 1.20, veuillez garder à l'esprit les dates importantes à venir :
Vendredi 6 novembre : semaine 8 - Date limite pour les relations publiques de l'espace réservé aux documents
Jeudi 12 novembre : Semaine 9 - Gel du code

Pour rappel, veuillez lier tous vos PR k/k ainsi que vos PR docs à ce problème afin que nous puissions les suivre.

Merci!
Kirsten

Bonjour @soltysh , 1.20 Docs shadow ici.
Ce travail d'amélioration prévu pour la version 1.20 nécessite-t-il de nouveaux documents ou une modification des documents existants ?

Si tel est le cas, veuillez suivre les étapes ici pour ouvrir un PR contre dev-1.20 branche k/website . Ce PR peut être juste un espace réservé pour le moment et doit être créé avant le 6 novembre

Jetez également un œil à la documentation d'une version pour vous familiariser avec les exigences de documentation pour la version.
Merci!

Roger ça :+1:

Salut @soltysh
La date limite des espaces réservés pour les documents est presque arrivée. Assurez-vous de créer un espace réservé PR contre la branche dev-1.20 dans le k/website avant la date limite

N'oubliez pas non plus les dates importantes à venir :

• Vendredi 6 novembre : semaine 8 - Date limite pour les relations publiques de l'espace réservé aux documents
• Jeudi 12 novembre : Semaine 9 - Gel du code
• Lundi 23 novembre : semaine 11 - Docs PR prêt pour examen
  Pour rappel, veuillez lier tous vos PR k/k ainsi que vos PR docs à ce problème pour que l'équipe de publication puisse les suivre.

• Implémentation du contrôleur - https://github.com/kubernetes/kubernetes/pull/93370
• Documentation - https://github.com/kubernetes/website/pull/24885

Salut @soltysh !

On dirait que kubernetes/kubernetes#93370 est toujours ouvert mais en cours de révision. Juste un rappel que Code Freeze arrive dans 2 jours le jeudi 12 novembre . Tous les PR doivent être fusionnés à cette date, sinon une exception est requise.

Meilleur,
Kirsten

Oui, j'y suis, si nous n'obtenons pas la fusion des relations publiques dans les prochaines heures, nous remplirons l'exception.

ça a fusionné ! Impressionnant!!