5 Commits

Include renames

Author	SHA1	Message	Date
devops	e9c93bfb82	fix(medusa): usar flags explicitos en pg_isready en vez de DATABASE_URL crudo ... El init container wait-for-postgres pasaba $DATABASE_URL completo a pg_isready. Al agregarle ?sslmode=disable (via create-commerce-secrets.sh), pg_isready fallaba con "no attempt" (exit 3, conninfo invalida para su parser de URI) y el pod quedaba atascado en Init indefinidamente, sin llegar nunca al CrashLoopBackOff visible. Postgres, DNS, Endpoints y NetworkPolicy estaban sanos; el fallo era puramente del parseo de la URI. Se reemplaza por -h/-p/-U/-d explicitos (host y puerto fijos del Service, usuario y db ya disponibles via envFrom), asi el init container queda inmune a query params futuros en DATABASE_URL.	2026-08-10 00:27:10 -05:00
devops	7a83ed61b9	fix(medusa): forzar podAffinity con commerce-postgres para evitar blackhole MTU cross-node ... Diagnostico: pg_isready y el cliente pg de Medusa fallan de forma consistente (100%, 186/186 intentos) cuando el pod queda agendado en un nodo distinto al de commerce-postgres-0. TCP handshake (nc/ping) funciona cruzando nodos, pero el primer paquete de datos real de la sesion nunca llega - blackhole de PMTU Discovery entre los nodos del cluster k3d (flannel VXLAN / MTU del bridge Docker subyacente). Se agrega podAffinity requiredDuringSchedulingIgnoredDuringExecution (no nodeSelector fijo, mantiene portabilidad) para que medusa-deploy siempre comparta nodo con commerce-postgres-0 y evite cruzar el blackhole. Es un workaround, no el fix de raiz: documentado en docs/known-issues.md junto con el TODO de ajustar el MTU del cluster a 1400.	2026-08-09 02:34:15 -05:00
devops	f4ad14028e	fix(medusa): agregar initContainer wait-for-postgres para evitar CrashLoopBackOff por fallo transitorio de red en arranque	2026-08-09 01:29:43 -05:00
gitea-actions	7066f2d871	chore(gitops): deploy Medusa v1.0.85 [skip ci]	2026-08-02 07:07:12 +00:00
devops	aa857bc2ae	fase 1	2026-07-31 23:27:01 -05:00