마이그레이션 계획

[kwonkwonn]

Goal

현재 혼용되어있는 파일 및 패키지가 많아 이를 역할별로 분리하려고 함

Acceptance Criteria

api : /api 로 모두 모으는 것이 1차적인 목표.

• /api로 모든 핸들러 이동
• http 헤더 작성 유틸 생성/적용

/request: 현재 사실상 모든 원격호출을 담당하는 것 같음.지금은 그렇지 않지만 하위 레이어의 서비스 함수들을 /reqest에서 담당할 것 같은 걱정이 있음.

• request를 client로 수정
• 현재 각 함수별로 엔드포인트를 하드코딩하는 방식으로 진행되는데, client 는 http timeout 관리, 헤더작성, 에러 const 동기화의 역할만 맡고 함수 엔드포인트 등은 DI 로 해결(오버엔지니어링이 될까 고민중)
• ovn-client 파일 /service/network.go를 /client/ 로 이동
  예시)

// endpoints.go - path 상수만 분리
const (
    EndpointCreateVM       = "/createVM"
    EndpointDeleteVM       = "/DeleteVM"
    EndpointStartVM        = "/BOOTVM"
    EndpointForceShutdown  = "/forceShutDownUUID"
)

service/: 순수한 서비스 함수를 넣을 얘정, 결과적으로는 DI, 값 파싱, infrastructure 관리의 로직

• ssh key gen, guacamole config 와 같은 함수들을 /pkg로 이전, service -> pkg 를 참조하는 구조
• service/vm상의 함수들을 역할별로 분리

pkg/ : 도메인 특화 혹은 util 함수를 각각 가짐. ** 하위 의존성이 없는 파일들의 모음 **

• sshKeygen
• password encryption
• Core, guacamole 등 도메인 특화 작업(원자적인) , 해당 함수들을 service 에서 가져와서 쓰게 할 예정

고민

현재는 DB.Con 을 가지는 패키지를 만들고, pkg/{domain}/{model} 와 같이 pkg 별로 디비 로직을 관리할 예정.
추후에 pkg 내부에서 db 로직을 서로 참조하는 등으로 발전되면 repository로 분리할 듯.(현재 기준에서는 오버엔지니어링 같음)

예상구조

KWS_Control/
  api/              → HTTP handler, req/resp 모델, 응답 헬퍼
  client/           → CoreClient, CmsClient (transport만)
    core/
      client.go
      endpoints.go
    cms/
      client.go
      endpoints.go
  service/          → 오케스트레이션, ControlContext 관리
  pkg/ (or internal/)
    ssh/
    guacamole/
    crypto/
  structure/        → 도메인 모델 (현재 유지)
  startup/          → 초기화 (현재 유지)
  util/             → logger (현재 유지 또는 pkg로)

Notes

해당 이슈는 의견에 따라 자유롭게 수정될 예정입니다.
테스크를 진행할때에는 서브 이슈를 만들고, 체크박스를 선택해주세요

[kwonkwonn]

@wind5052 @ga111o @onebone @ukleon123
의견 주세용

[kwonkwonn]

나름 잘 써놔서 서브이슈 만들면서 plan 모드로 돌리고 검수만 하면서 해도 아마 잘 돌아가지 않을까 싶습니다

[ga111o]

넵 해당 구조로 진행하는 거 좋다고 생각합니다.