OpenStack 2번째 커맨드 개발하기

Ryan Kim
7 min readNov 6, 2021

--

3주에서 2시간으로 단축되어 개발할 수 있었던 나의 2번째 OpenStack CLI 커맨드 개발 후기

지난 오픈소스 컨트리뷰션에서 활동 이후, 우리 팀은 4등을 수상했다.

이후 활동의 일환으로 함께 참여를 했던 멘토님이 내게 20 ~ 21일 지역 스프린트 활동으로 대구 경북대에서 중, 고등학생들을 대상으로한 오픈스택 교육을 하러 함께 “멘토”로 가자는 제의(?)를 해주셨고, 스스로 오픈스택에 대해 경험이 더 필요하다고 생각했던 나는 이제껏 우리팀이 개발했던 내용들을 쭉 훑어보게 되었다.

장관상 아니고 장려상…?

그 동안 통합 커맨드를 개발해왔던 일에 전념했고, 나는 Glance 컴포넌트 CLI 통합 작업으로 기여했고, 이번에는 glance 말고 다른 컴포넌트 CLI는 어떨까 싶어서 Nova 컴포넌트의 커맨드 mapping table을 보게 되었다.

노바의 하이퍼바이저 관련 커맨드 표

이미 우리 팀원이 구현해 놨던 hypervisor-servers라는 명령어는 패치가 올라가 있으니, 가볍게 hypervisor-uptime이라는 커맨드를 보게 되었고, 하이퍼 바이저의 총 구동시간을 보여주는 커맨드이기도 하고, 옵션으로 주는 command parsing 값도 적기에 21년 11월 6일 자정에 개발을 시작하게 되었다.

무엇보다 공식문서 설명도 단순했고, 하이퍼 바이저의 ID 또는 name을 받으면 총 구동 시간을 보여주기 때문에 별다른 옵션 추가가 필요하지 않아서 새벽에 빨리 개발하고 자야겠다(?)고 다짐하게 되었다.

아니, 근데 glance task-list 코드 구현할 땐 3주나 걸렸는데 이걸 오늘 하루만에(??) 구현할 수 있을까 싶었는데, 무슨 근거없는 자신감인지 20 ~ 21일에 학생들 지도하러 가려면 최소한 커맨드 5개는 개발해 놓고 가서 “멘토질”을 할 수 있을 것이라 생각했고, 그렇게 뜬금없이 커맨드 개발을 시작했다.

1. 구현해야하는 코드를 nova 컴포넌트로 우선적으로 구현 시작하기

우선 어떤 값들을 API로 받아와서 구현하는지를 명확하게 알고 있어야하니까, 카페 24 가상 머신에 올려놓은 오픈스택에서 노바 컴포넌트 커맨드 (nova hypervisor-uptime <하이퍼바이저 이름 또는 아이디>)를 사용했다.

nova hypervisor-uptime

필드 값들을 보면,

  • hypervisor_hostname
  • id
  • status
  • state
  • uptime

이렇게 5개의 값을 표기하고 있고, 노바에서는 id값이 영문 소문자 + 숫자로 랜덤하게 생성되는데 오픈스택에서는 생성되는 순서에 따라 오름차순 정수형으로 표기된다. (hypervisor-show 커맨드에서도 동일하게 작동한다)

2. 기능 & 테스트 코드 구현하기

내가 구현한 openstack hypervisor uptime 커맨드

물론 maintainer의 답변을 확인해야할 것이고, openstack hypervisor에서 랜덤하게 생성된 ID를 parser 값으로 넣어주면 동작하지 않는다.

위의 코드는 이미 CLI에 구현되어 있는 openstack hypervisor show 커맨드와 nova hypervisor-show 커맨드를 통해 교차 검증을 진행했고, 이 2개의 커맨드에서도 아이디를 표기하는 방법 및 테이블의 제목 칼럼의 Field / Property 항목의 표기가 다르게 되어 있다는 것을 모두 확인하고 작업했다.

openstack hypervisor show
VCPU 정보가 빠져있는 기존의 노바 컴포넌트의 hypervisor-show
커맨드 코드 구현 끝…;

다른 커맨드의 교차 검증을 진행 후, 이번 코드 구현을 더 쉽게 했던 것은 무엇보다 uptime 관련 정보가 하이퍼 바이저에 uptime이라는 메소드로 존재하고 있었고, 인자값으로 하이퍼바이저의 아이디 값을 전달하니 원하는 정보가 한 번에 나왔다.

(위에서 언급했던 5개의 필드 값들)

커맨드를 setup.cfg에 등록한 것은 말할 것도 없고, 커맨드가 정상적으로 작동하는 것을 만들어 봤으니, 테스트 코드를 바로 구현하러 넘어갔다.

참고로 glance task-list 때는 관련 커맨드 구현된 게 없어서 sdk 컴포넌트로 넘어가서 task.py라는 파일에서 api 정보를 받아와 코드를 구현했었다.

그러나 하이퍼 바이저 관련 커맨드는 이미 2개나 구현되어 있었고, 참조할 코드가 있었기 때문에 SDK까지 볼 필요가 없이 이미 구현된 코드들만으로 uptime 커맨드 구현이 충분히 가능했다.

테스트 코드를 이렇게 빨리 작업했다고…?

여기까지 구현하고 나서 tox 테스트 환경을 실행해보니, pep8 에러 제외하고 기능적으로 문제가 있던 부분은 하나도 없었다.

바로 커밋을 진행했고, 커밋 시각이 새벽 2시 13분이었다.

한숨 자고, 6일 아침에 일어나서 상황을 확인해보니 테스트 코드에 에러 하나 없이 깔끔하게 커밋이 올라간 것을 확인할 수 있었다.

ZUUL CI만 2시간씩 도는데 이거 더 빠르게 못하나..;

이쯤 되니, 이제 CLI 관련해서 작업하는 것에 대해서는 나름대로 노련함이 생겼다고 하지 않을 수 없다.

(코드는 여기서 확인이 가능하다)

3. 후기

커맨드 개발이 엄청 대단한 것은 아니지만, 처음에 구현할 때를 생각해보면 SDK 레포부터 시작해서 찾아봐야만했던 코드가 진짜 많았다.

일단 CLI 레포의 구조 자체를 잘 모르기 때문에 이걸 구현하는 게 쉽지 않을 것 같다는 생각을 했었고, image.py 관련 코드만 최소 1000줄이 넘어갔기 때문에 코드에 압도되었던 것이 있었기 때문이다.

그렇게 3주라는 시간 동안 삽질을 꽤 많이 하니, 레포 구조와 코드 구현 등에 대한 것들이 눈에 보이기 시작했고, hypervisor uptime 커맨드 구현에서는 큰 삽집 없이 구현으로 이어졌다.

전체 작업시간이 약 2시간 밖에 안되었기 때문에 되려 단시간에 기능을 구현하면서 집중력도 올라가고, 새로운 기능 개발하는 것에 거부감이 줄어들었다.

멘토님이나 멘티들에게 아직 얘기하지 않았지만, 이건 스스로 오픈스택에 대해 얼마나 배웠는지 검증하는 과정이라 생각한다.

만약, 함께 프로젝트를 수행했던 사람들이 없으면 나는 어디까지 구현할 수 있는가? 이번에 배운 지식은 그냥 2달 구현하고 끝? 이런 느낌이 아니고, 혼자서도 충분히 개발할 수 있다는 부분들을 검증하고 싶었다.

앞으로 11월 중에 3번 더 커맨드를 개발해 보려고 하는데, 하나의 기능을 개발할 때마다 포스트를 올려서 기록해야겠다.

--

--

Ryan Kim
Ryan Kim

No responses yet