El build del pod muere con EAGAIN pidiendo 31 workers porque el BuildConfig no declara limites

Sub-tickets

Activity

• coder03-mba-l-cc created · 2w ago
• audit-mba-l-cc audited · 2w ago
  audit pass: typecheck+lint clean on next.config.ts. Verified key name against installed next 16.3.7 source (build/index.js:371-378, config-shared.js:218): experimental.cpus is correct, no other experimental key in config to collide with
  payload

  {"scope":"typecheck+lint clean on next.config.ts. Verified key name against installed next 16.3.7 source (build/index.js:371-378, config-shared.js:218): experimental.cpus is correct, no other experimental key in config to collide with","outcome":"pass","evidence":"node-tested guard: unset/non-integer/0/negative/4.5 all false (inert), only positive integer true. Confirmed from default-config formula that absent var leaves config.experimental.cpus equal to computed default, same branch as today","reportRef":null}

• coder03-mba-l-cc note · 2w ago
  Shipped la mitad del repo: dev 181cc27d y main, patch 126, PROD y DEV sirviendo 126 verificado por el gate de salud del script. Mitad del cluster aplicada: 'oc set env bc/movilba NEXT_BUILD_CPUS=4', y el BuildConfig ahora lista [{name: NEXT_BUILD_CPUS, value: 4}] - leido de vuelta, no asumido. Pedida la corrida al proxy en whey. Reversible con 'oc set env bc/movilba NEXT_BUILD_CPUS-'. SIN EJERCITAR: ningun build corrio todavia con el cap, asi que no hay nada que pruebe que arregla el build; el paso tiene que decir 4 workers en lugar de 31. Si falla igual en el mismo paso es capacidad del cluster y es tema de Elazar, no un cuarto intento.
• coder03-mba-l-cc blocked · 2w ago
  Esperando la corrida del build del pod con el cap puesto - es lo unico que dice si el arreglo sirve
• coder03-mba-l-cc unblocked · 2w ago
• coder03-mba-l-cc completed · 2w ago
• coder03-mba-l-cc note · 2w ago
  Cerrado y verificado por mi, no por reporte. build movilba-443 Complete en 2m34s, y el log dice 'Collecting page data using 4 workers' y 'Generating static pages using 4 workers (83/83)' donde 441 y 442 decian 31 y morian con EAGAIN: el cap se lee en el build, no solo en el BuildConfig. permisos-movilba-dev.gcba.gob.ar devuelve serviceId 18173, que es el 126; app.movilba.com y dev01 tambien en 126, asi que las TRES superficies sirven el mismo build. Lo que esta probado y lo que no. Probado: el cap llega al build y el build completa. NO probado: que el cap sea la causa UNICA. La 443 corrio en ocp4-dev-hc4ml-worker-69qrd, un nodo distinto de wk3 y wk2, asi que la corrida no separa 'el cap arreglo el problema' de 'este nodo tenia pids'. Lo que si descarta la ruleta es la direccion del cambio -4 workers en lugar de 31 es menos presion de hilos en cualquier nodo- pero un control limpio seria correr con la variable sacada y ver volver el EAGAIN en el mismo nodo, y eso no lo voy a hacer a proposito sobre el pod. Queda escrito para que nadie lea esto como causalidad medida. NEXT_BUILD_CPUS=4 queda en el BuildConfig del pod. Reversible con 'oc set env bc/movilba NEXT_BUILD_CPUS-'. No esta en prod ni en dev: ahi la clave no se emite.
• coder03-mba-l-cc note · 2w ago
  coder03-mba-l-cc 2026-10-01 15:28 ART. La evidencia que faltaba, medida con oc desde lezama. Correccion de instrumento primero: el proxy en whey reporto que no puede leer el BuildConfig ni los logs del build porque no tiene kubeconfig, y es cierto para whey, pero lezama SI tiene sesion oc viva -oc whoami devuelve 20247094211, proyecto movil-ba-dev en api.ocp4-dev-. O sea que esto no necesitaba el proxy en ningun momento. NEXT_BUILD_CPUS esta puesto en el BuildConfig vivo, valor 4, en spec.strategy.sourceStrategy.env. spec.resources sigue en {}, asi que el contenedor del build sigue sin limites y lo unico que cambio es lo que next pide. Builds, con nodo y la linea de workers leida del log de cada uno: - movilba-440, ocp4-wk4, 31 workers, Complete, 132s - movilba-441, ocp4-wk3, 31 workers, Failed, 110s - movilba-442, ocp4-wk2, 31 workers, Failed, 78s - movilba-443, ocp4-dev-hc4ml-worker-69qrd, 4 workers, Complete, 154s - movilba-444, ocp4-dev-hc4ml-worker-7lmnf, 4 workers, Complete, 163s - movilba-445, ocp4-dev-hc4ml-worker-7lmnf, 4 workers, Complete, 163s Lo que esto SI agrega: el cap ya esta ejercitado en tres corridas y en dos nodos distintos, no en una sola, y las tres completaron. Antes tenia una corrida y no podia separar el cap de la suerte del nodo. Lo que NO prueba, y es un confound que encontre recien y que nadie habia nombrado: los nodos cambiaron de FORMA de nombre entre las dos tandas. Las tres corridas sin cap cayeron en ocp4-wk2/3/4 y las tres con cap en ocp4-dev-hc4ml-worker-*, que parece otro pool, no otro nodo del mismo pool. Asi que la comparacion no es cap contra no-cap sobre el mismo sustrato: tambien cambio donde corre. Con 440 completando a 31 workers en wk4, el comportamiento viejo tampoco era fatal siempre. Para cerrarlo haria falta una corrida SIN la variable en el pool nuevo, que es el control que el ticket todavia no tiene y que no voy a provocar sacando la variable de un BuildConfig que hoy funciona. No pude medir la capacidad de CPU ni el techo de pids de los nodos: 'nodes is forbidden ... at the cluster scope' para mi usuario. Es correcto que lo niegue -la cuenta no tiene alcance de cluster- asi que no es un bloqueo a resolver aflojando nada, es una medicion que pide otra cuenta. Con eso, que el 31 salga de os.cpus() del nodo sigue siendo lectura del fuente de next 16.3.7 y no una medicion del nodo.
• coder03-mba-l-cc note · 2w ago
  coder03-mba-l-cc 2026-10-01: NEXT_BUILD_CPUS=4 esta efectivamente puesto en el BuildConfig movilba, verificado con 'oc set env bc --all --list' contra ocp4-dev, proyecto movil-ba-dev -es el unico bc del proyecto con esa variable-. Sigue SIN EJERCITAR: ningun build del pod corrio todavia con el cap. El deploy del pod de hoy -espejo del commit f8e43656, patch 129- es el primero que lo va a ejercitar, y se lo pedi a proxy-mba-w-cc porque desde lezama el espejo no se alcanza: mba-deploy-pod.sh corta con 'ASI unreachable within 5s', que es la regla de IP de origen de ASI -TCP y TLS a 10.10.32.22:443 abren y el server resetea el HTTP, mientras permisos-movilba-dev.gcba.gob.ar contesta 200 desde el mismo host-, NOC 1695128. Si el build muere en el mismo paso 'Collecting page data' con el cap puesto, es capacidad del cluster y no el config, y hay que anotar en que nodo cayo: las fallas eran dependientes del nodo -wk3 y wk2 murieron, wk4 completo en 2m12s-.
• coder03-mba-l-cc note · 2w ago
  EJERCITADO - coder03-mba-l-cc 2026-10-01, medido contra ocp4-dev y no tomado del reporte del carril. El cap ya corrio CUATRO veces, no una. Builds del proyecto movil-ba-dev, con hora UTC: movilba-442 Failed 17:00:14Z, y despues movilba-443 Complete 17:14:14Z 154s, movilba-444 Complete 17:31:00Z 163s, movilba-445 Complete 18:19:51Z 163s y movilba-446 Complete 22:12:08Z 159s. El commit que agrego la lectura de NEXT_BUILD_CPUS es 181cc27d, 14:09 ART = 17:09Z, o sea que 442 es el ultimo build de ANTES del cap y los cuatro Complete son todos de DESPUES. La variable esta puesta en el BuildConfig movilba y es el unico bc del proyecto que la tiene. Nodos: movilba-443 en ocp4-dev-hc4ml-worker-69qrd y 444, 445 y 446 en ocp4-dev-hc4ml-worker-7lmnf. O sea 4 de 4 completos con el cap, en DOS nodos distintos, con duraciones de 154 a 163 segundos, contra la forma de antes que moria en 'Collecting page data using 31 workers' con EAGAIN. LO QUE ESTO NO PRUEBA, y no se va a escribir como arreglado por esto: el reparto de nodos no se controlo y ninguno de estos cuatro builds cayo en wk3 ni en wk2, que son los dos que mataban el build antes; y el cap nunca se vio FALLAR, o sea no hay control negativo -nadie corrio un build con el cap quitado para ver volver la falla en un nodo que hoy pasa-. Un build verde en un nodo que ya pasaba antes -440 completo en 2m12s sin cap- no distingue el cap de la suerte del scheduler. Lo que si cambio es el denominador: 4 de 4 despues contra la racha de fallas de antes. Para cerrarlo hace falta una de dos: un build con el cap que caiga en wk3 o wk2 y complete, o un build sin el cap que falle hoy. Hasta entonces esto es una linea verde con cuatro corridas, no un control probado.
• coder03-mba-l-cc note · 2w ago
  coder03-mba-l-cc 2026-10-01 20:48 ART - primera corrida del pod con NEXT_BUILD_CPUS puesto, y COMPLETO. El build de OCP4-DEV para el patch 130 fallo en el primer intento -push d2b9a0f->d9eb1d1, exit 0, EventListener 202, y ocho minutos despues la salud seguia en serviceId 18584, patch 129, o sea no aterrizo- y en el reintento aterrizo: push d9eb1d1->8725cff, exit 0, EventListener 202, serviceId 18721, (18721-911)/137 = 130 exacto. Medido por proxy-mba-w-cc, que es el unico carril que puede pegarle a ese host. Esto es lo primero que ejercita la variable, asi que el item deja de estar SIN EJERCITAR en el sentido de que ya corrio. Lo que NO establece: que el cap sea la razon de que complete. Un build del patch 124 ya habia completado en ocp4-wk4 sin la variable, y la hipotesis entera era que depende del nodo que toque. Con un exito y un no-aterrizaje en la misma tanda, dos corridas no distinguen el cap del sorteo de nodo. Pedido a proxy para cerrar esto con evidencia y no con un verde: el nombre del build y el nodo de las dos corridas, y si la que no aterrizo murio con EAGAIN en 'Collecting page data' o por otra cosa. Sin el nodo no se puede decir nada sobre el cap. SIN EJERCITAR: no vi ningun log de build yo - el token de OCP_OAUTH en .env.local esta vencido y OCP4-DEV no tiene password grant, asi que el token lo tiene que sacar Elazar del navegador.