En el post anterior conté cómo oci_management despliega un Odoo completo a partir de un formulario. Pero hay una pieza anterior: antes de desplegar, necesitas saber qué módulos existen, en qué versión, y cómo empaquetarlos. Ese es el trabajo de oca_management. Y fue donde empezó todo.
Este módulo nació de una frustración concreta: perder tiempo buscando addons por GitHub cada vez que arrancaba un proyecto. Lo que empezó como una utilidad interna acabó convirtiéndose en la base sobre la que se construyeron oci_management y server_management. Hoy cierro la serie contando la primera pieza del puzzle.
El problema: buscar agujas en un pajar de 140 repos
La OCA (Odoo Community Association) mantiene más de 140 repositorios en GitHub. Dentro de esos repos hay casi 3.000 addons instalables. Cada repositorio tiene ramas por versión de Odoo: 14.0, 15.0, 16.0, 17.0, 18.0, 19.0. Y no todos los addons existen en todas las ramas.
Antes de crear oca_management, si necesitaba saber si sale_commission existía en Odoo 18, el proceso era manual: ir a GitHub, buscar el repositorio (commission), cambiar a la rama 18.0, comprobar si el addon estaba ahí, verificar que fuera instalable, revisar sus dependencias. Repetir para cada addon. Con 50 addons por proyecto, una mañana entera perdida.
Y no era solo la búsqueda. También necesitaba saber qué dependencias arrastraba cada addon, si había conflictos entre versiones, y al final generar un fichero repos.yml coherente para la instalación. Todo eso a mano.
Eso me pasaba cada vez que arrancaba un proyecto nuevo. Así que decidí resolverlo una vez y ya.
258 repositorios OCA indexados en Odoo, con sus ramas y addons.
Buscando sale_commission entre 7.544 addons. Filtrar por versión, por repo, por dependencias.
Qué hace oca_management
oca_management nació para resolver eso. Configuras tu cuenta de GitHub en Ajustes (usuario y token), seleccionas las ramas que te interesan, y le das a sincronizar. El módulo recorre todos los repositorios de OCA vía la API de GitHub, clona cada uno en las ramas activas, y parsea el __manifest__.py de cada addon. En un rato tienes el catálogo completo indexado en Odoo: nombre, versión, categoría, autor, licencia, dependencias y el README.
A partir de ahí, todo es buscar y filtrar. ¿Necesitas un módulo de contabilidad para la 16.0? Filtras por rama y categoría. ¿Quieres ver las dependencias antes de decidir? Las tienes en la ficha del addon. Eso que antes llevaba horas ahora son segundos.
Una plantilla de instalación: seleccionas rama, repos, addons, y generas el repos.yml.
El repos.yml generado, listo para que oci_management lo consuma.
server_management: Odoo sin Docker
Tener el catálogo es útil, pero el valor real aparece cuando conectas ese catálogo con el proceso de instalación. oca_management no se queda en la consulta: te lleva hasta el despliegue.
repos.yml: la pieza que conecta catálogo y despliegue
Cuando ya tienes claro qué addons necesita tu cliente, los seleccionas en la vista de addons y lanzas el wizard de instalación. Le das un nombre, eliges la rama, y oca_management genera automáticamente dos cosas: un repos.yml y un script de instalación.
El repos.yml es un fichero YAML que lista cada repositorio OCA necesario con su URL de clonado y la rama concreta. Es el formato que utiliza git-aggregator, la herramienta estándar del ecosistema Odoo para gestionar múltiples repositorios. Ese fichero es lo que oci_management necesita para montar un despliegue Docker: sin él, no sabe qué repos descargar ni en qué rama. El resultado se guarda en una plantilla de instalación reutilizable: la creas una vez y la aplicas a tantos servidores como necesites.
Instalación nativa, sin Docker
No todas las empresas necesitan Docker. A veces un VPS con Odoo instalado y punto es exactamente lo que el cliente necesita. Para esos casos existe server_management.
Das de alta un servidor en Odoo: IP, usuario SSH, contraseña, puerto. server_management se conecta por SSH, verifica la conexión, y te muestra el estado del disco y el uptime. Cuando quieres instalar, seleccionas el servidor, eliges una plantilla de oca_management, y lanzas el wizard. El módulo sube por SFTP el repos.yml junto con el script de instalación y lo ejecuta en remoto.
Ese script hace una instalación completa: actualiza paquetes, instala PostgreSQL, descarga Odoo desde nightly, ejecuta git-aggregator con el repos.yml para traer los addons OCA, configura systemd, crea la base de datos, y opcionalmente monta nginx con SSL. Todo automatizado, sin Docker.
Servidores dados de alta: ct-139, test Odoo 18.
Detalle del servidor: IP, SSH, estado, disco.
Wizard de instalación: elige la plantilla, el nombre de la base de datos, dominio y certificado.
El mapa completo
Cuatro posts, tres módulos, un flujo:
- oca_management indexa los repositorios OCA, te permite buscar y filtrar addons por versión, y genera el
repos.ymlcon las plantillas de instalación. - oci_management consume ese
repos.ymly despliega un Odoo completo en Docker, ya sea on_premise (con nginx y SSL) o en cloud (detrás de un proxy externo). - server_management consume el mismo
repos.ymly despliega Odoo de forma nativa, sin Docker: directamente sobre un VPS con systemd, PostgreSQL y nginx. - Todo se opera con IA (Claude + skills) desde un único Odoo. Sin cambiar de herramienta, sin terminales abiertos, sin scripts sueltos.
Esto es lo que hay detrás de LTC Labs. Cuatro posts, tres módulos, y un objetivo: que montar un Odoo no sea un proyecto, sea una frase.
Este era el primer módulo que construí. El que empezó como una utilidad interna para dejar de buscar en GitHub se convirtió en la base de todo lo demás.
Si algo de esto te suena útil, mi correo está abajo. Si no, al menos ya sabes que existe la categoría.
Si acabas de llegar, empieza por el primero: ahí está el punto de entrada a la serie completa.