fix(migration): redirige FK servers.cluster_id vers server_clusters (etait sur l'ancienne table clusters)

migrate_patching_notes_fix_20260507.sql

@@ -0,0 +1,41 @@
+-- Fix : la FK servers.cluster_id pointait sur une ancienne table `clusters`,
+-- pas sur la nouvelle `server_clusters` créée par migrate_teams_pct_workflow.sql.
+-- Conséquence : l'UPDATE final pour rattacher les serveurs Sextan a échoué.
+-- Cette migration redirige la FK vers `server_clusters` puis rejoue l'UPDATE.
+-- Idempotent.
+
+-- 1) Drop l'ancienne FK (peu importe son nom exact, on la cherche)
+DO $$
+DECLARE
+    fk_name text;
+BEGIN
+    SELECT conname INTO fk_name
+      FROM pg_constraint
+     WHERE conrelid = 'public.servers'::regclass
+       AND contype = 'f'
+       AND pg_get_constraintdef(oid) ILIKE '%cluster_id%';
+    IF fk_name IS NOT NULL THEN
+        EXECUTE format('ALTER TABLE public.servers DROP CONSTRAINT %I', fk_name);
+        RAISE NOTICE 'FK % droppée', fk_name;
+    END IF;
+END $$;
+
+-- 2) Recrée la FK vers server_clusters
+ALTER TABLE public.servers
+    ADD CONSTRAINT servers_cluster_id_fkey
+    FOREIGN KEY (cluster_id) REFERENCES public.server_clusters(id) ON DELETE SET NULL;
+
+-- 3) Rejoue le rattachement des serveurs Sextan
+UPDATE public.servers s
+   SET cluster_id = (SELECT id FROM server_clusters WHERE name='Sextan')
+ WHERE LOWER(s.hostname::text) IN (
+    'vdameasxt1','vdameasxt2','vdameasxt3','vdameasxt4',
+    'vrameahtp1','vrameahtp2',
+    'vrameasxt1','vrameasxt2','vrameasxt3','vrameasxt4'
+ );
+
+-- 4) Vérification (optionnel)
+-- SELECT s.hostname, sc.name AS cluster, sc.reboot_delay_min_minutes
+--   FROM servers s LEFT JOIN server_clusters sc ON sc.id = s.cluster_id
+--  WHERE LOWER(s.hostname::text) LIKE '%sxt%' OR LOWER(s.hostname::text) LIKE '%htp%'
+--  ORDER BY s.hostname;