Test Scenarios IV0

Test Scenarios — IV0 플랫폼 설치·운영 CLI (mc-admin-cli)

생성: 2026-10-13 · 기준: v07 · 대상: mc-admin-cli(installAll.sh, mcc infra/k8s/rest/api/setup) · 실행: stage(mc-admin-cli-edge) · S10·S26 은 로컬(WSL, origin/develop 7f6f1cc) ← Test Scenarios · IV 허브 · 기능 TC · TC-ADMIN

TC 26개 = 시나리오 26개(IV0_Snn = TC-ADMIN-0nn) · 결과: ⬜ 미실행 7 · 🚧 BLOCKED 1 · ✅ PASS 12 · ⏭️ SKIP 3 · ❌ FAIL 3

서버 상태를 바꾸는 시나리오(설치·삭제·기동·등록)는 ADMIN_CLI_ALLOW_DESTRUCTIVE=1 일 때만 실행되며, 운영 중인 stage 에서는 실행하지 않았다(⬜ 미실행). 실행 방법은 Test-Specs-IV0.

요약

시나리오	기능 TC	제목	유형	결과	spec
IV0_S01	TC-ADMIN-001	Mode A 개발 설치: installAll.sh(1 Developer / Enter localhost / 2 Background) → mcc infra info 전체 healthy	정상	⬜ 공통	IV0_S01
IV0_S02	TC-ADMIN-002	Mode B 운영 설치: installAll.sh(2 Production / FQDN / 2 Background) → Let's Encrypt 발급 · HTTPS 정상 · 전체 healthy	정상	⬜ 공통	IV0_S02
IV0_S03	TC-ADMIN-003	방화벽 포트 점검: 필수 포트 서버 LISTEN + 외부 TCP 접속 (80, 443, 3001, 33002, 7780, 9090, 9000, 3000)	정상	🚧 공통	IV0_S03
IV0_S04	TC-ADMIN-004	IAM 초기화 결과 확인: post-initial 성공 로그 → IAM 관리자·역할·메뉴·기본 workspace/project → INFRA namespace	정상	✅ 공통	IV0_S04
IV0_S05	TC-ADMIN-005	환경 전체 정리: cleanAll.sh(y) → docker 이미지·컨테이너·볼륨·container-volume 삭제	정상	⬜ 공통	IV0_S05
IV0_S06	TC-ADMIN-006	풀스택 이미지 풀 및 기동: mcc infra pull → run -d → 전체 healthy	정상	⬜ 공통	IV0_S06
IV0_S07	TC-ADMIN-007	단일 서비스 타겟 기동: mcc infra stop/run -d -s mc-data-manager → 대상만 재기동, 다른 서비스 영향 없음	정상	⬜ 공통	IV0_S07
IV0_S08	TC-ADMIN-008	중지 → 재기동 → 이미지 업데이트: mcc infra stop → run -d → update (-s 대상)	정상	❌ 공통	IV0_S08
IV0_S09	TC-ADMIN-009	스택 정리: mcc infra remove -v -i → mcc 프로젝트 컨테이너·볼륨·compose 이미지 삭제	정상	⬜ 공통	IV0_S09
IV0_S10	TC-ADMIN-010	Compose Variant 전환: mini(-f docker-compose.mini.yaml) 기동·healthy·정리 / cert(-f docker-compose.cert.yaml) 인증서 발급	정상	✅ 공통	IV0_S10
IV0_S11	TC-ADMIN-011	K8s 배포: mcc k8s run -f values --k8sprovider (gke/eks/aks/minikube) → Pod Running	정상	⏭️ 공통	IV0_S11
IV0_S12	TC-ADMIN-012	Weave Scope 설치/제거: mcc k8s weave-scope install-weave-scope / uninstall	정상	⏭️ 공통	IV0_S12
IV0_S13	TC-ADMIN-013	Docker-K8s 상호배타 (예외): Compose 스택 실행 중 mcc k8s run → 거부	예외	⏭️ 공통	IV0_S13
IV0_S14	TC-ADMIN-014	HTTP 메서드별 호출: mcc rest get/post/put/patch/delete → 서버에 같은 메서드·본문 전달	정상	❌ 공통	IV0_S14
IV0_S15	TC-ADMIN-015	인증 모드: mcc rest -u/-p(Basic), --authToken(Bearer), --authScheme(사용자 scheme) → Authorization 헤더, mc-infra-manager readyz Basic 호출	정상	✅ 공통	IV0_S15
IV0_S16	TC-ADMIN-016	헤더·바디 설정: -H 여러 개, -d 문자열 본문, -f 파일 본문 → 서버 수신 확인	정상	❌ 공통	IV0_S16
IV0_S17	TC-ADMIN-017	HEAD / verbose: mcc rest get -I(응답 헤더), -v(요청 추적 정보)	정상	✅ 공통	IV0_S17
IV0_S18	TC-ADMIN-018	Docker Compose healthcheck exit code 통합: mcc rest get 종료 코드 = HTTP 상태 첫 자리(200→0, 404→4, 503→5) · healthcheck 연동	정상	✅ 공통	IV0_S18
IV0_S19	TC-ADMIN-019	서비스·액션 카탈로그 조회: mcc api --list, -s mc-infra-manager --list → api.yaml 과 일치	정상	✅ 공통	IV0_S19
IV0_S20	TC-ADMIN-020	서비스별 기본 호출 9종: mcc api -s <서비스> -a <상태 확인 액션> (infra-connector·infra-manager·iam·web-console·observability·application·workflow·cost·data)	정상	❌ 공통	IV0_S20
IV0_S21	TC-ADMIN-021	경로 파라미터·쿼리 문자열 치환: mcc api -a GetNs -p nsId:default, -a GetAllNs -q option=id	정상	✅ 공통	IV0_S21
IV0_S22	TC-ADMIN-022	출력 파일 저장: mcc api -a GetAllNs -o /tmp/iv0-getallns.json → 파일에 응답 JSON	정상	✅ 공통	IV0_S22
IV0_S23	TC-ADMIN-023	api tool: mc-infra-manager Swagger(api/doc.json) → mcc api tool -f → operationId 별 액션 정의 생성	정상	✅ 공통	IV0_S23
IV0_S24	TC-ADMIN-024	CSP Credential 등록: mcc setup credential --csp -u/-p → CredentialCSP 항목 입력 → RSA-OAEP/AES-CBC 암호화 → POST /credential → 등록 완료·connConfig verified	정상	✅ 공통	IV0_S24
IV0_S25	TC-ADMIN-025	암호화 cross-check: test_encryption.py 실행 · 임시 RSA-4096 키 왕복 복호화 · mc-infra-manager 공개키 형식	정상	✅ 공통	IV0_S25
IV0_S26	TC-ADMIN-026	CB-Tumblebug infra-init: mcc setup infra-init → 실행 버전 태그 clone → init.sh → initialized=true	정상	✅ 공통	IV0_S26

상세

IV0_S01

Mode A 개발 설치: installAll.sh(1 Developer / Enter localhost / 2 Background) → mcc infra info 전체 healthy

항목	내용
기능 TC	TC-ADMIN-001
화면	터미널 (bin)
구분	정상 · 공통
사전 조건	docker·docker compose 설치, mc-admin-cli clone, mc- 컨테이너 없음(클린)
자동화	IV0_S01

절차

1.bin 폴더에서 ./installAll.sh 실행 2.모드 1(Developer) 3.도메인 Enter(localhost) 4.실행 방식 2(Background) 5.완료 대기 6../mcc infra info

입력값

모드 1 / 도메인 Enter(localhost) / 실행 방식 2

기대결과

"All environments have been set up!" 종료(코드 0), post-initial 정상, mcc infra info 기대 컨테이너 전체 Up(healthy)

참고

도메인 Enter(localhost)는 plain HTTP(인증서 없음) 경로. 기능명의 자체 서명 인증서 경로는 ADMIN_CLI_DOMAIN=<서버 IP> 로 실행

결과 (v07)

• 공통 ⬜ 미실행 — 클린 서버 필요 — stage 에서 실행 금지

IV0_S02

Mode B 운영 설치: installAll.sh(2 Production / FQDN / 2 Background) → Let's Encrypt 발급 · HTTPS 정상 · 전체 healthy

항목	내용
기능 TC	TC-ADMIN-002
화면	터미널 (bin) + 외부 HTTPS 접속
구분	정상 · 공통
사전 조건	클린 상태, FQDN 의 DNS A 레코드가 서버 공인 IP, 80·443 외부 개방, 80 미사용
자동화	IV0_S02

절차

1.DNS·80 포트 확인 2../installAll.sh 실행 3.모드 2(Production) 4.FQDN 입력 5.실행 방식 2 6.외부에서 https://FQDN, :3001 접속 7../mcc infra info

입력값

모드 2 / 도메인 = 실제 FQDN(ADMIN_CLI_FQDN) / 실행 방식 2

기대결과

"Certificate generation completed", "Production mode configuration completed", 설치 완료 · 공인 인증서 검증 통과(443, 3001) · 전체 healthy

참고

Let's Encrypt 발급 횟수 제한(같은 도메인 주 5회) 주의

결과 (v07)

• 공통 ⬜ 미실행 — 클린 서버·실도메인 필요

IV0_S03

방화벽 포트 점검: 필수 포트 서버 LISTEN + 외부 TCP 접속 (80, 443, 3001, 33002, 7780, 9090, 9000, 3000)

항목	내용
기능 TC	TC-ADMIN-003
화면	터미널 + 외부 PC
구분	정상 · 공통
사전 조건	설치 완료 서버, 외부 접속 주소(ADMIN_CLI_PUBLIC_HOST)
자동화	IV0_S03

절차

1.서버에서 ss -ltn 으로 필수 포트 LISTEN 확인 2.외부 PC 에서 각 포트 TCP 접속

입력값

필수 포트 목록(ADMIN_CLI_PORTS 로 변경 가능)

기대결과

모든 필수 포트가 LISTEN 이고 외부에서 접속됨

참고

README 는 Cost FE 프록시를 7781 로 안내하나 현재 .env.setup 값은 7780 — README 갱신 필요

결과 (v07)

• 공통 🚧 BLOCKED (2026-10-13) — 서버 LISTEN 8/8 정상. 외부 접속은 9000 만 실패 — 테스트 PC 의 사내망이 9000 아웃바운드를 막음(서버 문제 아님). 사내망 밖에서 재확인 필요

IV0_S04

IAM 초기화 결과 확인: post-initial 성공 로그 → IAM 관리자·역할·메뉴·기본 workspace/project → INFRA namespace

항목	내용
기능 TC	TC-ADMIN-004
화면	터미널 (docker logs, IAM·INFRA API)
구분	정상 · 공통
사전 조건	TC-ADMIN-001 설치 완료, MC-INFRA-MANAGER healthy
자동화	IV0_S04

절차

1.docker logs mc-iam-manager-post-initial 2.플랫폼 관리자 로그인 3.역할·메뉴·workspace·project 목록 조회 4.mc-infra-manager GET /ns

입력값

docker logs -f mc-iam-manager-post-initial

기대결과

"[Success] MC-IAM-Manager initialization completed successfully!" · 종료 코드 0 · 역할 admin·메뉴·ws01·default 존재 · namespace default 존재

결과 (v07)

• 공통 ✅ PASS (2026-10-13) — 성공 로그·exit 0, 역할/메뉴/ws01/default 확인, ns default 존재

IV0_S05

환경 전체 정리: cleanAll.sh(y) → docker 이미지·컨테이너·볼륨·container-volume 삭제

항목	내용
기능 TC	TC-ADMIN-005
화면	터미널 (bin)
구분	정상 · 공통
사전 조건	설치된 서버(전용 테스트 서버), sudo 사용 가능
자동화	IV0_S05

절차

1.이미지·컨테이너·볼륨 수 기록 2../cleanAll.sh 실행 3.확인 질문 y 4.남은 자원 확인

입력값

./cleanAll.sh / 확인 y

기대결과

이미지·컨테이너·볼륨 0개, container-volume 폴더 삭제

참고

cleanAll.sh 는 M-CMP 외 서버의 모든 docker 자원도 삭제. 기존 시트 표기 clearAll.sh → cleanAll.sh

결과 (v07)

• 공통 ⬜ 미실행 — 서버 상태를 바꾸는 TC — 전용 테스트 서버에서 ADMIN_CLI_ALLOW_DESTRUCTIVE=1 로 실행

IV0_S06

풀스택 이미지 풀 및 기동: mcc infra pull → run -d → 전체 healthy

항목	내용
기능 TC	TC-ADMIN-006
화면	터미널 (bin)
구분	정상 · 공통
사전 조건	installAll.sh 설정 단계 완료(.env, nginx.conf)
자동화	IV0_S06

절차

1../mcc infra pull 2../mcc infra run -d 3../mcc infra info 로 healthy 대기(최대 20분)

입력값

기대결과

pull 오류 없음, run -d 종료 코드 0, 기대 컨테이너 전체 healthy

결과 (v07)

• 공통 ⬜ 미실행 — 서버 상태를 바꾸는 TC — 전용 테스트 서버에서 ADMIN_CLI_ALLOW_DESTRUCTIVE=1 로 실행

IV0_S07

단일 서비스 타겟 기동: mcc infra stop/run -d -s mc-data-manager → 대상만 재기동, 다른 서비스 영향 없음

항목	내용
기능 TC	TC-ADMIN-007
화면	터미널 (bin)
구분	정상 · 공통
사전 조건	전체 스택 healthy
자동화	IV0_S07

절차

1../mcc infra stop -s mc-data-manager 2.대상만 exited 확인 3../mcc infra run -d -s mc-data-manager 4.대상 healthy · 비교 서비스 StartedAt 불변

입력값

대상 ADMIN_CLI_TARGET_SERVICE(기본 mc-data-manager)

기대결과

대상만 중지·기동, mc-web-console-api 등 다른 서비스는 재시작되지 않음

결과 (v07)

• 공통 ⬜ 미실행 — 서버 상태를 바꾸는 TC — 전용 테스트 서버에서 ADMIN_CLI_ALLOW_DESTRUCTIVE=1 로 실행

IV0_S08

중지 → 재기동 → 이미지 업데이트: mcc infra stop → run -d → update (-s 대상)

항목	내용
기능 TC	TC-ADMIN-008
화면	터미널 (bin)
구분	정상 · 공통
사전 조건	전체 스택 healthy
자동화	IV0_S08

절차

1../mcc infra stop -s <대상> 2../mcc infra run -d -s <대상> 3../mcc infra update -s <대상> 4.healthy 확인

입력값

대상 ADMIN_CLI_TARGET_SERVICE(기본 mc-data-manager, all=전체)

기대결과

각 단계 후 상태 정상, update 가 최신 이미지 pull 후 재기동하고 명령이 종료됨

참고

v07 bin/mcc 의 update 는 -d 플래그가 없어 docker compose up 이 포그라운드로 붙어 끝나지 않음(MZC-CSC/mc-admin-cli#100 에서 항상 up -d 로 수정). 판정은 update 명령이 스스로 exit 0 으로 끝나야 PASS — 15분 timeout(124)·강제 종료 모두 FAIL. 대상의 의존 서비스(depends_on)도 compose 버전이 바뀌어 있으면 2단계 run -d 에서 함께 재생성됨

결과 (v07)

• 공통 ❌ FAIL (2026-10-14) — stage, v07 bin/mcc(main 8c0786c), 대상 mc-data-manager: stop·run -d 는 PASS, update 는 pull 후 'Attaching to mc-data-manager' 로 10분 이상 미종료(강제 종료). 원인 src/cmd/docker/update.go 가 run 전용 detachFlag 를 참조 — -d 미등록
• 공통 ✅ PASS (2026-10-14, 수정 검증) — MZC-CSC/mc-admin-cli#100 브랜치 bin/mcc: mc-data-manager(update exit 0, 6초), mc-application-manager 0.7.1→0.7.2(update exit 0, 8초)

IV0_S09

스택 정리: mcc infra remove -v -i → mcc 프로젝트 컨테이너·볼륨·compose 이미지 삭제

항목	내용
기능 TC	TC-ADMIN-009
화면	터미널 (bin)
구분	정상 · 공통
사전 조건	스택 설치됨(전용 테스트 서버)
자동화	IV0_S09

절차

1.컨테이너·이미지 수 기록 2../mcc infra remove -v -i 3.남은 컨테이너·볼륨·이미지 확인

입력값

-v(볼륨) -i(이미지)

기대결과

mcc 프로젝트 컨테이너 0, 볼륨 0, compose 이미지 없음

결과 (v07)

• 공통 ⬜ 미실행 — 서버 상태를 바꾸는 TC — 전용 테스트 서버에서 ADMIN_CLI_ALLOW_DESTRUCTIVE=1 로 실행

IV0_S10

Compose Variant 전환: mini(-f docker-compose.mini.yaml) 기동·healthy·정리 / cert(-f docker-compose.cert.yaml) 인증서 발급

항목	내용
기능 TC	TC-ADMIN-010
화면	터미널 (bin)
구분	정상 · 공통
사전 조건	기본 스택 없음(컨테이너 이름 중복), cert 는 FQDN·80 비어 있음
자동화	IV0_S10

절차

1../mcc infra run -d -f ../conf/docker/docker-compose.mini.yaml 2.mini 서비스 healthy·그 외 없음 3../mcc infra remove -v -f mini 4.(FQDN) ./mcc infra run -f ../conf/docker/docker-compose.cert.yaml

입력값

mini / cert 파일, ADMIN_CLI_FQDN

기대결과

mini: 정의된 서비스만 healthy 후 정리 / cert: mcmp-certbot exit 0, fullchain.pem 생성

참고

참고: 로컬 develop(이전 커밋)의 mini 는 csescsta/mc-web-console-*:edge 이미지가 pull 거부(저장소 없음) — origin/develop 에서 cloudbaristaorg 0.6.7 로 이미 수정됨

결과 (v07)

• 공통 ✅ PASS (2026-10-13) — 로컬(WSL, mc-admin-cli origin/develop 7f6f1cc)에서 실행: mini 기동 65초 → 12개 healthy → remove -v 로 정리. cert 단계는 실도메인이 없어 건너뜀

IV0_S11

K8s 배포: mcc k8s run -f values --k8sprovider (gke/eks/aks/minikube) → Pod Running

항목	내용
기능 TC	TC-ADMIN-011
화면	터미널 (bin) + kubectl
구분	정상 · 공통
사전 조건	kubectl 컨텍스트, helm, ../helm-chart
자동화	IV0_S11

절차

1.kubectl·helm·values 확인 2../mcc k8s run 3.Pod Running 대기 4../mcc k8s stop

입력값

ADMIN_CLI_K8S_PROVIDER, ADMIN_CLI_K8S_VALUES

기대결과

mcmp 네임스페이스 Pod 전부 Running/Completed

참고

현 버전 미지원 기능 — 기능목록 제외 또는 SKIP 유지 결정 필요

결과 (v07)

• 공통 ⏭️ SKIP (2026-10-13) — mcc k8s 미지원 — 현 바이너리에 k8s 명령 없음(root.go AddCommand 주석, README "K8S is not currently supported"), helm-chart 폴더도 없음

IV0_S12

Weave Scope 설치/제거: mcc k8s weave-scope install-weave-scope / uninstall

항목	내용
기능 TC	TC-ADMIN-012
화면	터미널 (bin) + kubectl
구분	정상 · 공통
사전 조건	K8s 클러스터 접속
자동화	IV0_S12

절차

1.install-weave-scope 2.weave 네임스페이스 Pod Running 3.uninstall 4.weave 네임스페이스 삭제

입력값

ADMIN_CLI_K8S_PROVIDER

기대결과

설치 후 Running, 제거 후 자원 없음

참고

설치 매니페스트 URL(cloud.weave.works)은 Weaveworks 서비스 종료로 접속 불가 가능 — 기능목록 제외 검토

결과 (v07)

• 공통 ⏭️ SKIP (2026-10-13) — mcc k8s 미지원(현 버전 비활성)

IV0_S13

Docker-K8s 상호배타 (예외): Compose 스택 실행 중 mcc k8s run → 거부

항목	내용
기능 TC	TC-ADMIN-013
화면	터미널 (bin)
구분	예외 · 공통
사전 조건	Compose 스택 실행 중
자동화	IV0_S13

절차

1.Compose 실행 중 확인 2../mcc k8s run 실행

입력값

--k8sprovider

기대결과

거부 메시지 출력, helm install 미실행

참고

기능목록 제외 검토

결과 (v07)

• 공통 ⏭️ SKIP (2026-10-13) — mcc k8s 미지원(현 버전 비활성). 소스(k8s/run.go)에도 상호배타 검사 로직 없음

IV0_S14

HTTP 메서드별 호출: mcc rest get/post/put/patch/delete → 서버에 같은 메서드·본문 전달

항목	내용
기능 TC	TC-ADMIN-014
화면	터미널 (bin) + 임시 echo 서버
구분	정상 · 공통
사전 조건	대상 서버 python3 (임시 echo 서버 127.0.0.1:18999)
자동화	IV0_S14

절차

1.echo 서버 기동 2../mcc rest <메서드> URL [-d JSON] 5종 실행 3.서버가 받은 메서드·본문 비교

입력값

-d '{"k":"v"}' (post/put/patch)

기대결과

5종 모두 같은 메서드로 도착, 본문 일치, 종료 코드 0

참고

제품 결함 후보: mcc rest post 가 GET 요청을 보냄

결과 (v07)

• 공통 ❌ FAIL (2026-10-13) — GET·PUT·PATCH·DELETE 정상, POST 만 GET 으로 전송됨(본문 없음) — src/cmd/rest/post.go 가 req.Post 대신 req.Get 호출

IV0_S15

인증 모드: mcc rest -u/-p(Basic), --authToken(Bearer), --authScheme(사용자 scheme) → Authorization 헤더, mc-infra-manager readyz Basic 호출

항목	내용
기능 TC	TC-ADMIN-015
화면	터미널 (bin) + 임시 echo 서버
구분	정상 · 공통
사전 조건	mc-infra-manager 실행 중, ADMIN_CLI_TB_AUTH
자동화	IV0_S15

절차

1.-u/-p 로 호출 2.--authToken 3.--authScheme OAuth --authToken 4.실제 /tumblebug/readyz Basic 호출

입력값

-u iv0user -p iv0pass / --authToken iv0token / --authScheme OAuth

기대결과

Basic base64(user:pass) · Bearer iv0token · OAuth iv0token 전달, readyz ready:true

결과 (v07)

• 공통 ✅ PASS (2026-10-13) — 3가지 인증 헤더 모두 정확, readyz ready:true

IV0_S16

헤더·바디 설정: -H 여러 개, -d 문자열 본문, -f 파일 본문 → 서버 수신 확인

항목	내용
기능 TC	TC-ADMIN-016
화면	터미널 (bin) + 임시 echo 서버
구분	정상 · 공통
사전 조건	대상 서버 python3
자동화	IV0_S16

절차

1.-H Content-Type, -H X-Iv0 로 호출 2.put -d JSON 3.put -f 파일

입력값

-H "Content-Type:application/json" -H "X-Iv0:hello" / -d '{"RegionName":"iv0"}' / -f /tmp/iv0-body.json

기대결과

두 헤더 수신, -d 본문 일치, -f 파일 내용 일치

참고

제품 결함 후보: mcc rest -f(파일 본문)가 동작하지 않음

결과 (v07)

• 공통 ❌ FAIL (2026-10-13) — -H 2개·-d 본문 정상. -f 파일 본문이 비어서 전송됨 — rest/root.go 가 -f 값을 fileData 에 받지만 SetReqData 는 inputFileData 를 읽음

IV0_S17

HEAD / verbose: mcc rest get -I(응답 헤더), -v(요청 추적 정보)

항목	내용
기능 TC	TC-ADMIN-017
화면	터미널 (bin) + 임시 echo 서버
구분	정상 · 공통
사전 조건	대상 서버 python3
자동화	IV0_S17

절차

1../mcc rest get -I URL 2../mcc rest get -v URL

입력값

-I / -v

기대결과

-I: 응답 헤더(X-Echo, Content-Type) 출력 / -v: Request Trace Info·TotalTime·Status Code 200

참고

개선 메모: -I 설명은 "headers only" 인데 본문도 출력, -v 는 "request data : %!s(MISSING)" 출력 형식 오류와 Basic 비밀번호를 평문 출력

결과 (v07)

• 공통 ✅ PASS (2026-10-13) — 헤더·추적 정보 정상 출력

IV0_S18

Docker Compose healthcheck exit code 통합: mcc rest get 종료 코드 = HTTP 상태 첫 자리(200→0, 404→4, 503→5) · healthcheck 연동

항목	내용
기능 TC	TC-ADMIN-018
화면	터미널 (bin) + 임시 echo 서버
구분	정상 · 공통
사전 조건	스택 실행 중
자동화	IV0_S18

절차

1.상태 200/404/503 응답 URL 호출 후 종료 코드 확인 2.mc-infra-manager healthcheck 정의·상태 확인

입력값

?status=200/404/503

기대결과

종료 코드 0/4/5, healthcheck 가 /app/tool/mcc rest get 사용하고 healthy

참고

참고: post/put/patch/delete 는 상태 코드와 무관하게 종료 코드 0(GET 만 반영)

결과 (v07)

• 공통 ✅ PASS (2026-10-13) — 종료 코드 0/4/5, mc-infra-manager healthcheck healthy

IV0_S19

서비스·액션 카탈로그 조회: mcc api --list, -s mc-infra-manager --list → api.yaml 과 일치

항목	내용
기능 TC	TC-ADMIN-019
화면	터미널 (bin)
구분	정상 · 공통
사전 조건	bin/../conf/api.yaml
자동화	IV0_S19

절차

1../mcc api --list 2../mcc api -s mc-infra-manager --list 3.없는 서비스 지정

입력값

기대결과

api.yaml 서비스·액션 전체 출력, 없는 서비스는 지원 목록에 없다는 안내

참고

개선 메모: 액션 이름이 소문자로 출력됨(getreadyz) — api.yaml 의 이름과 다름

결과 (v07)

• 공통 ✅ PASS (2026-10-13) — 서비스·액션 목록 일치, 오류 안내 정상

IV0_S20

서비스별 기본 호출 9종: mcc api -s <서비스> -a <상태 확인 액션> (infra-connector·infra-manager·iam·web-console·observability·application·workflow·cost·data)

항목	내용
기능 TC	TC-ADMIN-020
화면	터미널 (bin)
구분	정상 · 공통
사전 조건	스택 실행 중, api.yaml(호스트명을 localhost 로 바꾼 사본)
자동화	IV0_S20

절차

1.api.yaml 사본 생성 2.9개 서비스 상태 확인 액션 호출 3.응답 확인

입력값

서비스·액션 9쌍

기대결과

9개 서비스 모두 정상 응답

참고

제품 결함 후보: api.yaml GetDataMgrReadyz 경로 불일치. 환경 제약: api.yaml 기본 baseurl 이 docker 내부 호스트명

결과 (v07)

• 공통 ❌ FAIL (2026-10-13) — 7/9 성공. mc-data-manager: api.yaml 경로 /readyz → Not Found(서비스 실제 경로 /readyZ). mc-observability: 18080 이 호스트에 공개되지 않아 connection refused

IV0_S21

경로 파라미터·쿼리 문자열 치환: mcc api -a GetNs -p nsId:default, -a GetAllNs -q option=id

항목	내용
기능 TC	TC-ADMIN-021
화면	터미널 (bin)
구분	정상 · 공통
사전 조건	mc-infra-manager 실행 중
자동화	IV0_S21

절차

1.-a GetNs -p nsId:default 2.-p 없이 호출 3.-a GetAllNs -q option=id 4.-q "?option=id"

입력값

-p nsId:default / -q option=id / --authUser·--authPassword

기대결과

namespace default 반환, -p 누락 시 안내, output id 목록 반환

참고

참고: api.yaml 의 mc-infra-manager 인증값(spider)이 실제(default)와 달라 인증 인자로 덮어써야 함

결과 (v07)

• 공통 ✅ PASS (2026-10-13) — 4단계 모두 정상

IV0_S22

출력 파일 저장: mcc api -a GetAllNs -o /tmp/iv0-getallns.json → 파일에 응답 JSON

항목	내용
기능 TC	TC-ADMIN-022
화면	터미널 (bin)
구분	정상 · 공통
사전 조건	mc-infra-manager 실행 중
자동화	IV0_S22

절차

1../mcc api -s mc-infra-manager -a GetAllNs -o 파일 2.파일 내용 확인

입력값

-o /tmp/iv0-getallns.json

기대결과

파일 생성, ns 목록 JSON

결과 (v07)

• 공통 ✅ PASS (2026-10-13) — 파일에 ns 목록 저장

IV0_S23

api tool: mc-infra-manager Swagger(api/doc.json) → mcc api tool -f → operationId 별 액션 정의 생성

항목	내용
기능 TC	TC-ADMIN-023
화면	터미널 (bin)
구분	정상 · 공통
사전 조건	mc-infra-manager 실행 중
자동화	IV0_S23

절차

1.Swagger JSON 내려받기 2../mcc api tool -f 파일 3.operationId 수와 액션 수 비교 4.현재 api.yaml 과 차이 기록

입력값

-f /tmp/iv0-tb-swagger.json

기대결과

모든 operationId 에 대해 method·resourcePath 를 가진 액션 생성

참고

참고: 현재 Swagger 에 basePath 가 없어 "Base Path:" 가 빈 값

결과 (v07)

• 공통 ✅ PASS (2026-10-13) — operationId 340개 = 생성 액션 340개

IV0_S24

CSP Credential 등록: mcc setup credential --csp -u/-p → CredentialCSP 항목 입력 → RSA-OAEP/AES-CBC 암호화 → POST /credential → 등록 완료·connConfig verified

항목	내용
기능 TC	TC-ADMIN-024
화면	터미널 (bin, TTY)
구분	정상 · 공통
사전 조건	mc-infra-manager healthy, credential key=value 파일(ADMIN_CLI_CRED_FILE, 키는 CredentialCSP 형식)
자동화	IV0_S24

절차

1.metainfo 의 CredentialCSP 로 필요 항목 조회 2../mcc setup credential --csp aws -u -p 3.항목 입력 4.검토 no 5.확인 yes 6.등록 완료 메시지·connConfig 확인

입력값

ADMIN_CLI_CSP=aws, ADMIN_CLI_CRED_FILE(aws_access_key_id / aws_secret_access_key)

기대결과

"CSP Credential registration completed successfully", 서버 거부 없음, 해당 CSP connConfig verified

참고

참고: 저장소 bin/mcc 는 7월 빌드 그대로라 수정이 들어 있지 않음(소스 빌드 필요). api.yaml 의 mc-infra-manager 인증값(spider)이 설치 기본값(default)과 달라 -u/-p 지정 필요

결과 (v07)

• 공통 ✅ PASS (2026-10-13) — stage 에서 수정 빌드(mc-admin-cli origin/develop 604d5dc, PR #97 e85bd88)로 재실행 → 등록 완료, aws 연결 18개 verified 유지(같은 값으로 덮어씀). 수정 전(7f6f1cc·edge)은 키 이름 불일치(ClientId/ClientSecret)로 서버 거부 — FAIL

IV0_S25

암호화 cross-check: test_encryption.py 실행 · 임시 RSA-4096 키 왕복 복호화 · mc-infra-manager 공개키 형식

항목	내용
기능 TC	TC-ADMIN-025
화면	터미널 (bin)
구분	정상 · 공통
사전 조건	python3 + pycryptodome(없으면 uv 임시 환경)
자동화	IV0_S25

절차

1.pycryptodome 확인 2.python3 test_encryption.py 3.임시 키쌍 암호화→복호화 4.GET /credential/publicKey 로 암호화

입력값

기대결과

4개 값 암호화 완료, 왕복 결과 원문과 같음(AES-256), 암호화 키 512바이트·AES 블록 형식

결과 (v07)

• 공통 ✅ PASS (2026-10-13) — 3단계 모두 정상(uv 임시 환경 사용)

IV0_S26

CB-Tumblebug infra-init: mcc setup infra-init → 실행 버전 태그 clone → init.sh → initialized=true

항목	내용
기능 TC	TC-ADMIN-026
화면	터미널 (bin, TTY)
구분	정상 · 공통
사전 조건	mc-infra-manager healthy, ~/.cloud-barista/credentials.yaml.enc, uv
자동화	IV0_S26

절차

1.credential 암호화 파일 확인 2../mcc setup infra-init 3.y / 1(새로 받기) / y 4.cb-tumblebug 태그 확인 5.readyz initialized·connConfig

입력값

ADMIN_CLI_INIT_INPUT(기본 y / 1 / y)

기대결과

실행·healthy·버전 확인, 같은 태그 checkout, init.sh 실행, initialized=true, connConfig 등록

참고

참고: 이미지 태그가 x.y.z 가 아니면(edge 등) 버전 감지 실패. 같은 경로에 cb-tumblebug 폴더가 있으면 메뉴 1 이 폴더를 삭제함

결과 (v07)

• 공통 ✅ PASS (2026-10-13) — 로컬에서 실행(234초): 버전 0.13.5 감지 → v0.13.5 clone → init.sh(a+ 백업 복원) → initialized=true, 연결 85개 verified. 기존 ~/go/... 저장소 보호를 위해 임시 HOME 에서 실행