Cambiar de Primary deja de ser un clic mudo — confirmación, historial y aviso al equipo

User value

Cuando cambias qué ordenador vigila tu infraestructura —promocionando o degradando un Agente en el Fleet Manager— ahora sabes exactamente qué vas a mover antes de confirmarlo, queda un historial consultable de quién lo hizo y cuándo, y los administradores de la organización reciben un correo si la vigilancia (el Sentinel) se muda de máquina sin que nadie lo pidiera — por ejemplo, porque el ordenador que vigilaba se apagó de noche.

Cómo usarla

1. Abre el Agent Fleet Manager (botón “Agent” en la barra de navegación, o desde el widget Agent Fleet del Observatory).
2. Pulsa Promote sobre un Agente Secondary: aparece una confirmación propia (#fleet-role-confirm-modal) que nombra las dos máquinas — “Sentinel monitoring will move from OFFICE-PC to RACK-MINI” — con el botón Promote to Primary.
3. Pulsa Demote sobre el Primary: la confirmación avisa de que nadie toma el relevo automáticamente y los targets dejan de vigilarse hasta que promuevas a otro.
4. Bajo la tabla de agentes, la sección Role changes lista cada transición: cuándo, qué agente, de qué rol a cuál, la causa (manual / failover automático / asignación automática) y quién la hizo.
5. Si el Primary cambia de máquina, los administradores de la organización reciben un correo con el asunto [CreaRack] <hostname> is now the Primary agent (<causa>).

Implementación

• Modal de confirmación: #fleet-role-confirm-modal en templates/base.html, sustituye al confirm() nativo del navegador; lógica en static/js/base.js (?v=9).
• Historial persistido: [[entity—terminal—model—agentroleevent]] (modelo AgentRoleEvent, migraciones terminal/0007+0008), escrito por terminal.fleet_events.record_role_change() desde los cuatro puntos que cambian el rol de un Agente: promote, demote, el failover del consumer al desconectarse el Primary, y la asignación automática al registrarse (incluido el barrido que caduca a un Primary mudo >10 min).
• Endpoint de lectura: GET /api/agent/fleet/history?limit=50 (terminal/api/fleet.py::fleet_role_history, permiso fleet:view, hasta 200 filas), consumido por la sección Role changes.
• Aviso por correo: terminal.fleet_events.notify_primary_change(), send_mail a los usuarios role="admin" activos de la organización; solo se dispara si to_role == "primary", había un from_role previo y el Primary anterior (from_agent_id) era OTRA máquina — la asignación inicial de un Agente recién instalado no manda correo, y tampoco la misma máquina recuperando el rol tras un micro-corte. Corrección v1.132.11 (task #304, 15-09-2026): con un solo Agente por organización, cada micro-corte lo degradaba (failover) y su reconexión lo volvía a promocionar (auto_assign) con correo — 57 correos en 7 días y 0 relevos reales, todos con from_agent_id vacío. Ahora terminal/fleet_lifecycle.py::_db_register_locked rellena from_agent_id/from_hostname con el ÚLTIMO Primary del historial (el failover ya lo degradó en la BD; solo AgentRoleEvent lo sabe) y la condición del correo exige que sea distinto del agente que se promociona. La fila del historial se guarda siempre. Tests: tests/api/test_fleet_primary_noise_304.py.
• Auditoría genérica paralela: log_action(request, "SYSTEM", "fleet.promote"/"fleet.demote", ...) sobre [[entity—core—model—systemlog]], desde promote_agent/demote_agent.
• Modelo hermano: [[entity—terminal—model—agentinstance]] es la fuente del campo role actual; este historial registra sus transiciones.
• Todas las escrituras son best-effort: un fallo al guardar el evento o al enviar el correo se registra en el log y no rompe la promoción ni el failover que lo disparó.
• 6 tests nuevos en tests/api/test_fleet_role_events.py (promote con evento+correo+SystemLog, demote sin correo, failover del consumer, orden/aislamiento entre organizaciones y 403 para el rol readonly en el endpoint de historial).

Límites honestos: no hay canal de notificaciones dentro de la propia aplicación — el aviso al equipo son el correo y el historial, nada más. Un promote manual sin Primary anterior (primera promoción de la organización) tampoco manda correo desde v1.132.11: no hay mudanza que anunciar. Y un Agente recién instalado que toma el relevo de un Primary caducado de otra máquina tampoco avisa (su primera asignación no cuenta como mudanza; comportamiento previo, no tocado).

Commits relacionados

• 6645039b (2026-08-31) — feat(fleet): cambiar de Primary con confirmación seria, historial visible y aviso al equipo · task #234 · v1.88.0 (PR #474)
• PR #541 (2026-09-15) — fix(terminal): el correo de ‘cambio de Primary’ solo sale cuando el Sentinel cambia DE MÁQUINA · task #304 · v1.132.11

Véase también

• [[entity—terminal—model—agentroleevent]]
• [[entity—terminal—model—agentinstance]]
• [[entity—terminal—endpoint—fleet]]
• [[entity—core—model—systemlog]]
• [[crearack—monitoring—fleet-manager]]
• [[feature—terminal—agent-health-heartbeat]]
• [[concept—saas—multi-tenancy]]