@yunkon-kim let me check the situation.

please hold this PR ;)

@yunkon-kim FYI

NCP 종료 지연 및 VM 루트디스크 용량 지정 불가 현황 – 테스트 결과 및 분석 공유

1. 배경

• CM-Beetle @yunkon-kim의 NCP 테스트 결과를 기반으로 PR 오픈

  • 내용: VM 종료 지연 문제로 CB-TB의 VM 종료 타임아웃을 NCP 드라이버와 동일하게 45분으로 상향 제안

• 특정 CSP에만 적용하더라도 45분 타임아웃은 메인테이너 입장에서 수용 어려움

• CM-BT 테스트에서 나타난 현상이 개인 MapUI 테스트에서는 재현되지 않아, 추가 테스트 진행

2. 주요 테스트 및 분석 결과

(1) VM 종료 지연 원인

• 종료 지연은 실제 종료 문제가 아니라 VM 생성 시 스토리지 초기화(“설정 중”) 상태 지연에 기인

• VM 생성 완료 신호가 오더라도, NCP 콘솔에서는 스토리지가 “설정 중” 상태일 수 있음

  • 이 상태에서는 스토리지 연결 해제/삭제 불가
  • CB-TB/CM-BT에서 즉시 삭제 시도 시, 드라이버가 해당 상태 종료까지 대기 → 결과적으로 종료 시간이 길어짐

• “설정 중” 상태 지속 시간: 2~3분 ~ 10분 이상

  • 이미지 종류에 따라 지연 시간 차이 발생

(2) RootDisk 용량 설정 문제

• 특정 이미지 사용 시, 요청한 RootDisk 크기가 반영되지 않고 NCP 기본값으로 생성됨

• 테스트 셋 비교

  1. @yunkon-kim 테스트:

     • specId: s2-g3, cspImageName: 23789321 (호환되지 않는 GPU 이미지)
     • RootDisk 정상 생성, 하지만 “설정 중” 지연 길어짐

  2. @seokho-son MapUI 테스트:

     • specId: s2-g3, cspImageName: 23214590 (기본 Ubuntu 22.04)
     • RootDisk 크기 지정 반영 안 됨, 대신 “설정 중” 지연 크지 않음 (50초?)

3. 처리 방향 추정

1. CB-TB의 VM 종료 타임아웃 증가는 허용하지 않음 (문제 해결까지 한시적으로 타임아웃 증가 처리 가능. @yunkon-kim 의견주세요.)
2. NCP 드라이버에서 VM 생성 시, 스토리지 “설정 중” 상태 완료까지 포함해 생성 완료 처리
3. NCP 환경에서 스토리지 “설정 중” 지연 원인 분석 필요
4. RootDisk 용량 설정 오류 개선

@seokho-son 추가적인 테스트와 자세한 설명 감사합니다.

이해한 Tumblebug의 정책

Tumblebug은 VM 삭제 요청(option: terminate) 후 10분이 지나면 이슈가 있다고 판단하여 의도적으로 요청을 중단하는 상황이라고 판단됩니다.

생각되는 이슈 공유

관련하여 이슈라고 생각되는 몇 가지를 공유 드립니다.

1. Spider/driver가 요청을 처리 중인 상황에서 Tumblebug에서 중단해버리는 상황이 발생할 수 있습니다. (살짝 결이 다른 부분이 있을 수 있습니다 ;;)
2. 이 때, Beetle은 Internal Server Error 응답을 받게되어 Error handling 및 이슈 리포트 하기가 곤란한 상황입니다.
3. 디버깅 차원에서 로그 분석하면 Spider에서 시간초과로 인해 중단됨 정도를 파악할 수 있는 상황입니다. (시점 파악을 위해 TB_LOGLEVL=debug 설정 필요)

(로그 참고)

cm-beetle                | 9:09AM ERR pkg/client/tumblebug/mci.go:226 > Failed to delete MCI error="[Error from: http://cb-tumblebug:1323/tumblebug/ns/mig01/mci/mmci01?option=terminate] Status code: 500 Internal Server Error, Message: {\"message\":\"[[Error from: http://cb-spider:1024/spider/vm/d29hhlfmh8im6se14hm0] Message: Delete \\\"http://cb-spider:1024/spider/vm/d29hhlfmh8im6se14hm0\\\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)]\"}\n"

추가 의견 및 사유

의견: 실제로 정상적인 처리 과정이 중간에 중단되지 않도록 Timeout 시간 재고가 필요해 보입니다. 일단, 현재 파악된 NCPVPC 상황을 고려하여 15분으로 재 제안 드려보고요. 추후 Spider/driver의 요청 처리시간과 어느 정도는 맞춰가면 좋을 것 같습니다.

사유 및 설명:

현 상황은 VM 생성 과정에서 디스크에 대한 이슈로 인해 VM 삭제가 지연되는 닭이 먼저인지 달걀이 먼저인지 같은 상황이긴 한데요.
일단 Tumblebug의 Timeout을 늘리고 실행해보면, 약 13분 정도에 디스크 관련 사항 확인/해소된 후 VM 삭제가 진행되고 응답을 받을 수 있습니다.

Spider/driver의 요청 처리가 완료될 때까지 Timeout을 늘리면 오류 메시지 또는 정상적인 응답을 받을 수 있겠다고 판단했습니다. 그래서, 45분이 긴 시간이긴하나, 정상적일 수 있는 요청 처리 작업이 중간에 중단되는 것을 피하고자 됨을 막고자 Spider/driver의 요청 처리 시간인 45분으로 설정을 제안했던 부분입니다.

따라서, 정상 처리 범위를 보장할 수 있는 선에서 Timeout 시간을 조율할 필요가 있어보입니다.

일단, 현재 파악된 NCPVPC 상황을 고려하여 15분으로 재 제안 드려보고요. 추후 Spider/driver의 요청 처리시간과 어느 정도는 맞춰가면 좋을 것 같습니다.

@yunkon-kim

의견: 실제로 정상적인 처리 과정이 중간에 중단되지 않도록 Timeout 시간 재고가 필요해 보입니다. 일단, 현재 파악된 NCPVPC 상황을 고려하여 15분으로 재 제안 드려보고요. 추후 Spider/driver의 요청 처리시간과 어느 정도는 맞춰가면 좋을 것 같습니다.

• 맞습니다. CB-SP가 구동 중인데, CB-TB가 닫아버리면, 그 사이에 일어나는 일은 제어 불가능 상태가 됩니다. (원래는 이러한 상황 자체도 추가적으로 제어 및 관리하는게 바람직하겠지만....) 이후, CM-BT에서의 처리는 더 까다롭겠죠.

  • VM terminate -> VM delete 를 구분하여 두 단계로 처리하는 것도 방법입니다.

• 다만, 이번 문제는 NCP의 VM 종료가 15분씩 걸리는 상황 자체가 문제(현재 동작을 정상적인 처리 과정이라고 보기 어려운 측면도 있습니다.), 드라이버 차원에서 이 부분이 어느 정도 해결 되는 것이 바람직해 보이는 상황이긴 합니다. 다른 CSP가 아직 이러한 형태를 보이는 일이 일단 없었기 때문에, 만약 현 상황을 유지하면서 타임아웃을 늘린다면, 여러 CSP 가 섞인 MCI가 다같이 10분 이상 종료 팬딩이 걸리는 것으로 보일 수도 있겠네요.

• NCP 처리가 개선되기 전까지는 15분 타임아웃을 수용하겠습니다.

@seokho-son 정리해 주셔서 감사합니다.

내용 반영(amend)후 force push 했습니다 :)

/approve