[OSS] OpenStack Meet-up 2

• 일자 : 2020-08-13(목) 19:00 ~ 21:30

---

Ian Y. Choi (최영락)

Git-Hub Repository에 어떤 양식으로 올려야 하는지

• OpenStack에서 쓰는 Tool들이 Git-Hub와 조금 다름. 그런 관점에서 설명
• 어느 순간부터 Git-Hub가 de facto Standard(사실상 표준) 
• Git 과 GitHub가 다른 것은 다 아시겠죠
• OpenStack 같은 경우는 OpenStack 전용 Repository를 만들었었고 git.openstack.org로요.
  지금은 opendev.org로 openstack foundation의 더 많은 opensource를 다루는 공간을 사용하고 있습니다.

OpenDev: Free Software Needs Free Tools

• Git-Hub의 PR(Pull-Request : 리뷰해주세요) 를 Opendev에서는 Gerrit이라는 Tool을 사용해서 Review를 요청합니다
• 메신저/커뮤니케이션 :
  - 저희는 Slack을 사용해서 소통하고 있지만
  - Openstack 재단/Openstack Main Contributor들은 IRC를 사용합니다.
• 버그 리포트 :
  - 오픈소스마다 다를 수 있겠지만 저희는
  - Launchpad / Stroyboard 를 사용합니다.
• Markdown :
  - Python기반의 Project들은 RST(Restructed Text)를 사용합니다.

 

 

• 저희가 쓰는 공간은 아래와 같습니다.

https://github.com/openstack-kr/contributhon-2020

openstack-kr/contributhon-2020

 

■ Git과 Github 차이

 

Git과 Github(깃허브)의 차이

 

---

Openstack을 다룰 때 GitHub 사용법

 

1. Fork를 사용하여 자신의 Repository에 가져온다.

 

2. Fork한 자신의 Repository에서 Clone 한다.

 

$ git clone https://github.com/lkeonwoo94/contributhon-2020.gitCloning into 'contributhon-2020'...
$ cd contributhon-2020/
$ git remote -v
origin  https://github.com/lkeonwoo94/contributhon-2020.git (fetch)
origin  https://github.com/lkeonwoo94/contributhon-2020.git (push)

upstream : fork 뜨기 전 main 저장소를 바라보면서, origin 저장소에서 작업을 하고

 

- Branch

$ git branch
* master
$ git checkout -b test
Switched to a new branch 'test'

$ git status
On branch test
nothing to commit, working tree clean

$ git branch
  master
* test

 

- Commit

$ git commit -a

 

3. Create Pull Request

- 이것을 가지고 Review를 합니다.

- Review를 올리는 방법에 대한 것은 아래에 적어놓았습니다.

 

4. RST로 작성하는 것을 권장하는 이유

RST 보이죠?

• 오픈스택의 문서 contribution은 RST로 진행이 됩니다.

 

5. Openstack의 Pull Request

• (인프라)opendev.org 를 직접 만들어서 제공합니다.
• https://opendev.org/opendev/sandbox

sandbox

• Fork 없이 Direct로 Clone 합니다.

$ git clone https://opendev.org/opendev/sandbox.git sandbox
$ cd sandbox/

$ git review -s
를 통해서 로컬 폴더에 커밋을 만들고 ID를 붙임
커밋에 gerrit을 통해 아이디가 붙고
원하는 것을 fetch? patch?함

 

---

http://cacti.openstack.org/cacti/graph_view.php

Graphs -> Tree Mode

• 오픈스택 컨트리뷰터들이 인프라를 관리
• 수많은 인프라에 대해 모니터링을 함
• IRC 로그 등등

http://status.openstack.org/openstack-health/#/

http://status.openstack.org/openstack-health/#/

• Health check도 가능함

모든 것을 Open Source 로 해보자는 Idea

진정한 오픈 소스라면, 모든 것을 다 오픈소스 Tool을 사용해서 라는 철학

 

GitHub와 Openstack의 Contribution은 다르다 !

---

4 open 이란 ?
: Openstack Foundation 에서 강조하는 가치. 4가지 주제로 활동한다.

OpenStack Governance: The Four Opens

• Open Source : 우리는 Enterprise Version 안한다. Community 기반이 핵심 가치이다.
• Open Design : Design 하는 Process를 공개하겠다.
• Open Development : 모두 다 개발에 참여할 수 있다.
• Open Community : 특정 회사/국가가 주도하지 않는다. 느린 합의를 지향한다.

Openstack Foundation은 이제 openstack만 하지 않아요.

Opensource 기반의 주변 에코시스템을 아우르는, Infra Structure를 만드는 방향성으로 가고있어요.

 

[ 오픈스택 5가지 메인 프로젝트 : 배포/컨테이너/IaaS/Edge-Computing/CI-CD]

---

OpenStack Governance
: 전 세계의 수많은 개발자들이 모이기 때문에

OpenStack Docs: OpenStack Governance

• Committees

• Foundation Board Director : 이사진의 역할. 기술적으로 뛰어나거나, 오픈스택의 방향성을 결정함. 지원을 하고, 커뮤니티의 투표를 통해서 결정됨.
  ↔ Openstack Staff : OSF에 돈을 받고 고용된 사람. (행사 준비/운영 진행)
  
  
• Technical Commitee : Group. 기술위원회. Openstack에 필요한 기능들을 결정하는 사람. 이 또한 지원을 하고 투표를 통해 결정 됨
  
  
• User Commitee : 유저 커뮤니티가 잘 운영되도록, 더 많은 사람들이 커뮤니티에 들어올 수 있도록 도와주는 역할
  
  

 

• Roles (역할)

• Active Technical Contributor(ATC) : 오픈스택의 Release주기(6개월) 이내에 한번이라도 Commit 한 사람.
• Active Project Contributor(APC) : ATC보다 발전된 개념. 특정 Project에 많은 공헌을 한 사람. Maintainer의 수준
• Project Team Lead(PTL) : 팀장님. 6개월마다 바뀌긴 하는데 보통 연임함. PTL에 따라서 Project가 움직임.
• Core Reviewer : APC의 역할이라고도 볼 수 있는데, Gerrit에 +2점을 줄 수 있음 (Merge 가능)
• Active User Contributor(AUC) : 기술적인 것 말고, 유저 커뮤니티를 위해 활동하는 사람

 

---

메신저/커뮤니케이션 : IRC

OpenStack Docs: Communication

• IRC를 기본으로 채팅 함 (전통적인 기술 IRC) :: 인스턴스 식
  - 프로젝트 별로 채널을 만들어 놓음 (Slack 같은 느낌)
  - 문서들이 산발적으로 펼쳐져 있음
  - 처음 접할 때 History 파악은 어렵지만, 메인테이너들에게 물어보면서 알게 됨

OpenStack Docs: Setup IRC

[IRC 로그]

Thursday, 2020-01-16

 

• 메일링리스트(ML) - 주소를 구독하는 사람에게 뿌림  :: 중요한 공지/논의
• Wiki Page : 정리
• Etherpads : 회의록, 아이디어 를 기록하는 곳. 나는 이런 것을 하고 있어
  - 오프라인에서 만나서 이야기를 하면서, 이더패드에 정리함
  - 대부분의 자료는 이더패드에 있음
  - 단점은 이더패드에서 검색이 잘 안됨
  - 기능의 History를 찾기 어려움

OpenDev Etherpad

• ask.openstack.org : 오픈스택의 Stackoverflow 같은 곳

Questions - Ask OpenStack: Q&A Site for OpenStack Users and Developers

---

지금까지 이야기한 튜토리얼

OpenStack Docs: Code & Documentation Contributor Guide

이 튜토리얼을 따라하겠습니다.

 

1. 계정생성

OpenStack Docs: Account Setup

• OSF 계정
• StoryBoard 계정 (Ubuntu One 계정) : 코드관리, Bug tracking software

 

1-1. OSF 계정

https://www.openstack.org/join

Become a member of OpenStack, one of the largest open source communities in the world

• 위의 페이지에 접속한다
• Foundation member 클릭

 

1-2. StoryBoard 계정 : bug tracking software

 

https://storyboard.openstack.org/

StoryBoard

• 위의 페이지에 접속한다
• Ubuntu One User로 가입

 

2. Git Commit Messages

오픈스택은 정해진 규칙대로 작성하지 않으면 커밋이 되지 않습니다.

Git 메시지는 중요합니다.

OpenStack Docs: Setup and Learn GIT

Git Commit Message Format은 아래와 같습니다.

 

line #	Name	Description
line 1	Summary Line	- Patch 내용을 설명, 요약 - 마침표를 적으면 안됨 - 50자 이내로 작성
line 2	공백	한줄 띄움
line 3	Body	- 가로 72자 이내 - 넘으면 개행
...	...	...
line n	공백	한줄 띄움
line n+1	Tags	* Change-id : 우리가 작성하는 것이 아님. git review라는 도구가 자동 생성 * Task : 내가 해결하고자 하는 Task 번호 * Story : 내가 해결하고자 하는 Story 번호 * Closes-Bug : Fully Fix. 완번 버그 수정. 내 Patch는 완전히 버그를 Cover함 * Partial-Bug : 일부분 버그 수정 * Related-Bug : Reference가 되는 Bug들. 연관있는 버그. 유사한 버그 <<Blue print 내용 : 새로운 기능을 제안 - 제안서>> * Implements : 제안 * Partial-Implements : 일부 제안

 

[예시]

    Switch libvirt get_cpu_info method over to use config APIs     # Summary Line

    The get_cpu_info method in the libvirt driver currently uses   # Body line
    XPath queries to extract information from the capabilities     # Do not over 72
    XML document. Switch this over to use the new config class
    LibvirtConfigCaps. Also provide a test case to validate
    the data being returned.

    DocImpact
    Closes-Bug: #1003373                                           # Tag
    Implements: blueprint libvirt-xml-cpu-model
    Change-Id: I4946a16d27f712ae2adf8441ce78e6c0bb0bb657           # Auto generated

※ 참고 : https://wiki.openstack.org/wiki/GitCommitMessages

 

저희는 주로 Closes-Bug와 Task를 많이 쓰게 될 거고요

오늘 실습한 대상은 Launchpad를 많이 쓸 거에요

 

 

3. Gerrit :: Openstack에서 사용하는 Git 기반의 Code Review System
- 일정 점수 이상을 받아야 코드 변경을 적용

Gerrit의 원리는 Github의 원리와 조금 달라요

---

■ 참고 : https://d2.naver.com/helloworld/9767525

https://docs.opendev.org/opendev/infra-manual/latest/gettingstarted.html

Getting Started — OpenDev Manual documentation

• Gerrit을 들어가 볼게요. 아래 페이지를 클릭하세요

 

https://review.opendev.org/

Gerrit Code Review

• Login을 하면 아까 만들었던 Ubuntu One 의 계정이 필요합니다.
• 그리고 계약서에 Sign을 하게 됩니다.
• Login 후 Settings에서 Individual 을 클릭합니다.
• 컨트리뷰션한 코드에 대한 저작권을 OSF에 귀속한다는 것에 동의해야 합니다.

위 내용 진행을 위해서 , 아래의 페이지를 참고 할 수도 있어요.

OpenStack Docs: Setting Up Your Gerrit Account

그리고 나면, 위 페이지 대로 SSH Key를 등록해야 합니다.

 

Key가 없을경우 아래처럼 만들 수 있습니다.

ssh-keygen

 

4. Git Review :: Gerrit을 쓰기 위해서

OpenStack Docs: Setting Up Your Gerrit Account

1. git-review install

sudo pip install git-review

 

 

2. Clone Opendev

sandbox

• Fork 없이 Direct Clone

$ git clone https://opendev.org/opendev/sandbox.git sandbox
$ cd sandbox/

 

3. Git Config

git remote -v
# 하면 opendev의 origin만 바라보고있습니다.
# 근데 우리는 gerrit을 연동시켜야하죠

git config --global user.name <username>
git config --global user.email <useremail>
# Gerrit에 연동할 꺼니까, review.opendev에 사용했던
# Ubuntu One 에 등록한 e-mail을 반드시 사용하셔야 합니다.

git config --global gitreview.username <username>
# review.opendec 에 있는 username을 똑같이 맞춰 주셔야합니다
# 안맞추면 push가 안됩니다

$ git review -s
# git review라는 Tool이 Opendev에 내 설정을 넣어줍니다

# 로컬 폴더에 커밋을 만들때 ID를 붙임
# 커밋에 gerrit을 통해 아이디가 붙고 원하는 것을 patch?함

 

 

$ git remote -v

Gerrit에 연결 됨

 

4. Bug Test 하기

https://launchpad.net/openstack-dev-sandbox

openstack-dev-sandbox in Launchpad

4-1. Bug Report를 합니다

- 유사한 버그가 있는지 검색합니다.

 

- 유사한 버그가 없다면

- Summary를 적고 Bug 내용을 적고 Commit을 합니다

- Bug가 생성됩니다. Bug 번호가 생성됩니다.

- Bug 번호가 굉장히 중요해요

버그를 수정하는 Commit을 만들어 볼거에요

vim [파일명 아무거나] [내용도 아무거나 채움]
git add [파일명]
git commit [파일명]

 

자 여기서부터 아까 배웠던 Commit Message를 적용해주면 됩니다

Buf fix summary line

어쩌구 저쩌구
블라블라블라

Closes-Bug: #[Bugid]

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch master
# Your barnch is ahead of 'origin/master' by 1 commit.
# *use "git push" to publish your local commits)
#
# Changes to be committed:
#           new file : [파일명]

저장해주고 닫으면

 

git log

깃 리뷰가 알아서 체인지 아이디를 만들어줌

• 저는 아무짓도 안했는데 Change-ID가 생성이 됐어요
• Git Review Tool이, 제가 Commit을 하는 순간 Change-ID를 만들어 줍니다.

 

git review
#push 대신 review를 사용합니다

이렇게 뜨면 성공이에요

 

remote 주소로 들어갑니다 : https://review.opendev.org/#/c/750048/

• Zuul이 체크하고 Patch를 했어요
• Patch Set 2: Verified+1 Build succeeded (check pipeline).
• Verified +1은 Zuul이 +1점 준거에요. 아무런 TC가 없어서 Success가 떨어진거에요

 

그럼 이제 올린 파일을 클릭하고

Line을 클릭하면 적는 공간이 생겨요

여기에 Review 할 Message를 작성하고 Save 해주세요

 

Comment를 달고나서 위로 올라가기를 클릭해주세요

 

그리고 Reply를 눌러서 내용을 작성하고 Post를 누르세요.

Post를 눌러야 Comment가 달립니다.

 

 

자 그럼 이제 CodeReview 받은 내용을 토대로 파일을 다시 수정합니다.

vim [파일명 아까꺼]
#파일수정
git add [파일명]
git commit --amend

이 상태에서 커밋 메시지를 수정합니다.

 

그리고 나서

git status

를 확인해보면

Commit 할 것이 없다고 나옵니다.

Amend를 하면 수정한걸로 돼요

 

이 상태에서 다시 review를 올려요.

새로운 review가 만들어 진게 아니고, 아까 만들어놓은 review와 연결이 될 거에요

git review

 

그리고 다시 그 주소로 들어가보면 PatchSet이 추가가 되었어요

 

그리고 이렇게 코드 변경점을 확인할 수 있어요

그리고나서 아까 Reply에서 +2점을 줍니다.

그러면 Zuul이 Verified를 돌아서 +1점을 줍니다.

아직 하나더 남았는데요

Workflow+1를 해야합니다. 이것은 PR과 동일합니다. 지금은 저희가 하지만, 실제로는 Maintainer들이 해요

 

Workflow+1를 하면, Zuul이 다시한번 전체적으로 Verified를 돌고 Merge가 됩니다

• Zuul Check : Unit Test
• Zuul gate : Integration Test, python version 별 test

 

Commit 통계를 내주는 곳

https://www.stackalytics.com/

Stackalytics | Official community contribution

• 여기다가 계정 정보를 등록해주셔야 합니다.
• 아래의 링크를 들어가셔서, 알파벳 순서에 맞게 이름을 작성해주셔야 해요.

https://github.com/stackalytics/default_data

stackalytics/default_data

• 아래와 같이 작성해주시고, PR을 날리면 굉장히 느리지만 언젠가는 Merge가 됩니다. (2주정도)

{
            "launchpad_id": "launchpad ID 적기",
            "zanata_id": "zanata ID 적기",
            "companies": [
                {
                    "company_name": "*independent",
                    "end_date": null
                }
            ],
            "user_name": "launchpad username",
            "emails": ["이메일"]
},

• Indent를 잘 맞춰주셔야 합니다! 저는 이것 때문에 시간을 많이 날렸어요 ㅠㅠ..

 

 

• https://launchpad.net/

keonwoo lee in Launchpad

---

Openstack의 번역

모든 번역은 Zanata라는 도구를 쓰고 여기에서 합니다.

 

https://translate.openstack.org/?dswid=-7210

Zanata: Home

• 별도로 가입을 해주셔야 합니다.
• 그리고 Explorer Tab에서 아래와 같이 번역작업을 진행할 수 있어요

 

위 Site에서 Login이 되지 않는 오류가 있습니다.

• 이렇게 Login을 시도하면 에러가 뜹니다.

• 주소창을 보니 Create_user로 되어있어요. 이상하네요

그래서 제가 찾은 방법은 다음과 같습니다

• Sign up 에서 아무렇게 입력을 해줍니다.
• 그리고 sign up을 누르면

• 로그인 할 수 있는 페이지로 바뀝니다.
• 이상태에서 Log in 을 누르면

• Login이 됩니다... 이상한 시스템이네요

---

StoryBoard Code Patch

 

• 여기는 openstackclient에 대한 버그를 확인할 수 있어요
• 코드패치는 패치를 하는 것도 중요하지만, 오래 전의 버그 리포팅이 더이상 유효하지 않다는 것을 알려주는 것도 중요합니다.
• 여기서 수정해보고 싶은 버그를 선정하고, 내용을 분석해보세요

 

python-openstackclient에서 해결해볼만한 이슈들입니다.

• "Image upload doesn’t support the upload progress like in glance client"
  https://storyboard.openstack.org/#!/story/2007777
  
• "server resize --flavor --wait waits for wrong success statuses"
  https://storyboard.openstack.org/#!/story/2006973
  
• "Provide support for migration-list command in openstackclient"
  https://storyboard.openstack.org/#!/story/2007575
  
• "Provide support for server-migration-list command in openstackclient"
  https://storyboard.openstack.org/#!/story/2007582