v0.9.265
승인 화면이 실행될 값과 다른 값을 보여줬습니다
internal/action/impact.go 는 클러스터를 바꾸는 모든 액션이 승인 전에 통과하는 유일한 영향도 산출기입니다. 그 결과가 DryRunDiff 로 저장되고, 운영자는 그 텍스트만 보고 승인 버튼을 누릅니다. 272줄에 테스트는 4개뿐이었고, 실제로 들어올 수 있는 요청과 대조해 보니 결함 네 가지가 나왔습니다.
① preview 와 실행기가 같은 replicas 를 다르게 읽었습니다
영향도 쪽 num() 은 float/int 만 처리하는데, 실행기 쪽 intFromParams 는 JSON 문자열도 Atoi 로 파싱합니다. 그래서 {"replicas":"5"} 요청은 승인 기록과 감사 로그에 replicas 2 → 0 (-2) 로 남고 실제로는 5로 스케일됐습니다 — 승인한 값과 실행된 값이 다릅니다. 이제 영향도가 실행기와 같은 방식으로 읽습니다.
② replicas 가 없거나 음수여도 "0으로 축소" 로 렌더됐습니다
실행기는 이런 요청을 replicas 파라미터가 필요합니다 로 거절합니다. 그런데 승인 기록에는 실행될 수 없는 전면 중단 diff 가 남았습니다. 이제 값을 읽을 수 없으면 그렇다고 말하고 승인 사유를 답니다.
③ replica 0 축소에 승인 게이트가 없었습니다
scale 은 Classify 가 유일하게 RequiresApproval:false 로 두는 액션입니다(workload-scoped reversible action). 하지만 replica 0 은 워크로드 전면 중단입니다. 서비스 플랫폼의 stop 경로는 같은 요청을 이미 approval_required 로 기록하고 있었고, Action Center API(POST /admin/k8s/actions)만 pending 으로 통과시키고 있었습니다. 이제 승인 대상입니다.
④ uncordon 이 cordon 의 설명문을 그대로 썼습니다
두 액션이 한 case 를 공유해서, 스케줄을 다시 여는 uncordon 을 승인하는 운영자가 "현재 N개 Pod 영향. cordon은 신규 스케줄만 차단합니다" 를 읽었습니다 — 반대 동작에 대한 설명입니다.
덧붙여 patch 의 미허용 필드 목록이 map 순회 순서라 같은 요청이 매번 다른 승인 문구를 만들던 것도 정렬했습니다.
초록불을 믿지 않았습니다
신규 테스트 5개를 고치기 전 코드에 되돌려 붙여 확인했습니다 — 다섯 개가 위 결함을 각각 정확히 지목하며 실패했습니다.
검증: go build ./... · go vet ./... · go test ./... 전부 통과(20 패키지).
- 이미지:
clustara:v0.9.265 - 배포 압축본:
clustara-v0.9.265.tar.gz