[OpenStack에 contribute하기 - 6] 실전 (2)

본 포스트에서는 OpenStack을 로컬 환경에 설치하고, 변경 사항을 제출하는 방법에 대해서 설명하고자 합니다.

---

 

DevStack

---

DevStack이란?

DevStack은 git의 master 브랜치의 최신 버전을 기반으로 완전한 OpenStack 환경을 신속하게 띄우는 데 사용되는 확장 가능한 스크립트 모음입니다. DevStack은 개발 환경과 많은 OpenStack 프로젝트의 기능 테스트의 기초로서 상호적으로 사용됩니다. 즉, OpenStack을 쉽게 설치할 수 있도록 도와주는 스크립트라고 생각하시면 됩니다.

 

DevStack 설치하기

주의! DevStack은 설치 중에 시스템의 많은 부분을 변경합니다. 오로지 이 목적으로만 사용되는 서버나 가상 머신에서만 DevStack을 실행하세요.

Stack User 추가하기 (Optional)

DevStack은 sudo권한이 부여된 비-루트 사용자로 실행되어야 합니다. ("ubuntu" 또는 "cloud-user"와 같은 클라우드 이미지에 대한 표준 로그인은 괜찮습니다.)

만약 클라우드 이미지를 사용하지 않는다면, DevStack을 실행하기 위해 다음과 같은 별도의 stack 유저를 생성할 수 있습니다.

$ sudo useradd -s /bin/bash -d /opt/stack -m stack

이 사용자가 시스템의 상당 부분을 변경할 것이므로, sudo 권한이 필요합니다.

$ echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/stack
$ sudo su - stack

 

DevStack 다운로드하기

$ git clone https://opendev.org/openstack/devstack
$ cd devstack

DevStack 레포지토리에는 OpenStack을 설치하는 스크립트와 구성 파일을 위한 템플릿이 포함되어 있습니다.

 

local.conf 생성하기

DevStack git 레포지토리의 최상위 경로에 4개의 암호가 있는 local.conf 파일을 생성하세요.

[[local|localrc]]
ADMIN_PASSWORD=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD

이는 DevStack을 시작하는데 필요한 최소 설정입니다.

DevStack 레포지토리 내의 samples/ 폴더 안에 local.conf를 위한 예제 파일이 있습니다.

 

설치 시작하기

$ ./stack.sh

인터넷 연결 속도에 따라 15~20분이 소요됩니다. 이 과정에서 많은 git tree와 패키지가 설치됩니다.

DevStack을 설치하면서 /opt/stack/ 경로에 keystone, glance, nova, placement, cinder, neutron 그리고 horizon이 설치됩니다. 다른 프로젝트에 대해서 작업하고자 한다면, Github에서 해당 프로젝트 레포지토리를 복제하시거나 다른 방법으로 설치해야 합니다.

 

 

변경사항 만들기

---

다음으로 진행하기 전에, 작업하고자 하는 프로젝트의 레포지토리 내에서 이 과정을 마치고 진행하세요. OpenStack의 경로는 /opt/stack/ 입니다.

 

변경사항을 작업할 프로젝트로 이동하기

OpenStack은 여러 서브 프로젝트들을 포함하고 있기 때문에, 본인이 작업하고자 하는 프로젝트로 이동해야 합니다. 저는 neutron 프로젝트에서 작업을 할 것이기 때문에, neutron 프로젝트로 이동하겠습니다.

$ cd /opt/stack/neutron

 

최신 변경사항으로 업데이트하기

로컬 레포지토리가 위와 같이 설정되면, 반드시 다음의 workflow를 사용해야 합니다. 최신 버전의 upstream 변경사항이 반영되어 있는지 확인하세요. 아래의 명령어를 실행하여 최신 버전으로 업데이트하세요.

$ git remote update
$ git checkout master
$ git pull --ff-only origin master

 

브랜치 생성하기

변경사항을 생성하기 전에, 브랜치를 생성해야 합니다. 작업을 저장할 토픽 브랜치를 생성하고, 그 브랜치로 변경하세요. 만약 blueprint에 대해서 작업 중이라면, 브랜치 이름을 bp/BLUEPRINT으로 생성하세요. 여기서 BLUEPRNIT는 Launchpad내의 blueprint 이름입니다. (예: bp/authentication)

일반적으로 버그에 대해서 작업할 때에는 브랜치 이름을 bug/BUG-NUMBER와 같이 생성합니다. (예: bug/1234567) 아니면 Gerrit에서 변경사항에 대한 제목을 나타낼 것이기 때문에, 의미 있는 이름으로 생성하세요. 제 경우 버그 번호는 1857035입니다.

버그 번호는 버그 페이지에서 아래의 빨간 박스 위치에서 확인할 수 있습니다.

버그 이슈 번호

다음의 명령어로 브랜치를 생성할 수 있습니다.

$ git checkout -b TOPIC-BRANCH

생성된 브랜치 bug/1857035

 

변경사항 작업하기

이제 해당 버그를 위한 브랜치로 이동했으니, 해당 버그나 이슈에 대해서 작업합니다. (제 경우에는  neutron/tests/functional/cmd/test_netns_cleanup.py에 대해서 작업했습니다.)

 

변경사항 테스트하기

여기를 참고하여 변경사항에 대해서 테스트하세요. 저는 tox를 사용합니다. 제가 사용한 명령어는 다음과 같습니다.

$ cd /opt/stack/neutron/neutron/tests/functional/cmd
$ tox -e functional -- test_netns_cleanup.NetnsCleanupTest.test_cleanup_network_namespaces_cleans_dhcp_and_l3_namespaces

이는 test_netns_cleanup.py 모듈의 NetnsCleanupTest 클래스의 test_cleanup_network_namespace_cleans_dhcp_and_l3_namespaces() 메소드를 테스트합니다. 여기서 주의할 점은 tox는 파일의 경로와 클래스, 메소드는 마침표(.)로 구분합니다.

테스트 결과

위와 같이 테스트가 성공적으로 끝났다면 이제 변경사항을 제출할 준비가 됐습니다.

 

변경사항 제출하기

변경사항을 제출하기 전에, OpenStack의 커밋 메시지 컨벤션과 관련된 포스트를 읽고 진행해주세요. (여기와 여기를 참고해주세요.)

작성한 커밋 메시지

대부분의 경우 Git-review가 설치한 Gerrit 커밋 훅에 의해 Change-Id 라인이 자동으로 추가된다는 점에 유의하세요. (가장 첫 번째 커밋에는 Change-Id를 작성하지 않으셔야 합니다.) 이미 커밋을 했는데 Change-Id가 추가되지 않은 경우, Gerrit 설정 단계를 다시 수행하고 다음의 명령어를 실행하세요. `git commit --amend` 커밋 훅은 실제로 아무 변경을 하지 않더라도 커밋 메시지 수정이 끝나면 Change-Id를 추가합니다. Gerrit이 혼동할 수 있으므로 Change-Id는 절대로 변경하지 마세요.

변경사항에 대해 작업하고 커밋한 후, 리뷰를 위해 제출하세요.

$ git commit -a
$ git review

 

제출한 변경사항 확인하기

우리가 제출한 변경사항은 실시간으로 여기에서 확인할 수 있습니다. 제 변경사항은 이미 OpenStack에 병합되었으므로, 다른 사람의 변경사항에 대해서 확인해보겠습니다.

지금까지 제출된 변경사항들

위에서 "Mask the token used to allow access to consoles"라는 변경사항을 살펴보겠습니다.

 

제출한 변경사항 페이지. 리뷰를 위해 사용된다.

왼쪽 위의 빨간 상자를 확인하시면, 현재 제출한 변경사항의 번호를 확인할 수 있습니다. 이 분의 변경사항의 번호는 704255입니다. 오른쪽 아래의 빨간 상자를 확인하시면 코드 리뷰 점수와 테스트 결과를 확인할 수 있습니다. 이 분의 변경사항은 현재 통과하지 못한 테스트가 있네요. 이 경우에는 다시 새로운 패치를 작성하고 제출하면 자동으로 다시 Zuul이 테스트하고, 해당 패치에 대해 리뷰 점수를 부여합니다.

현재 진행 중인 테스트에 대해서는 여기를 확인하시면 됩니다.

제출한 변경사항에 대해 진행중인 테스트

위에서 말했다시피, 실패한 테스트가 있음을 확인할 수 있습니다. 만약 Zuul의 빌드 테스트를 통과한다면 다음과 같은 이메일을 받으실 수 있습니다.

Zuul의 빌드 테스트 결과

이제는 우리는 Zuul로부터 빌드 테스트도 통과했고, 변경사항이 병합되기까지 핵심 리뷰어들로부터 +2점의 리뷰를 2번 이상 받기만 하면 됩니다!