@erictune fyi

@soltysh ¿En qué SIG puedo discutir esta característica? Quiero tener una discusión más larga sobre los recursos de terceros para esta función y por qué creemos que debe integrarse en el núcleo.

Usemos SIG-Apps por ahora. No ha habido mucha discusión sobre los controladores allí, que he visto, pero intentemos y veamos cómo va.

¿Se está considerando esto para su exclusión del núcleo? Pensé que la propuesta ya había sido aceptada.

@gtaylor aún no se ha decidido nada. Actualmente será parte del grupo alfa en lote, aún no se sabe qué pasará cuando este migre a más estable.

Tengo entendido que esto se aceptó en el núcleo, mientras que el flujo de trabajo del trabajo se rechazó para el núcleo. De hecho, originalmente habíamos planeado tenerlo en 1.3.

@davidopp mi comentario se basó en la discusión que hemos tenido anteriormente con @philips @erictune aquí . Aunque, personalmente, prefiero que SJ se quede en el núcleo: gafas de sol:

@soltysh Interpreté el comentario en el sentido de que estaría en el núcleo (basado en la mención de alpha / beta y la declaración "Si alguien produjera una versión de terceros de scheduleJob, mucho antes de la 1.4, y mostrara que era comparablemente útil , ese sería un argumento persuasivo para el último camino "donde el último camino era Tercera parte).

@davidopp, ese comentario se hizo cuando pensé que SJ sería Beta en 1.4. Ahora va a Alpha en 1.4. La filosofía era que podemos cancelar una función alfa por cualquier motivo, pero deberíamos tener un listón bastante alto para cancelar una función beta.

Además, a todos los que trabajan en SJ: debemos seguir trabajando a toda velocidad, a pesar de la conversación anterior. Gran parte del trabajo se aplicará de cualquier manera, y necesitamos ofrecer algún tipo de función a los usuarios para que puedan dar su opinión.

Todo el trabajo de SJ está a toda velocidad, el único problema restante (con suerte) es tener https://github.com/kubernetes/kubernetes/pull/29187 adentro. Espero discutir este problema con @smarterclayton hoy o en el fin de semana y fusionarlo, por lo que la próxima semana deberíamos ver uno tras otro SJ PR que se fusionarán.

@soltysh : parece que # 29187 se fusionó, ¿significa que la próxima versión alfa 1.4 tendrá a SJ listo para jugar?

@eghobo ese es el plan.

Esto necesita documentos en k8s.io, pero parece que el código está en. ¡Genial!

+100

@soltysh, ¿ se considera que los documentos están terminados o están agregando más ejemplos / tutoriales? Si los documentos están listos, podemos marcar la casilla de documentos.

@janetkuo Normalmente los marco como hechos una vez que se fusionan. Con eso en mente, he verificado el uno contra la rama 1.4, el otro esperará la fusión.

Dado que se cambió el nombre a CronJobs, actualizaré el título para reflejar ese cambio también.

¿Va a estar en beta para 1.5?

@ConorNevin lamentablemente no, consulte los requisitos de la versión beta en la descripción del problema, lo que debemos abordar primero para promoverlo a la versión beta. Lo siento: decepcionado: se recomienda encarecidamente ayudar a solucionarlos: smiley:

Todavía hay https://github.com/wercker/cronetes , si uno necesita una funcionalidad similar a cronjob ahora sin la capacidad de ejecutar funciones alfa.

¿Se ejecutará como máximo una vez que se implemente la función en CronJobs?
Veo que no se incluyó en el alfa - https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/scheduledjob.md#decision

@ vinay-g eventualmente, supongo que sí, pero no tengo idea de cuándo ocurrirá. Sin embargo, la ayuda siempre es bienvenida :)

Esta función todavía está adjunta al hito 1.4, y la hoja de cálculo del hito 1.6 no menciona nada sobre Cron / ScheduledJobs.

¿Todavía está programado para una versión beta 1.6? Como cliente de GKE, _me encantaría_ comenzar a mover todos nuestros crones fuera del clúster al clúster en sí (sin usar cronetes).

En efecto. Esta es una característica muy necesaria que se ha estado prolongando desde la versión 1.3 si no me equivoco. Yo mismo estoy en la misma posición: no puedo esperar hasta que se dé cuenta para poder comenzar a llevar los trabajos locales a GKE.

Modifiqué el hito al siguiente, todavía hay mucho trabajo por hacer para que CronJobs los estabilice, me encantaría impulsarlo de manera más agresiva, pero desafortunadamente la falta de tiempo es el factor principal que puedo ''. t atm.

¿ Se admite

@soltysh gracias por actualizar.

¿Se admite imagePullSecrets en la plantilla ChronJob?

@avaranovich debería serlo, ya que estamos creando un Pod a partir de la plantilla. Si no es así, rellene un problema y etiquéteme allí.

Hola @soltysh . ¡Me encantaría verlo pronto en esta versión beta! Quiero ayudar pero no estoy seguro de qué se requiere / el siguiente paso aquí. ¿Puede refinar un poco la lista de verificación (tal vez crear / señalar problemas / documentos relevantes)? 🙂

@ApsOps antes de la versión beta, definitivamente necesitamos implementar la eliminación del lado del servidor, admitir el motor de aplicaciones de Google y el formato chronos, y permitir el uso de zonas horarias. Probablemente sería bueno barrer los errores que tengo relacionados con CronJobs. Dudo que sea factible para 1.6, pero para los próximos lanzamientos es factible. Lo más importante es que me etiquetes en cada número / pr que crees relacionado con este tema.

@soltysh

Creo que bastantes personas usan CronJobs como lo hacen ahora, y escucho principalmente "cuándo será beta", y no tantos problemas con alfa.

Si creemos que podemos agregar eliminación del lado del servidor, motor de aplicaciones y cronos, y zonas horarias sin romper la API actual, entonces no veo ninguna razón para no mover la versión beta ahora y agregar esas cosas antes de GA.

+1 para CronJobs beta. Tan pronto como sean beta y no se requiera el reinicio del clúster, sería una característica decisiva para varios de nuestros flujos de trabajo aquí.

Esperamos que esta función se convierta en beta y no hemos tenido problemas con la versión alfa.

Personalmente, preferiría abordar al menos la parte de eliminación, ya hay alguien trabajando para agregar límites configurables para la cantidad de trabajos exitosos y fallidos que quedan atrás. Y la eliminación es un elemento clave, creo. Analicemos la opción de mover esto a la versión beta para 1.6 o 1.7 durante la próxima llamada sig-apps. @michelleN ¿te importaría agregar esto como tema?

@NiclasHedam, ¿se han

Todos se han abordado en 1.4.7

¿Hay algún plan para agregar soporte GUI a esto? Por ejemplo, actualmente puedo ver lo siguiente:

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

Sin embargo, en la GUI solo puedo ver la ejecución histórica, no los trabajos actuales y el cronograma asociado con ellos. Además, kubectl get no enumera cronjob / cronjobs como tipos de recursos válidos, aunque sí funcionan.

Naturalmente, podría estar perdiendo algo, ¡pero la búsqueda exhaustiva de las diversas partes de la GUI aún no me muestra mis trabajos!

@oscarbatori Abra un problema en el repositorio de kubernetes / dashboard y solicite esa mejora.

@luxas lo hará, gracias por su pronta respuesta.

@soltysh ¿Puede agregar k8s.io Docs PR para esta función para la versión 1.8 aquí: https://docs.google.com/spreadsheets/d/1AFksRDgAt6BGA3OjRNIiO3IyKmA-GU7CXaxbihy48ns/edit#gid = 0

@soltysh, esta función aparece en la hoja de cálculo de seguimiento de funciones: https://docs.google.com/spreadsheets/d/1AFksRDgAt6BGA3OjRNIiO3IyKmA-GU7CXaxbihy48ns/edit#gid = 0, pero no tiene asignado un hito de 1.8.

¿Esta función tiene como objetivo 1.8?

@idvoretskyi parcialmente, la promoción a la versión beta estaba dirigida a 1.8 y sucedió en ese período de tiempo. No hay un hito establecido para esto, porque todavía no hay un plan claro para la promoción futura a estable.

@soltysh entendió. Entonces, marcaré con 1.8 hito.

¡Gracias!

@idvoretskyi ya que hay una característica ( capacidad para iniciar CronJobs manualmente ) intentaremos entrar en la versión 1.9 relacionada con CronJobs, agregaré 1.9 milstone aquí, ¿está bien? No quiero crear otro problema solo para rastrear ese único elemento.

Probablemente intentaré actualizar la descripción inicial para que refleje los cambios introducidos (también planificados) para las funciones relacionadas con CronJob.

@soltysh ¿ algún progreso con la actualización de la descripción de la función? :)

Utilice la nueva plantilla: https://github.com/kubernetes/features/blob/master/ISSUE_TEMPLATE.md

@soltysh : wave: indíquelo en el panel de seguimiento de funciones 1.9
si esta función necesita documentación. En caso afirmativo, abra un PR y agregue un enlace a la hoja de cálculo de seguimiento. ¡Gracias por adelantado!

@idvoretskyi ya que hay una característica ( Capacidad para iniciar CronJobs manualmente ) intentaremos ingresar a la versión 1.9 relacionada con CronJobs, agregaré 1.9 milstone aquí

Esta característica específica no estará en 1.9. ¿Movemos el hito a 1.10?

Para el hito 1.10 hay 3 temas:

1. Soporte de TimeZone en CronJob (https://github.com/kubernetes/kubernetes/pull/47266) - @iterion vea este comentario para razonar por qué
2. Creación de instancias manual de CronJob (https://github.com/kubernetes/kubernetes/pull/53988) - @erhudy
3. (?) Vuelva a escribir el controlador para usar informadores compartidos (https://github.com/kubernetes/kubernetes/issues/17130) - @soltysh

@soltysh y todavía beta, ¿verdad?

Requisitos estables:

1. Informadores compartidos en el controlador (https://github.com/kubernetes/kubernetes/issues/17130)
2. Admite diferentes formatos de hora ( ISO 8601 , formato de hora GCE ).

La hoja de cálculo de seguimiento de funciones la hoja de cálculo ? ¡Gracias!

@soltysh docs ping - la fecha límite para fusionar documentos PR es este viernes 9 de marzo. Consulte el comentario anterior. ¡Gracias! / cc @idvoretskyi

@ Bradamant3 perdón por el retraso, no se necesita ninguna actualización de documentación para esta función. Agregué un comentario en la hoja de cálculo vinculada.

@soltysh
¿Algún plan para esto en 1.11?

Si es así, ¿puede asegurarse de que la función esté actualizada con lo siguiente?

• Descripción
• Hito
• Cesionario (s)
• Etiquetas:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

¿Algún plan para esto en 1.11?

Reescriba el controlador para satisfacer https://github.com/kubernetes/kubernetes/issues/17130 pero todavía estoy luchando con el tiempo. Así que esto es más una ilusión que planes reales: guiño:

Está bien, genial. Voy a impulsar el hito en esto.

¿Alguna actualización sobre los planes para llevar esto a una situación estable? Supongo que, en base a la falta de hito, esto no sucederá en 1.12.

¿Alguna actualización sobre los planes para llevar esto a una situación estable? Supongo que, en base a la falta de hito, esto no sucederá en 1.12.

@soltysh ^^

@spiffxp - Hablé con @soltysh antes. Nada planeado para la 1.12.

Hola
Se ha realizado un seguimiento de esta mejora antes, por lo que nos gustaría verificar y ver si hay algún plan para que esto gradúe las etapas en Kubernetes 1.13. Esta versión está destinada a ser más "estable" y tendrá una línea de tiempo agresiva. Solo incluya esta mejora si existe un alto nivel de confianza en que cumplirá con los siguientes plazos:

• Documentos (RRPP de marcador de posición abierto): 8/11
• Código Slush: 11/9
• Comienza la congelación de código: 15/11
• Documentos completos y revisados: 27/11

Tómese un momento para actualizar los hitos en su publicación original para un seguimiento futuro y haga ping a hoja de seguimiento de mejoras 1.13

¡Gracias!

@ kacole2, esto no se moverá a ninguna parte hasta que solucionemos el problema más grande con el controlador cronjob, que son los informadores compartidos. Discutiremos este tema durante la próxima convocatoria de SIG-Apps.

Los problemas se vuelven obsoletos después de 90 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle stale .
Los problemas obsoletos se pudren después de 30 días adicionales de inactividad y finalmente se cierran.

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/ ciclo de vida obsoleto

Los problemas viejos se pudren después de 30 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle rotten .
Los problemas podridos se cierran después de 30 días adicionales de inactividad.

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/ ciclo de vida podrido

¿Qué tal un prefijo para trabajos como 20190212T2157Z

/ eliminar-ciclo de vida podrido

/ ciclo de vida congelado

Los problemas de mejora abiertos en kubernetes/enhancements nunca deben marcarse como congelados.
Los propietarios de las mejoras pueden asegurarse de que las mejoras se mantengan actualizadas constantemente actualizando sus estados a lo largo de los ciclos de lanzamiento.

/ remove-lifecycle congelado

Hola @soltysh , soy el líder de mejora de 1.15. ¿Esta característica va a graduar las etapas alfa / beta / estable en 1.15? Por favor, avíseme para poder realizar un seguimiento adecuado y agregarlo a la hoja de cálculo. Como de costumbre, será necesario fusionar un KEP antes de que esto pueda progresar.

Una vez que comience la codificación, enumere todos los RP k / k relevantes en este número para que se puedan rastrear correctamente.

Como usuario, he estado utilizando con éxito este tipo de recurso durante mucho tiempo. No he visto ningún problema importante con la API. ¿Es hora de enviarlo como GA?

Estamos trabajando en un KEP para la graduación.

Está bien. Gracias por la actualización.

Hola @ kow3ns @soltysh , soy el líder de mejora 1.16. ¿Esta función va a graduar las etapas alfa / beta / estable en 1.16? Por favor, avíseme para que se pueda agregar a la hoja de cálculo de seguimiento 1.16 . Si no se está graduando, lo eliminaré del hito y cambiaré la etiqueta de seguimiento.

Una vez que comience la codificación o si ya lo ha hecho, enumere todos los RP k / k relevantes en este número para que se puedan rastrear correctamente.

Como recordatorio, cada mejora requiere un KEP en un estado implementable con los Criterios de graduación que explican los requisitos de cada etapa alfa / beta / estable.

Las fechas de hitos son Enhancement Freeze el 30 de julio y Code Freeze el 29 de agosto.

Gracias.

Hola @soltysh @ kow3ns , 1.17 Mejoras en la sombra aquí. Quería registrarme y ver si crees que esta Mejora se graduará en alfa / beta / estable en 1.17.

El calendario de lanzamiento actual es:

• Lunes 23 de septiembre: comienza el ciclo de lanzamiento
• Martes 15 de octubre, EOD PST - Congelación de mejoras
• Jueves, 14 de noviembre, EOD PST - Code Freeze
• Martes 19 de noviembre: los documentos deben completarse y revisarse
• Lunes 9 de diciembre: lanzamiento de Kubernetes 1.17.0

Si lo hace, lo agregaré a la hoja de seguimiento 1.17 (https://bit.ly/k8s117-enhancement-tracking). Una vez que comience la codificación, enumere todos los RP k / k relevantes en este número para que se puedan rastrear correctamente. 👍

¡Gracias!

Los problemas se vuelven obsoletos después de 90 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle stale .
Los problemas obsoletos se pudren después de 30 días adicionales de inactividad y finalmente se cierran.

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/ ciclo de vida obsoleto

/ remove-lifecycle stale

Hola @soltysh @ kow3ns ,

1.18 Miembro del equipo de mejoras aquí. Quería registrarme y ver si crees que esta Mejora se graduará en alfa / beta / estable en 1.18. Las mejoras se congelarán el 28 de enero.

Si lo hace, lo agregaré a la hoja de seguimiento 1.18 (https://bit.ly/k8s-1-18-enhancements). Una vez que comience la codificación, enumere todos los RP k / k relevantes en este número para que se puedan rastrear correctamente. : +1:

¡Gracias!

El calendario de lanzamiento actual es:

• Lunes 6 de enero: comienza el ciclo de lanzamiento
• Martes 28 de enero EOD PST - Congelación de mejoras
• Jueves, 5 de marzo, EOD PST - Code Freeze
• Lunes 16 de marzo: los documentos deben completarse y revisarse
• Martes 24 de marzo: lanzamiento de Kubernetes 1.18.0

Hola @palnabarun @ barney-s está trabajando para cerrar el KEP a tiempo, la implementación continuará.

Gracias, @soltysh por las actualizaciones. Supongo que la mejora está destinada a ser estable para el lanzamiento. Estoy actualizando lo mismo en la hoja de seguimiento. Por favor avíseme si es de otra manera.

/ escenario estable

/ hito v1.18

@ barney-s Solo un recordatorio amistoso, estamos a solo 7 días de la congelación de mejoras (martes 28 de enero).

¿Tiene alguna actualización sobre el KEP?

Según @mattfarina en Slack, esto no se graduará a estable en 1.18. Lo eliminaré del hito 1,18 y lo quitaré de la hoja de seguimiento de versiones.

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

/ hito claro

Los problemas se vuelven obsoletos después de 90 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle stale .
Los problemas obsoletos se pudren después de 30 días adicionales de inactividad y finalmente se cierran.

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/ ciclo de vida obsoleto

/ remove-lifecycle stale

Hola @soltysh @ kow3ns , 1.19 Mejoras en la sombra aquí. Quería registrarme y ver si crees que esta Mejora se graduará en 1.19.

Para tener esta parte del lanzamiento:

1. El KEP PR debe fusionarse en un estado implementable
2. El KEP debe tener planes de prueba
3. El KEP debe tener criterios de graduación.

El calendario de lanzamiento actual es:

• Lunes 13 de abril: Semana 1: comienza el ciclo de lanzamiento
• Martes 19 de mayo: Semana 6 - Congelación de mejoras
• Jueves 25 de junio: Semana 11 - Congelación de código
• Jueves 9 de julio: Semana 14: los documentos deben completarse y revisarse
• Martes 4 de agosto: semana 17: lanzamiento de Kubernetes v1.19.0

Si lo hace, lo agregaré a la hoja de seguimiento 1.19 (http://bit.ly/k8s-1-19-enhancements). Una vez que comience la codificación, enumere todos los RP k / k relevantes en este número para que se puedan rastrear correctamente. 👍

¡Gracias!

Hola @soltysh / @ kow3ns , estoy haciendo un seguimiento de mi actualización anterior sobre esta Mejora que es parte del lanzamiento v1.19 .

¿Tiene alguna actualización sobre la posibilidad de que esto se incluya en el lanzamiento v1.19 ?

Gracias nuevamente por su tiempo y contribuciones. 🖖

Hola @soltysh / @ kow3ns , estoy haciendo un seguimiento de mi actualización anterior sobre esta Mejora que es parte del lanzamiento v1.19 .

¿Tiene alguna actualización sobre la posibilidad de que esto se incluya en el lanzamiento v1.19 ?

Gracias nuevamente por su tiempo y contribuciones. 🖖

Hola @soltysh / @ kow3ns , ¿algún plan para que las Mejoras se incluyan en v1.19 ? Avíseme para que pueda actualizar la hoja de seguimiento para mostrar el estado de inclusión.

_ La congelación de mejoras es el 19 de mayo _

Tenga en cuenta que recientemente ha cambiado el formato KEP. Además, # 1620 se fusionó recientemente, agregando preguntas de revisión de preparación de producción a la plantilla KEP.
Aproveche esta oportunidad para reformatear su KEP y también responda las preguntas agregadas a la plantilla en ese PR.

Gracias,
🖖

Hola @soltysh / @ kow3ns , Desafortunadamente, la fecha límite para la congelación de la Mejora 1.19 ha pasado y el KEP # 978 todavía está en vuelo. Por ahora, esto se está eliminando de la hoja de seguimiento de hitos y excepción de mejora .

Los problemas se vuelven obsoletos después de 90 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle stale .
Los problemas obsoletos se pudren después de 30 días adicionales de inactividad y finalmente se cierran.

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/ ciclo de vida obsoleto

/ ciclo de vida congelado

Los problemas de mejora abiertos en kubernetes/enhancements nunca deben marcarse como congelados.
Los propietarios de las mejoras pueden asegurarse de que las mejoras se mantengan actualizadas constantemente actualizando sus estados a lo largo de los ciclos de lanzamiento.

/ remove-lifecycle congelado

/ ciclo de vida congelado

Hola @soltysh

Las mejoras conducen aquí. ¿Algún plan para esto en 1.20?

Gracias,
Kirsten

@kikisdeliveryservice sí, estamos planeando mover esto lentamente, consulte https://github.com/kubernetes/enhancements/pull/1996 para obtener una propuesta, por lo que 1.20 es cuando presentaremos el nuevo controlador como alfa. Acabo de actualizar la descripción inicial con todos los enlaces adecuados y para que coincida con la plantilla actual.

/ hito v1.20

@kikisdeliveryservice sí, estamos planeando mover esto lentamente, vea la propuesta # 1996, así que 1.20 es cuando presentaremos el nuevo controlador como alfa. Acabo de actualizar la descripción inicial con todos los enlaces adecuados y para que coincida con la plantilla actual.

OK, leí esto un montón y estoy un poco confundido 😄
El KEP está en beta. ¿Se quedará en beta? hasta 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"

Parece que se trabajará durante 1.20 (nuevo controlador, etc.) para llevar esto a GA, pero ¿ese trabajo puede tomar una versión o 2 para terminar antes de GA? ¿Lo entendí bien? Entonces, ¿no sería necesario realizar un seguimiento de esto para la versión 1.20?

(¡¡Por favor corrígeme si estoy equivocado!!)

Parece que se trabajará durante 1.20 (nuevo controlador, etc.) para llevar esto a GA, pero ¿ese trabajo puede tomar una versión o 2 para terminar antes de GA? ¿Lo entendí bien? Entonces, ¿no sería necesario realizar un seguimiento de esto para la versión 1.20?

Eso es correcto. No estamos apuntando a 1.20 per se, pero una parte importante del trabajo (el nuevo controlador) aterrizará en 1.20. Es por eso que creo que debería rastrearse para 1.20, ¿no?

/ etapa beta

@soltysh Tiene sentido, sigamos adelante: +1:

Para mi propio registro, solo estamos esperando que el PR (que cumple con los criterios) https://github.com/kubernetes/enhancements/pull/1996 se fusione antes del 6 de octubre

¡MANTENER fusionado! : cara_fiesta:

¡Hola @soltysh !

Dado que su Mejora está programada para la versión 1.20, tenga en cuenta las próximas fechas importantes:
Viernes 6 de noviembre: Semana 8 - Fecha límite de relaciones públicas del marcador de posición de Docs
Jueves, 12 de noviembre: Semana 9 - Congelación de código

Como recordatorio, vincule todas sus relaciones públicas de k / k, así como las relaciones públicas de los documentos, a este problema para que podamos rastrearlas.

¡Gracias!
Kirsten

Hola @soltysh , 1.20 Docs shadow aquí.
¿Este trabajo de mejora planificado para la versión 1.20 requiere algún documento nuevo o modificación de los documentos existentes?

Si es así, siga los pasos aquí para abrir un PR contra la sucursal dev-1.20 en el repositorio k/website . Este PR puede ser solo un marcador de posición en este momento y debe crearse antes del 6 de noviembre

También eche un vistazo a Documenting para una versión para familiarizarse con los requisitos de documentación para la versión.
¡Gracias!

Entendido eso: +1:

Hola @soltysh
La fecha límite del marcador de posición de documentos está casi aquí. Asegúrese de crear un marcador de posición PR contra la rama dev-1.20 en el k/website antes de la fecha límite

Además, tenga en cuenta las próximas fechas importantes:

• Viernes 6 de noviembre: Semana 8 - Fecha límite de relaciones públicas del marcador de posición de Docs
• Jueves, 12 de noviembre: Semana 9 - Congelación de código
• Lunes 23 de noviembre: Semana 11 - Docs PR listo para revisión
  Como recordatorio, vincule todas sus relaciones públicas de k / k, así como las relaciones públicas de los documentos, a este problema para que el equipo de lanzamiento pueda realizar un seguimiento.

• Implementación del controlador: https://github.com/kubernetes/kubernetes/pull/93370
• Documentación: https://github.com/kubernetes/website/pull/24885

¡Hola @soltysh !

Parece que kubernetes / kubernetes # 93370 aún está abierto, pero se está revisando activamente. Solo un recordatorio de que Code Freeze llegará en 2 días el jueves 12 de noviembre . Todos los RP deben fusionarse antes de esa fecha; de lo contrario, se requiere una excepción .

Mejor,
Kirsten

Sí, estoy en eso, si no fusionamos las relaciones públicas en las próximas horas, completaremos la excepción.

¡Se fusionó! ¡¡Impresionante!!