/ asignar @apelisse

Parece que todavía necesitamos algunos documentos para preparar esta función para su lanzamiento @apelisse
¿Podría ayudarme con eso? Si hay algo que pueda hacer para ayudar, hágamelo saber.

Como mínimo, buscamos tener un PR de marcador de posición en el repositorio de kubernetes / sitio web. El proceso es bastante sencillo: pague la rama release-1.11 , haga un compromiso de marcador de posición, empújelo a su bifurcación y aumente un PR entre él y la rama release-1.11 , con el estado /hold .

¡¡¡¡¡MUCHAS GRACIAS!!!!!

@apelisse Noté el cambio de hito. ¿Está planeando sacar esto de la versión 1.11?

Sí, no en 1.11. Estoy actualizando el cuerpo.

¡Gracias @apelisse!

No estoy seguro de si es el lugar correcto para comentar sobre esto, pero hemos estado trabajando en nuestro propio tipo de "solicitud del lado del servidor" mediante la construcción de https://github.com/seibert-media/dimios
Si bien este es únicamente un proyecto de tiempo de inactividad en el que esperamos construir nuestra futura interacción con Kubernetes, ambos tropezamos con problemas con todo el proceso de solicitud (discutido en la holgura con algunas personas) pero también pensamos un poco sobre la mejor manera de abordar esto.

Si bien todavía no he trabajado directamente en los K8, podría imaginar contribuir a esta idea / característica si es posible / quisiera.

¿Puede enviar esto por correo electrónico a [email protected]? Podemos hacer un seguimiento allí.

@apelisse No puedo publicar mensajes en dicho grupo ([email protected])

Lo sentimos, es posible que primero deba unirse al grupo: https://groups.google.com/forum/#!forum/kubernetes -wg-apply

Botón azul, "Unirse al grupo para publicar" (arriba a la izquierda)

@apelisse @ kubernetes / sig-api-machinery-feature-orders @ kubernetes / sig-cli-feature-orders -

Esta función se eliminó del hito anterior, por lo que nos gustaría verificar y ver si hay algún plan para esto en Kubernetes 1.12.

Si es así, asegúrese de que este problema esté actualizado con TODA la siguiente información:

• Descripción de la función de una línea (se puede utilizar como nota de la versión):
• Contacto principal (cesionario):
• SIG responsables:
• Enlace de propuesta de diseño (repositorio comunitario):
• Enlace a e2e y / o pruebas unitarias:
• Revisores: (para LGTM) recomiendan tener más de 2 revisores (al menos uno del archivo de PROPIETARIOS de área de código) que estén de acuerdo para revisar. Los revisores de varias empresas prefieren:
• Aprobador (probablemente de SIG / área a la que pertenece la característica):
• Objetivo de función (qué objetivo es igual a qué hito):
  
  
  
  • Objetivo de liberación alfa (xy)
  
  
  • Objetivo de lanzamiento beta (xy)
  
  
  • Objetivo de liberación estable (xy)
  
  

Configure lo siguiente:

• Descripción
• Cesionario (s)
• Etiquetas:
  
  
  
  • etapa / {alfa, beta, estable}
  
  
  • sig / *
  
  
  • tipo / característica
  
  

Tenga en cuenta que la congelación de funciones es el 31 de julio, después de lo cual cualquier problema de funciones incompletas requerirá que se acepte una solicitud de excepción en el hito.

Además, tenga en cuenta los siguientes plazos relevantes:

• Fecha límite de documentos (RRPP de marcador de posición abierto): 21 de agosto
• Congelación de casos de prueba: 8/28

Asegúrese de que todos los RP de las funciones también incluyan notas de la versión relevantes.

¡Feliz envío!

/ cc @justaugustus @ kacole2 @robertsandoval @ rajendar38

¡Creo que todo está ahí @justaugustus! Gracias

¡Gracias por la actualización, @apelisse!

¡Hola! @apelisse Soy el luchador de los Documentos de esta versión. ¿Existe alguna posibilidad de que pueda abrir un PR de documentos contra la rama de la versión 1.12 como marcador de posición? Eso nos da más confianza en el envío de funciones en esta versión y me da algo con lo que trabajar cuando comenzamos a hacer revisiones / ediciones. ¡Gracias! Si esta función no requiere documentos, ¿podría actualizar la hoja de cálculo de seguimiento de funciones para reflejarla?

@zparnold Cambió el hito de 1.12 a 1.13 :-). Puedes olvidarte de esto por ahora, gracias.

Será alfa, sería bueno documentarlo. Jenny dijo que intentaría armar algo. [EDITAR: problema incorrecto, ignorar]

El martes, 21 de agosto de 2018 a las 12:44 p.m. Antoine Pelisse [email protected]
escribió:

@zparnold https://github.com/zparnold Cambió el hito de 1.12
a 1,13 :-). Puedes olvidarte de esto por ahora, gracias.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/features/issues/555#issuecomment-414797736 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAnglgxXgV0DuPpOq4P4UZZjMY8Fcx6Lks5uTGMDgaJpZM4TKb_j
.

Lo siento, vi esto en mi correo electrónico y lo confundí con el problema de la función de ejecución en seco. Sí, la aplicación del lado del servidor no se inicia en 1.12.

@lavalamp @apelisse Haré los cambios en la hoja de cálculo. gracias por informarnos! cc @justaugustus

¿Hay algún problema o relaciones públicas que podamos rastrear para comprender mejor qué trabajo se está haciendo para obtener qué funcionalidad en 1.13 como parte de esto?

@spiffxp No tenemos ningún problema en este momento. tenemos un grupo de trabajo para esto y hacemos un seguimiento de las tareas en una hoja de cálculo. Intentaré crear un problema para realizar un seguimiento del progreso y aumentar la visibilidad, gracias.

¿No es este el problema?

Para relaciones públicas, mire aquí: https://github.com/kubernetes-sigs/structured-merge-diff/pulls

También busque en el repositorio principal, busque "rama de función" en el nombre (por ejemplo, Jenny tiene un cambio de API en este momento).

Tenemos notas de nuestra reunión quincenal aquí: https://docs.google.com/document/d/1j_UqnJRvB7AywfZauHybVVNCOoDDA1AGWGxzPGE08ko/edit# (únase a la lista de correo wg-apply si desea leer)

También tenemos grabaciones de reuniones, aunque podríamos estar detrás de su publicación.

@lavalamp @apelisse ¿ estos 3 RP los únicos pendientes?

@lavalamp correcto, mi Q era más si alguna de las cosas de la rama de características iba a aterrizar en el maestro, de lo contrario, no parece que esto deba estar en nuestro radar; las notas de wg-apply son bastante espartanas en ese sentido

Está el documento de la

Basado en su último comentario en las notas de la reunión sig-api-machinery , estoy tratando de determinar qué elementos de trabajo deberíamos estar atentos "no estoy seguro de que lleguemos a alfa a tiempo" y si "alfa" implica el aterrizaje de la función. rama para dominar

@spiffxp Sí, llegar a alfa es lo mismo que fusionar la rama de funciones de nuevo en la maestra.

@AishSundar No, hay muchos PR aún por escribir. Mire los PR cerrados en ese repositorio para obtener una estimación de la velocidad reciente. Además, necesitaremos más RP para la rama de funciones en el repositorio principal.

¿Pueden ayudarme ustedes dos a comprender por qué este nivel de detalle es necesario / útil? Todavía tenemos 3 semanas antes de que algo se congele o se derrame, ¿no? Si la rama no se fusiona para entonces, tendremos que eliminar esto.

@lavalamp dado que este es un ciclo de lanzamiento corto, el equipo de lanzamiento está tratando de evaluar, desde el principio, la cantidad de trabajo pendiente para cada función planificada y las posibilidades de posibles errores. Esto nos ayudará a rastrearlos mejor a lo largo del ciclo.

Definitivamente, queda algo de trabajo por hacer para obtener esto en 1.13 y las posibilidades de que se deslice son no despreciables. Sin embargo, todavía queremos arriesgarnos y esperamos que las pocas semanas que quedan sean suficientes para llegar a la calidad alfa.

Me complace ayudarlo a rastrear ese artículo de cualquier manera posible y puedo volver a comunicarse con usted regularmente para brindarle un estado. Espero que ayude, gracias.

@apelisse por ahora, si puede

@ kacole2 como para su información

No estamos rastreando nuestro trabajo a través de problemas específicos que necesitan relaciones públicas específicas escritas, eso sería bastante pesado para nosotros. Estamos utilizando esta hoja de cálculo: https://docs.google.com/spreadsheets/d/1ZHTDyiQssYBzs7DQWQd70bNQybeyS0m-S1aIS_zo-78/edit?pli=1#gid = 0

(probablemente ya esté en algún grupo de correo electrónico que tenga acceso)

En un chat sin conexión con @spiffxp , parece que en realidad estás tratando de evaluar el riesgo; Creo que las preguntas anteriores en realidad no tienen sentido para este esfuerzo en particular dado que esto está sucediendo en una rama de características, que es probablemente la razón por la que estamos hablando entre nosotros.

• En términos de riesgo para la estabilidad, no lo fusionaremos si no alcanza el listón antes de que se cierre la ventana, por lo que hay muy poco riesgo. Todos nuestros cambios están en la rama de funciones u otros repositorios, por lo que no es como si dejáramos el maestro en un estado medio roto si no lo hacemos.
• En cuanto al riesgo de no llegar a la meta a tiempo, somos conscientes de que el tiempo es corto y hay muchas posibilidades de que no logremos el lanzamiento.

Hola @lavalamp y @apelisse , soy el dev-1.13 del sitio web k / y enviarme un enlace? Si ya tiene un PR de documentos abierto, o si esto no requiere documentos en el sitio web k /, hágamelo saber.

La fecha límite para los marcadores de posición para la versión 1.13 es el 8 de noviembre. Por lo tanto, es importante hacer un RP de documentos lo antes posible.

Si tiene alguna pregunta sobre este tema, me complacerá ayudarlo. También puedes enviarme un mensaje con holgura (también voy a ir allí).

¡Gracias!

@tfogo ¡ Gracias por tu ayuda! Lo creé aquí: https://github.com/kubernetes/website/pull/10812

Hola @lavalamp y @apelisse : soy Enhancements Shadow por 1.13. Al leer este hilo y considerar el método de seguimiento de esta función, ¿podría informar al equipo de lanzamiento sobre la probabilidad de que esta mejora se convierta en el lanzamiento 1.13?

El aguanieve de código comienza el 9/11 y la congelación del código es el 15/11.

¡Gracias!

Hola @guineveresaenger , todavía hay posibilidades de que nos

@apelisse, ¿podemos marcar el tiempo de la decisión de pasar / no pasar para el miércoles (14/11) de la próxima semana? En este punto del ciclo, esperamos que todas las mejoras de 1.13 tengan todos los códigos y PR de prueba fusionados o muy cerca de fusionarse. Entiendo que esta función se está desarrollando en una rama de funciones. Pero con la congelación de código el próximo viernes (16/11), debemos fusionarlo con el maestro al menos antes del miércoles temprano para obtener señales de CI estables durante un par de días del maestro. Si eso no es posible, tendremos que llevarlo a 1,14. Gracias

@ kacole2

Encontramos un par de errores en el último segundo, por lo que fusionaremos esto como lo primero para 1.14 cuando se abra master.

Gracias por la actualización @lavalamp.

@ kacole2 @tfogo @marpaia @ kbarnard10 como para su información

@apelisse @lavalamp Hola: Soy el líder de la mejora para la versión 1.14 y estoy revisando este problema para ver qué trabajo (si corresponde) se está planificando para la versión 1.14. La congelación de mejoras es el 29 de enero.

Hola @claurence , estamos planeando lanzar esta característica alfa este ciclo. Acabo de actualizar la descripción para reflejar el nuevo hito. ¿Algo más que necesite actualizar?

¡@apelisse suena bien! Agregaré esto a nuestra hoja de seguimiento 1.14.

¿Cómo se vería la solicitud de API realizada por el cliente después de esto? Supongo que enviará la definición de recurso local completa, pero ¿seguirá siendo una solicitud de PATCH? ¿O un PUT?

Estoy muy emocionado con esto, elimina mucha complejidad de los clientes personalizados.

Sí, recibirá el objeto local en el verbo PATCH, con un tipo de contenido específico.

Por cierto, el enlace a la propuesta de diseño está roto.

Arreglado, gracias, buena captura.

Este parece ser el último enlace https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/0006-apply.md

Por cierto, todos los documentos de diseño de Google vinculados allí no se pueden ver públicamente.

Hola Felix, ese documento necesita una limpieza masiva, me ocuparé de eso justo después de congelar el código (o antes si tenemos tiempo extra). ¡Gracias!

Estoy de vuelta, tal vez pueda actualizar el KEP.

/ asignar lámpara de lava

¡Hola @apelisse! Soy uno de los documentos v1.14 lanzan sombras.

¿Esta mejora requiere nuevos documentos (o modificaciones)?

Solo un recordatorio amistoso de que estamos buscando un PR contra k / website (branch dev-1.14) para el viernes 1 de marzo. Sería genial si es el comienzo de la documentación completa, pero incluso un PR de marcador de posición es aceptable. ¡Hazme saber si tienes alguna pregunta!

Gracias por el recordatorio @ cody-clark, ¡definitivamente necesitamos documentación!

¡Perfecto! Lo marcaré en la hoja de seguimiento. ¡Gracias por la rápida respuesta, @apelisse!

@apelisse revisando el KEP para esta mejora. No veo ningún plan de prueba. ¿Alguien puede ayudar a RR.PP. en los planes de prueba para esta mejora? Esta información es útil para saber si esta función está lista para el lanzamiento y es especialmente útil para CI Signal.

Si no tenemos planes de prueba, esta mejora correrá el riesgo de incluirse en la versión 1.14

@claurence He actualizado la descripción, ¡avísame si esperabas algo diferente! ¡Gracias!

Hola, sombra de mejora 1.14 aquí. Code Freeze es el 7 de marzo y todos los RP deben fusionarse para entonces con su problema para hacer la versión 1.14. ¿Qué relaciones públicas de K / K abiertas todavía tienes que fusionar? Gracias

Hola @lledru , tenemos algunas relaciones públicas en proceso que deberían fusionarse en una semana más o menos. ¡Ninguno de ellos está realmente bloqueando el lanzamiento y absolutamente podríamos lanzarlo en el estado actual!

hola @apelisse ,
¿Puede enviar un PR contra el KEP con el plan de pruebas?
Esta información es útil para saber si esta función está lista para el lanzamiento y es especialmente útil para CI Signal.
Si no tenemos planes de prueba, esta mejora correrá el riesgo de incluirse en la versión 1.14
Muchísimas gracias.

Hola @apelisse , la fecha límite de documentación fue el pasado viernes 1 de marzo (para abrir un marcador de posición de relaciones públicas). ¿Tiene algún RP en vuelo para los documentos dev-1.14? ¿Sigue apuntando a 1,14?

Hemos creado el marcador de posición de la documentación: https://github.com/kubernetes/website/pull/12898. No estoy seguro de que sea correcto, pero al menos existe :-)

@lledru Gracias por el recordatorio, @jennybuckley está trabajando para actualizar el KEP.

@lledru Ahí está: # 878

@apelisse ¿ algún trabajo planeado aquí para 1.15 o quedarse en Alpha?

Sí, con suerte será beta 1.15

Gracias @apelisse. Cuando sea el momento adecuado, elimine los k / k PR asociados con los criterios de graduación beta que se indican en el KEP.

/ hito v1.15
/ etapa beta

Hola @apelisse. Veo que tenía un PR de marcador de posición para 1.14, pero necesitamos un PR contra k / website (branch dev-1.15) que vence el jueves 30 de mayo. Sería genial si es el comienzo de la documentación completa, pero incluso un PR de marcador de posición es aceptable. ¡Hazme saber si tienes alguna pregunta!

@simplytunde @apelisse Me ocuparé de ello, ya que todavía tengo algunas cosas que poner en los documentos para mi tarea "clear managedFields".

¡Gracias @kwiesmueller, avíseme si puedo ayudar!

Hecho: https://github.com/kubernetes/website/pull/14300
Podemos usar esto como un marcador de posición PR y usarlo para otras cosas que podríamos querer agregar para 1.15

Estoy más que emocionado de que esto aterrice (¿el próximo mes?).
¿Hay alguna forma de probarlo ya (en Minikube)?

Hola @apelisse @kwiesmueller . Code Freeze es el jueves 30 de mayo de 2019 @ EOD PST . Todas las mejoras que se introduzcan en la versión deben ser de código completo, incluidas las pruebas , y tener documentos PR abiertos.

Enumere todos los k / k PR actuales para que se puedan rastrear cuando se congelan. Si los RP no se fusionan por congelación, esta función se deslizará durante el ciclo de lanzamiento de 1.15. Solo se permitirán problemas de bloqueo de versiones y RP en el hito.

Si sabe que esto se deslizará, responda y háganoslo saber. ¡Gracias!

Realmente no veo cómo se haría esto mediante la congelación de código. Creo que puedes marcarlo para 1,16: - /

😭

@felixfbecker Puede usar cualquier kubernetes 1.14 o posterior con la función ServerSideApply habilitada para probarlo.

En minikube, sería algo así como ... minikube start --feature-gates=ServerSideApply=true hasta donde yo entiendo!

Lo sentimos, nos lo perdimos, tenemos un problema de escalabilidad que debemos abordar primero.

/ hito claro

Habilita todo lo que se ha lanzado en 1.14 más lo que fusionamos en master desde entonces.
Me encantaría saber más sobre las funciones que desea, lo que está creando con ellas y lo que no le gusta de la función. No dude en enviarme un ping en holgura (apelisse @)

¿Ese último comentario fue dirigido a mí?

@felixfbecker y alguien más que borró su publicación ;-)

@felixfbecker Fui yo. Lo siento, borré mi publicación ya que encontré la respuesta después de tropezar con este hilo 🙂

Hola @apelisse , soy el 1.16 Enhancement Shadow. ¿Esta característica va a graduar las etapas alfa / beta / estable en 1.16? Por favor, avíseme para que pueda agregarse a la hoja de cálculo de seguimiento 1.16 y pueda actualizar las etiquetas de etapa e hito.

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.

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

Gracias.

Sí, estamos planeando lanzar esta función como Beta.

/ remove-label tracked / no
/ etiqueta rastreada / sí
/ hito v1.16

Hola, @apelisse @lavalamp Soy el líder de lanzamiento de documentos v1.16.

¿Esta mejora (o el trabajo planificado para v1.16) requiere algún documento nuevo (o modificaciones)?

Solo un recordatorio amistoso que estamos buscando un PR contra k / sitio web (sucursal dev-1.16) para el viernes 23 de agosto. Sería genial si es el comienzo de la documentación completa, pero incluso un PR de marcador de posición es aceptable. ¡Hazme saber si tienes alguna pregunta!

¿Hay una versión limitada de la aplicación del lado del servidor disponible en la v 13 (ahí es donde está mi clúster)? Algunos intercambios anteriores parecían implicar que puede ser. Mi caso de uso es para crear pods / despliegues / servicios en el ciclo de reconciliación de un operador. Usar api / core <> Pod, etc.es tedioso y propenso a errores, y poder usar una API de servidor para aplicar yaml sería mucho más limpio para mí. Gracias por cualquier sugerencia.

@champak , puede probarlo activando la función de puerta "ServerSideApply" de su apiserver, pero tenga en cuenta que esta sigue siendo una función alfa.

La congelación del código de

@ kacole2 Sí, tenemos algunos:

• https://github.com/kubernetes/kubernetes/pull/81754
• https://github.com/kubernetes/kubernetes/pull/78738
• https://github.com/kubernetes/kubernetes/pull/81816

También necesitamos otro RP trivial para habilitar la función.

¿Cuáles son los criterios para que algo ingrese a la versión beta? Probé la aplicación del lado del servidor, pero no parece utilizable realmente como un reemplazo de la aplicación del lado del cliente que kubectl hace: https://github.com/kubernetes/kubernetes/issues/80916

@felixfbecker ¡ Lo siento, se me escapó! Gracias por intentarlo. Estoy de acuerdo en que algo está mal y tenemos que arreglarlo para la versión beta.

Pero en general, suena un poco como si tuviera la expectativa de que esta es una extensión de la aplicación del lado del cliente, en realidad es más como un sistema paralelo: use uno u otro. El mecanismo de transición general es seguir los consejos de Jenny en su error. Hicimos esto para brindar una experiencia muy segura: puede elegir exactamente qué comportamiento desea.

Proporcionaremos una experiencia de transición sin problemas cuando desaprovechemos la solicitud del lado del cliente.

Hola @apelisse , parece que https://github.com/kubernetes/kubernetes/pull/81816 no se fusionó antes de la congelación del código y no está en el Tide Merge Pool . Esta función se eliminará de la v1.16. Si aún desea que esto sea parte de la versión 1.16, presente una excepción.

Las prs obligatorias se fusionaron, esto es beta ahora.

El viernes 30 de agosto de 2019 a las 4:58 a.m. Kendrick Coleman [email protected]
escribió:

Hola @apelisse https://github.com/apelisse , parece que
kubernetes / kubernetes # 81816
https://github.com/kubernetes/kubernetes/pull/81816 no se fusionó antes
congelación de código y no está en el Tide Merge Pool https://prow.k8s.io/tide .
Esta función se eliminará de la v1.16. Si aun así quisieras
si esto es parte de la versión 1.16, presente una excepción
https://github.com/kubernetes/sig-release/blob/master/releases/EXCEPTIONS.md

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/enhancements/issues/555?email_source=notifications&email_token=AAE6BFRCLZC47AWM6AQMJE3QHEDOPA5CNFSM4EZJX7R2YY3PNVWWK3TUL52HS4DFVDVREXWJWK3TUL52HS4DFVODVREXG43V2 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAE6BFRKMWNNIOAIINJGBELQHEDOPANCNFSM4EZJX7RQ
.

@lavalamp, ¿te importaría aclarar? ¿Estás diciendo que https://github.com/kubernetes/kubernetes/pull/81816 no era obligatorio para que esta función estuviera en versión beta?

@guineveresaenger No es obligatorio que esta función esté en versión beta. Ese PR es para abordar los problemas de escalabilidad y se puede fusionar en una versión futura, no cambia la API y solo mejora el rendimiento en clústeres donde muchas cosas son administradas por esta nueva característica.

@guineveresaenger Sí, es opt-in por objeto en beta 1, por lo que no es necesario ya que ya no hay un impacto global en el rendimiento.

gracias por avisarme @lavalamp

Hola @lavalamp @apelisse - 1.17 Las mejoras conducen 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, enumere todos los RP k / k relevantes en este número para que se puedan rastrear correctamente. 👍

¡Gracias!

/ hito claro

Hola @mrbobbytables , estamos planeando grandes mejoras en esta función para la próxima versión, pero todavía no planeamos pasar a GA. Gracias.

@apelisse señaló: ¡gracias por la rápida respuesta! 😄

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

Estamos trabajando en una versión "beta 2" de esta función para la versión 1.18, no estoy seguro de cómo / si necesitamos rastrear eso, pero felices de seguir un proceso.

Hola @apelisse , ¡gracias por resaltar eso! Lo rastrearemos como un cambio dentro de la versión beta en la hoja de mejoras. ¿Habrá algún cambio en el KEP asociado con esto? ¿O esto solo estará relacionado con los cambios de código? Si pudiera vincular todos los k / k PR asociados con esto para que podamos rastrearlo, sería genial.

Si está realizando cambios en KEP, la congelación de mejoras será el 28 de enero
Code Freeze será el 5 de marzo .

¡Gracias!

/ hito v1.18

Podríamos fusionar https://github.com/kubernetes/enhancements/pull/1442 hasta el 28.
Quizás incluso https://github.com/kubernetes/enhancements/pull/923.

Y acabo de ver que https://github.com/kubernetes/enhancements/pull/1123 se fusionó, por lo que la implementación también podría convertirse en 1.18.

Hola, @apelisse : soy una sombra de Docs en el equipo de lanzamiento de la versión 1.18.

¿Este trabajo de mejora planificado para la versión 1.18 requiere algún documento nuevo o modificaciones a los documentos existentes?

Si no es así, ¿puede actualizar la hoja de seguimiento de mejoras 1.18 (o avíseme y lo haré)?

Si se requieren actualizaciones de documentos, recuerde que los PR de marcador de posición en el sitio web k / (sucursal dev-1.18) vencen el viernes 28 de febrero.

¡Hazme saber si tienes alguna pregunta!

Actualmente estamos trabajando en los documentos, ¡gracias por el recordatorio!

Hola @apelisse @kwiesmueller ,

Solo un recordatorio amistoso de que el código congelado para 1.18 es el 5 de marzo de 2020 .

A medida que avanzamos hacia la congelación del código, enumere / enlace a cualquier RP en el que esté trabajando para graduar esta mejora.

¡Gracias por el recordatorio!

Hola @apelisse @kwiesmueller ,

Dando vueltas hacia atrás a medida que nos acercamos a la congelación del código. Enumere cualquier RP de k / k en el que esté trabajando para que podamos realizar un mejor seguimiento de este problema .

Creo que no lo lograremos con las cosas en las que estoy trabajando.
@apelisse podría tener algunos y probablemente @julianvmodesto con dryrun y diff?

He creado el marcador de posición doc PR: https://github.com/kubernetes/website/pull/19286

Hola @apelisse, recordatorio amistoso de que el código congelado para 1.18 es el 5 de marzo . Solo faltan unos días. Gracias por abrir el documento PR de arriba ... ¿podría vincular a cualquier PR K / K relevante para esto para que podamos rastrear mejor el progreso de la mejora a medida que nos acercamos a la congelación del código?

¡Muchas gracias!

Hola @apelisse , desafortunadamente https://github.com/kubernetes/kubernetes/pull/88875 no se fusionó antes de la congelación del código (parece que aún necesita ser aprobado). En este punto, deberá presentar una solicitud de excepción para este.

/ hito claro

¿Qué está pasando con esto?

Todavía estamos en fase beta, trabajamos en nuevas mejoras, pero todavía no estamos listos para GA. ¡Lanzaremos una publicación de blog en unos días sobre esto!

Hola @apelisse : 1.19 Mejoras.

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

Hola, no tenemos previsto promocionar esta función en este ciclo. Gracias.

Gracias @apelisse por las actualizaciones. Actualizaré la hoja de seguimiento en consecuencia. : +1:

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 @apelisse

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

Gracias,
Kirsten

Realmente no, estamos planeando seguir mejorando la función existente, pero no hay una graduación programada para la 1.20, ¡gracias!