9 Commits

Include renames

Author	SHA1	Message	Date
gitea-actions	38722b97a8	chore(gitops): deploy Medusa v1.0.108 [skip ci]	2026-08-15 19:28:44 +00:00
gitea-actions	130177a9f2	chore(gitops): deploy Medusa v1.0.92 [skip ci]	2026-08-13 22:08:17 +00:00
devops	6a0e9965a9	chore(gitops): fijar Medusa a v1.0.90 tras carrera de promocion en CI ... El pipeline build-medusa.yaml (run #90) construyo y publico ecommerce-medusa:v1.0.90 con exito, pero su paso "Actualizar manifiesto Medusa" quedo skipped: el chequeo de promocion segura comparo github.sha contra origin/main y encontro que el commit "chore: release v1.0.91" del frontend ya habia cambiado el HEAD, asi que se abstuvo de sobrescribirlo. medusa.yaml se quedo en v1.0.88, sin el subscriber revalidate-storefront agregado en el PR #9. Bump manual del tag en ambos containers (migrations y medusa) para que Argo CD despliegue la imagen que ya esta en el registry.	2026-08-13 16:39:28 -05:00
gitea-actions	77bf6089fb	chore(gitops): deploy Medusa v1.0.88 [skip ci]	2026-08-13 05:01:13 +00:00
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