[whi02]

Summary

• 클론 대상 스토리지 선택: .env의 NODE_{N}_CLONE_STORAGES(쉼표 구분)에 후보를 적은 노드는, 후보 중 사용률 80% 미만이고 VM 디스크(티어 크기)가 들어가는 스토리지에서 남은 용량이 가장 큰 곳을 골라 clone.post(storage=...)로 클론 (mon_service.select_clone_storage)
• SSD 검사 기준: 후보가 설정된 노드는 합산 SSD 80% 검사 대신 스토리지별로 검사. 설정이 없는 노드는 기존 동작 그대로(합산 검사, storage 인자 없음). 대시보드·Discord 리포트는 그대로 합산 표시
• 실패 처리: 후보 없음 507, 스토리지 조회 실패 503. VMID·IP·DB 기록 전에 선택해서 실패해도 남는 것이 없음. 다른 스토리지로 대체 시도하지 않음
• 클론 실패 정리 (fix): _wait_for_clone의 HTTPException(클론 실패·타임아웃) 때 DB 레코드만 지우고 Proxmox VM이 남던 문제 수정. 정리 코드를 _cleanup_failed_vm_resources로 묶어 두 예외 분기에서 함께 쓰고, VM이 이미 없을 때(does not exist)만 lock 대기·삭제를 건너뜀. 권한·일시 오류면 삭제를 시도
• 오류 메시지 (리뷰 반영): _wait_for_clone이 Proxmox exitstatus 원문(스토리지·볼륨 이름 포함 가능)을 사용자 메시지에 넣던 것을 로그로만 남기고 일반 문구로 변경. 스토리지 목록 응답이 리스트가 아니면 503
• 상수 분리: 80% 기준을 RESOURCE_USAGE_THRESHOLD_PCT로 분리해 create_vm과 스토리지 선택이 같은 값을 사용
• 동시성: 선택을 create_vm() 안에서 하므로 기존 VM 생성 큐(워커 1개)가 순서를 보장. 백엔드가 프로세스 1개로 돈다는 전제
• 명세: SPEC.md (공개 저장소라 운영 정보는 빼고 일반화)

Test plan

• tests/test_clone_storage.py 신규 32개 + test_vm_lifecycle.py·test_vm_policy.py·test_discord_daily_report.py·test_monitoring_rbac.py — 111 passed (Python 3.11, main 기준)
• ruff check . (CI와 같은 0.15.22) — All checks passed
• 배포 전: 운영 백엔드가 프로세스 1개인지 확인 (WEB_CONCURRENCY 없음 또는 1, --workers 없음)
• 배포 후: 운영 .env에 NODE_3_CLONE_STORAGES 설정 후 백엔드 재시작
• 배포 후: gsmgpu3에 테스트 VM 생성 → Proxmox Hardware에서 디스크가 새 스토리지에 있는지 확인 후 콘솔에서 삭제

참고

• develop에 먼저 머지된 PR #174의 변경만 main에 바로 올린다. develop에는 아직 main에 없는 다른 PR(test: 스냅샷 생성 엔드포인트 오류 응답 회귀 테스트 추가 #168, fix: iptables 명령 예외 시 추가 규칙 롤백 #169, perf: 모니터링 노드별 30초 캐시와 동시 요청 중복 조회 방지 #170)이 있어 develop → main으로 올리면 같이 배포되므로, 이 브랜치는 main에서 따서 #174의 커밋 7개만 cherry-pick했다
• 코드 리뷰에서 나온 타임아웃 후 정리 한계는 #175로 분리

[soyuo]

LGTM