[f1v3-dev]

🔗 Related Issue

• https://github.com/jam2in/arcus-works/issues/863#issuecomment-5596924093

⌨️ What I did

• zk delete의 디렉터리 존재 검사를 제거하여, 원격 디렉터리가 이미 삭제된 경우에도 정리할 수 있도록 변경합니다.
• SSH로 원격 호스트에서 ruok를 실행하여 삭제 전 연결 상태를 확인하도록 변경합니다.
  • 연결 거부가 확인된 경우에만 검사를 통과시키고, 연결 성공이나 그 외 오류는 삭제를 거부합니다.
• 원격 삭제 경로에 Shell Quote를 적용하여, 공백으로 경로가 분리되거나 특수문자가 Shell 문법으로 해석되는 것을 방지했습니다.
• zk delete의 오류를 RunE로 반환하도록 변경하고, CLI 오류가 중복 출력되지 않도록 정리했습니다.

[claude]

리뷰 완료 — Blocker 0건, Major 0건, Minor 3건, Question 0건

[claude]

리뷰 완료 — Blocker 0건, Major 0건, Minor 2건, Question 0건

[f1v3-dev]

@namsic @oliviarla

삭제 전 상태 확인 방식을 mntr + pgrep에서 SSH를 통한 ruok 검사로 변경했습니다.
연결 거부가 확인된 경우에만 삭제를 진행하고, 연결 성공이나 그 외 오류는 삭제를 거부합니다.

운영 장비에서 원격 장비에 SSH로 접속이 거부되는 상태는 없다고 가정을 했습니다.

[claude]

리뷰 완료 — Blocker 0건, Major 0건, Minor 0건, Question 1건

[Question]
verifyAllStopped(internal/zk/delete.go)는 서버가 정지되었다고 판단하는 조건을 nc -v 실행이 exit code 1을 반환하고 출력에 "Connection refused"가 포함된 경우로 한정합니다. 원격 장비에 설치된 nc 구현체(BusyBox nc, ncat 등)에 따라 종료 코드나 메시지 문구가 이와 다를 수 있습니다. 그 경우 실제로는 정지된 서버도 "확인 불가" 오류로 처리되어 삭제가 차단되므로 데이터 손상으로 이어지지는 않지만(안전한 방향으로 실패), 배포 대상 환경들의 nc 구현체가 이 문구/종료 코드 조합을 보장하는지 확인해 주세요.

[oliviarla]

zookeeper_server.pid 파일 기반으로 체크하는 방식도 혹시 고려해보셨나요?

[f1v3-dev]

zookeeper_server.pid 파일 기반으로 체크하는 방식도 혹시 고려해보셨나요?

생각을 해봤었는데, zkServer.sh stop으로 종료하게 될 경우 PID 파일을 삭제하지만, kill로 종료하게 될 경우 파일이 남아있어 파일 존재 여부만으로는 실행 상태를 판단하기 어렵다고 생각했으며, PID의 실제 프로세스 존재 여부와 해당 ZooKeeper 노드인지까지 검증이 필요합니다.