[AIP-3127] feat: 프로젝트 삭제 시 해당 프로젝트의 템플릿 정리

[joonseolee]

Summary

• project CR 이 삭제될 때 그 프로젝트에 속한 템플릿을 aipub-backend 에 요청해 함께 정리한다
• template 의 SoT 는 DB, project 의 SoT 는 k8s 라 두 저장소의 생명주기가 어긋나 있던 문제를 맞춘다
• 템플릿 삭제 요청이 실패해도 프로젝트 삭제와 나머지 reconcile 은 계속 진행한다(best-effort)
• 앞으로 늘어날 v1alpha2 API 를 위해 전용 ApiClient 를 분리한다

변경 내용

domain/aipubbackend — 백엔드 호출

TemplateService / TemplateServiceImpl 추가.

DELETE /api/v1alpha2/templates?projectName={name}  ->  204

기존 ImageHubService, RepositoryService 와 동일하게 ApiClient.buildCall + CallHelper 패턴을 따른다.

configuration — v1alpha2 클라이언트 분리

AipubConfiguration 이 만들던 ApiClient 는 basePath 가 /api/v1alpha1 로 고정이었다. 신규 엔드포인트가 v1alpha2 라 전용 클라이언트를 하나 더 둔다.

• 인증(basic auth)·SSL 설정은 기존과 동일하고 basePath 만 다르다
• 생성 로직은 buildClient(properties, basePath) 로 묶어 중복을 없앴다
• 앞으로 추가될 v1alpha2 API 도 이 클라이언트를 재사용한다
• app.aipub.enabled=false 면 기존 서비스들과 같이 no-op 으로 동작한다 — 신규 설정값은 없다

controller/cr — 삭제 훅

ProjectReconciler.reconcileTerminatingProject() 에서 네임스페이스가 정리된 뒤 finalizer 를 떼기 직전에 템플릿 삭제를 요청한다.

호출은 try/catch 로 감싼다. 근거:

• 백엔드 장애가 project 를 Terminating 에 묶어두면 안 된다
• 같은 reconcile 루프의 finalizer 제거·상태 갱신까지 함께 중단되면 안 된다
• 여기서 놓친 템플릿은 aipub-backend 의 고아 템플릿 정리 배치가 주기적으로 회수한다

관련 변경

AIP-3127 은 두 저장소에 걸쳐 있다.

• 이 PR: project CR 삭제 시 삭제 API 호출 (TO-BE 1)
• ten1010-io/aipub-backend feature/AIP-3127: 삭제 API 신설 + 고아 템플릿 정리 배치 (TO-BE 2)

배포 순서: aipub-backend 가 먼저 떠 있어야 이 호출이 404 를 받지 않는다. 순서가 뒤집혀도 best-effort 라 장애로 번지지는 않고 배치가 회수한다.

Test plan

• ./gradlew clean build 통과 (전 모듈)
• 프로젝트가 삭제되면 그 프로젝트의 템플릿도 함께 정리한다
• 템플릿 정리에 실패해도 프로젝트 삭제는 멈추지 않는다
• 삭제 중이 아닌 프로젝트는 템플릿을 건드리지 않는다
• 백엔드 엔드포인트 실호출 검증 (로컬 격리 환경, 운영 무접촉)
  • ?projectName=alive-project → 204, 대상만 삭제
  • ?projectName=no-such → 204 (대상 없어도 성공)
  • 파라미터 누락 → 400
• 실제 클러스터에서 project CR 삭제 후 템플릿 정리 확인 (미수행)
• 백엔드 다운 상태에서 project 삭제가 정상 완료되는지 확인 (미수행 — 단위 테스트로만 검증)