ONE
ONE copied to clipboard
Samsung
[SSAFY] ONE-Dockerizing (OOTPG) project review
Purpose
Shares some questions and answers in implementing ONE-Dockerizing project in SSAFY team.
Please understand that this issue is written in Korean so that we can quickly and clearly understand and participate in the new project.
/cc @Samsung/ootpg
1주차 질문&답변
Q. Compiler, Backend Extension, Toolchain의 상호작용과 계층관계가 어떻게 되나요?
- Toolchain에 대해 이해한 내용이 맞을까요? 이해한 내용 ● Toolchain은 Compiler command tool과 Backend-specific tool의 집합입니다. Compiler command tool은 Compiler가 제공하는 cmd(one-build, one-import 등)입니다. ● ONE-vscode에서는 toolchain을 이용해 설정파일(.cfg)에 기입된 정보를 바탕으로 컴파일, 최적화 등을 진행합니다. ● ONE-vscode는 제공 가능한 toolchain을 추가하고 선택이 가능합니다.
Toolchain 은 Backend-specific tool 까지 포함하고 있는 것이 맞으나, 이 프로젝트에서는 Backend 가 구체화되지 않았기 때문에 Toolchain 에 one-compiler 만 포함하는 것으로 하면 좋을 것 같습니다. (만약, 시간적 여유가 된다면 dummy backend 를 구현하여 포함할 수도 있겠습니다.)
Q. Compiler, Backend Extension, Toolchain의 상호작용과 계층관계가 어떻게 되나요? 2) ONE-vscode와 Backend Extension 설치 없이 Toolchains을 추가할 수 있나요?
Toolchain package 는 one-vscode 와 backend extension 의 도움 없이도 artifactory (debian source repository)를 통해 설치가 가능합니다. (현재는 사내에서만 운영중입니다.)
- 계획서에는 Compiler만 도커화하는 것을 요구하는 것으로 보이는데, 도커화된 컴파일러가 기존 ONE 프로세스의 나머지 부분인 Packager 및 Runtime과 유기적으로 잘 돌아갈지 걱정됩니다. 혹시 이 부분까지 고려해서 기능 구현을 해야할까요?
이 프로젝트는 ONE compiler 의 결과물을 활용하는 것으로써 ONE runtime 과 nnpackage (packager) 와의 연관성은 고려하지 않아도 됩니다. (기존 one compiler 에서 다른 부분과의 연관성이 고려되어있습니다.)
Q. 프로젝트를 할 때 어떤 부분을 중점으로 보면 좋을까요?
- ONE Compiler에서 코드는 어떤 파일이나 부분을 중점으로 보면 좋을까요?
- ONE에 관련된 참고하기 좋은 별도의 문서화된 자료가 있을까요?
One compiler 관련 One cmds 의 onecc script file 분석 https://github.com/Samsung/ONE/tree/master/compiler/one-cmds One compiler debian package 설치 및 onecc 실행 테스트 https://github.com/Samsung/ONE/releases/tag/1.20.0
Debian 관련 One compiler debian package files 분석 https://github.com/Samsung/ONE/tree/master/infra/debian/compiler 생성된 debian package 를 Launchpad 로 올리는 방법 (기존 one member의 도움 필요) https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage
One-vscode 관련 Compiler Backend interface 분석 https://github.com/Samsung/ONE-vscode/blob/main/src/Backend/Compiler.ts https://github.com/Samsung/ONE-vscode/blob/main/src/Tests/MockCompiler.ts Launchpad 로 upload 된 debian package 를 다운로드 하는 방법 https://wiki.debian.org/SourcesList
Q. ONE github에 ONE/infra/docker/에 있는 dockerfile은 어떤 용도인가요? 현재 진행하는 도커화(Dockerizing)와는 어떤 차이가 있을까요? (https://github.com/Samsung/ONE/tree/master/infra/docker)
이 파일들은 One rumtime 에서 검증을 위해 사용하는 Dockerfile 입니다. 이번 과제와의 관련성은 없습니다.
Q. 반드시 지켜야 할 Pull Request, Commit, Code Convention이 있을까요?
- how-to-contribute 문서에는 작성 템플릿에 대한 설명이 없어서, 템플릿이 있다면 알고 싶습니다.
- 참고 자료 : [how-to-contribute] (https://github.com/Samsung/ONE/blob/master/docs/howto/how-to-contribute.md)
One project 의 경우 one/compiler 아래에 프로젝트 디렉토리를 생성합니다. 이후 [project directory] 라는 prefix 로 Github issue나 PR을 생성하시면 됩니다.
One-vscode 의 경우 [OneToolchain] 과 같이 이슈의 범주를 알 수 있도록 prefix 를 붙여주시면 됩니다.
Issue 생성시에는 무엇을 하고자 하는 것인지 왜, 그리고 가능하다면 어떻게 에 대한 내용을 포함해주면 이슈 이해에 도움이 됩니다.
Pr 생성시에는 간단한 내용이라도 반드시 테스트를 수행하고 올립니다. Pr은 보는 사람이 쉽게 이해할 수 있도록 나눠서 올립니다. 진행상황이 있다면 draft pr 을 생성해 지금 어떤 방향으로 진행하고 있는지 공유해주면 좋습니다.
Q. compiler build에 많은 시간이 소요되는데 평균 몇 분이 걸리나요 ? 하드웨어 환경에 따라 편차가 큰가요? (팀원 빌드시 소요된 시간 - 2시간/3시간/5시간...)
Compiler 첫 빌드에는 오랜 시간이 걸립니다. 빌드에 필요한 external codes 를 미리 다운받고 빌드용 도커이미지를 이용하시면 좀더 빠르게 빌드가 가능합니다. (실제로 테스트는 해보지 않았습니다만 pr 검증시 이렇게 구현되어있는 것으로 보아 가능할 것 같습니다.)
만약 직접 해보고 싶으시다면 아래와 같이 접근해서 보시면 이해에 조금이나마 도움이 될 것 같습니다.
https://github.com/Samsung/ONE/pull/9619 PR 의 하단 “All checks have passed” 에서 show all checks 를 누르면 pr-nncc-debug 를 볼 수 있고 클릭해서 들어가면 console output 을 참고하면 빌드되는 모습을 참고 할 수 있습니다.
Q. slack 에서 질문답변을 주고 받을 때 어떠한 방식으로 드리면 편하실까요? <질문 남기는 시간 or 질문 내용>
질문 채널: 슬랙, email([email protected]) 혹은 카카오톡 중 편한 방법 질문 남기는 시간: 업무시간일때도 업무시간이 아닐때에도 상관없습니다. 적어도 하루에 한번 이상 확인할 예정입니다. 질문 내용: 오류의 경우 에러 로그나 에러 화면 캡쳐 이미지 등을 첨부해주시면 분석에 용이할 것 같습니다. 그밖의 질문은 편하게 연락주세요.
Q. 계획서 외의 추가하고 싶으신 기능이 있으실까요..?
현재로써는 없습니다. 각각의 기능이 쉽다면은 쉽지만 어렵다면 어려운 부분일 것 같습니다. 특히나 리눅스라는 시스템에 익숙하지 않다면 더 어렵게 느껴지실 것 같습니다. 구현하고자 하는 기능을 원활하게 구현하는 것을 목표로 하고 혹여나 과제에 부족함이 느껴지신다면 함께 논의해 변경 혹은 확장해 나가면 좋을 것 같습니다.
2주차 질문&답변
[ONE-vscode]
- Compiler
- a. MockCompiler에 보면 installedToolchain과 availableToolchain이 존재하는데 2개의 차이가 무엇일까요?
- i. installed 상태와 available 상태는 어떻게 구분될까요?
installed 는 이미 시스템에 설치가 된 상태, available 은 시스템에 설치가 되지 않았지만 사용이 가능한 상태로 구분됩니다.
사내에서 구성된 system 에서는 daily 로 toolchain debian package 가 빌드되고 이 패키지가 apt repository (debian package 를 받아올 때 사용하는 repository)로 업로드 됩니다. 그리고 사용자는 apt repository 를 apt source 로 등록해두어 시스템에 설치 가능한 package list 를 확인할 수 있고, 그 중의 하나의 패키지를 시스템에 설치할 수 있습니다.
ONE-vscode 와 연관지어 설명하면, Compiler interface 의 prerequisitesForGetToolchains() 의 함수는 toolchain debian package 가 업로드 된 apt repository 를 시스템에 추가시켜주는 동작(/etc/apt/sources.list.d/a.list 라는 파일에 사내 apt repository 를 등록)을 합니다. 이 과정이 실행되고 나면 ONE-vscode 는 apt repository 에 업로드 되어있는 debian package 의 list 를 받아올 수 있습니다. 이렇게 설치 가능한 패키지 리스트를 반환하는 것이 getToolchains() 함수입니다. 그리고 이미 시스템에 설치되어있는 패키지를 반환하는 것이 getInstalledToolchains() 함수 입니다.
ONE dockerizing 의 경우, one toolchain debian package 를 생성하게 될 것입니다. 이 package 를 ubuntu launchpad 에 업로드하고 해당 주소를 /etc/apt 이하의 source list 로 등록을 하면 업로드 된 패키지를 확인할 수 있고 설치할 수 있습니다. 이 과정을 prerequisitesForGetToolchains() 에서 해준다면 ONE-vscode 에서는 package 에 대한 정보를 가져올 수 있는 준비가 됩니다. 이 후 getToolchains() 함수에서 apt command 를 이용해 설치 가능한 패키지 리스트를 가져와서 반환해주면 ONE-vscode의 사용자는 Toolchain view 의 + 를 눌렀을 때 설치가능한 리스트를 볼 수 있게 됩니다.
위에 얘기드린 것들은 version 에 대한 고민없이 기본 구조에 대해서 설명을 드렸습니다. version 에 대한 지원이 들어가면 세부적으로 달라지는 것들이 있을텐데 일단은 이렇게까지만 구현이 되면 이후 version 지원에 대해 고민하기 더 편할 것 같습니다. 버전에 대한 내용은 차차 천천히 얘기를 나누면 좋을것 같아요. :)
ii. ONE-vscode에서 사용자가 toolchains을 선택할 수 있나요? (원래 상태를 보지 못했기 때문에,) 만약 그렇다고 가정할 때, ONE-vscode에서 사용자가 toolchains을 선택하고 추가하는 과정이 있다면, 사용자가 toolchain을 직접 찾아서 설정해줘야 할까요? 그리고 이게 available과 installed toolchain 중 어떤 것과 연관이 있을까요?
음, 여기서 이야기 하시는 toolchain 이 backend 를 의미하는 것인지 모호하긴 한데요, 우선 ONE-vscode 사용자는 Backend 를 선택할 수 있습니다. Toolchain view 에서 + 버튼을 누르면 먼저 backend list 가 보여집니다. 그리고 그 중 하나의 Backend 를 선택하면 해당 Backend code 구현이 실행됩니다.
우리는 ONE Toolchain Backend 를 만들어 ONE Toolchain 과 연동하고자 합니다. (ONE-vscode 에서 도원결의 팀의 목표입니다. 서로 같게 이해했을까요? :)) ONE Toolchain Backend 는 Backend interface 를 상속받아 만들 것입니다. 그렇게 만들어진 ONE Toolchain Backend 는 ONE-vscode 에서 선택이 가능해야 하므로 ONE-vscode 에 등록하는 과정이 있어야 합니다. API.ts 파일의 registerBackend 를 참고하면 ONE Toolchain backend 를 ONE-vscode 에 등록할 수 있습니다. 이 부분은 Backend Extension 이 있을 경우 해당 Backend extension 의 backend 를 ONE-vscode 에 등록해주는 역할을 합니다.
Backend 가 등록되고 나면 Toolchain view 를 그리기 위해서 getInstalledToolchains() 함수를 실행할 것이고 + 를 선택했을 때 설치 가능한 리스트를 보여주기 위해서 getToolchains() 함수를 호출하게 될 것입니다. 따라서 Backend 에 대한 내용은 available, installed toolchain 모두와 연관이 있습니다.
iii. 사용자의 input (ONE-vscode에서 toolchain viewer 에서 + 누르면 나타나는)과 docker-compiler 가 연결이 어떻게 되는지 모호합니다. [현재 이해한 바로는 Backend가 Compiler를 반환하고 Compiler는 가용한 toolchain을 반환하는 구조인 것 같습니다. input을 통해 입력받는 Backend name이 어떻게 Copiler와 Toolchain까지 연결되는지 이해하는데 어려움이 있습니다.]
위에 설명드린 내용이 이 질문에 어느 정도 답이 되었을 것이라 생각합니다. :)
- 이미 설치된 backend가 검색이 되는지(파일 시스템에 설치 여부에 따라), 아니면 직접 찾아서 추가해야는 건가요?
구현한 backend 가 ONE-vscode 에 등록되어 검색이 되기 위해서는 API.ts 파일을 참고하여 Backend 를 등록하시면 됩니다.
- test 관련 파일에 dummy-backend 를 backend name으로 사용해서 테스트를 진행하신 것 같은데 dummy-backend 는 ONE-vscode에서 어떻게 backend로 인식이 가능한가요?
ONE-vscode Tests 에서는 Backend.test.ts 파일의 BackendMockup 을 구현하였고 이를 register 하여 사용하였습니다.
- dummy-backedn를 정의해서 사용하는 방법이 backend 설치 없이 toolchain을 사용하는 방법일까요?
Backend extension 없이도 Backend 를 정의하고 추가할 수 있습니다. 위에 안내드린 방법을 이용해서요. 기존에 Backend extension 을 별개로 둔 것은 확장성과 보안 등등의 이유에서 별개로 구현되었습니다. 하지만 ONE Toolchain backend 의 경우 ONE-vscode 와 밀접한 관련이 있으므로 Backend extension 구현없이 Backend 를 자체적으로 ONE-vscode 내에 구현하는 안으로 진행하는 것입니다. :)
b. DebianToolchain.ts가 기존 파일 시스템에 있는 toolchains(데비안 패키지 설치를 통해 사용가능한 toolchains)을 활용하는 거라고 이해해도 될까요?
DebianToolchain.ts 파일은 Debian package 를 컨트롤 하기 위한 일반적인 방법을 구조화해둔 것입니다. ONE Toolchain Backend 에서도 이 DebianToolchain class 를 이용하면 좀더 쉽게 debian pkg 를 설치하고 제거하고 설치되었는지 확인하고 onecc 를 실행하는 일련의 과정을 실행할 수 있습니다. 다만, DebianToolchain.ts 에서는 onecc 를 실행하도록 강제해둔 부분이 있어 이 부분이 ONE Toolchain debian pkg 와 연동이 되려면 수정이 필요하거나 재정의가 필요할 것 같네요.
c. Compiler 인터페이스에 getavailableToolchain 메소드를 정의하도록 되었는데, 단순히 compiler에 설정된 availableToolchain의 목록을 반환해주는 메소드로 이해했는데 맞을까요? 그렇다면, availableToolchain의 목록은 어떻게 가져올 수 있을까요?
apt source 로 repository 가 등록이 되어있다면 apt command 를 이용해 가져올 수 있습니다. 이와 관련된 내용은 google 검색을 하면 다양한 방법을 안내해줄 것입니다. :)
이를 테면 apt-cache show bash 식의 명령어를 입력하면 apt source 에 있는 패키지 리스트를 읽어올 수 있습니다.
d. MockCompiler getToolchains 메소드에서 assert로 검증할 때, 왜 count === 1 이어야하는지현재 가용한 toolchain의 수는 1개로 제한되어 있는 것으로 이해했는데, 이유가 있을까요?
assert(count === 1, 'Count must be 1');
이 코드는 Tests 를 위한 코드로 constructor 에서 하나의 toolchain 만을 assign 하였기 때문에 반드시 count 가 1 이어야만 합니다. 이를 검증하기 위한 코드로 ONE Dockerizing 구현과 관련된 개념적인 해석과는 별개 입니다.
[ONE]
- One Dockerizing PPT HOW 파트에 one tool 이라는 단어가 있는데, 해당 단어가 onecc-docker 를 의미하는지 궁금합니다. https://github.com/Samsung/ONE/issues/8232
여기서 말하는 one tool 은 onecc binary file 입니다. one-compiler 를 설치하게 되면 onecc binary 가 설치됩니다. 해당 파일을 이용해 compile 및 여러가지 동작을 실행시킬 수 있습니다. one-compiler 가 이미 설치가 되어있다면 onecc 파일을 그냥 불러주기만 해도 실행이 됩니다. 하지만 one-compiler 가 설치되어있지 않다면 onecc-docker 에서 Docker image 를 빌드해 docker container 내의 onecc 를 실행하면 됩니다.
- onecc-docker 를 실행하면, onecc 에서 사용되는 여러 flag들을 입력으로 받아서 처리하게 만들면 될까요? onecc-docker 는 그리고 기존 onecc 를 이용해서 파이썬으로 작성하면 될까요?
onecc-docker 를 어떻게 구현하시는지는 도원결의 팀 내에서 원하는 방향으로 진행하시면 됩니다. onecc-docker 가 onecc 를 실행시켜주게 됨에 따라 onecc 의 parameter 를 그대로 받게 되겠지만 이를 일일이 onecc-docker 내에서 재정의할 필요는 없고 상황에 따라 잘 forwarding 해주면 될 것으로 생각됩니다. 사용하는 언어 역시 자유롭게 정하시면 됩니다.
- shell script는 어떤 역할을 하게 만들면 될까요? onecc-docker 가 shell script의 역할을 한다고 생각하면 될까요? 아니면 다른 역할을 하게 새로 구성해야 할까요?
onecc-docker 의 역할은 "one-compiler 가 이미 설치되어있다면 설치된 onecc 를 실행 or one-compiler 가 설치되어있지 않다면 Dockerfile 을 빌드해 docker container 내의 onecc 실행" 입니다. 이 구현체는 shell script 가 될 수도 있고 python script 가 될 수도 있고 binary file 이 될 수도 있습니다.
- 유저가 ONE Compiler Debian Package 버전을 선택할 수 있다고 되어 있는데 구현시, onecc-docker 를 실행할 때 버전을 선택할 수 있도록 구현해야할까요?
이 부분을 미리 염두해 두고 디자인하면 좋아요. 하지만 version 에 대해 설계하는 부분에 있어 고민이 많이 필요하다면 일단 version 없이 실행될 수 있는 basic 파일을 먼저 구현하시는 것도 제안드려요.
Version 을 염두해 둔다면 여러가지를 함께 고려할 필요가 있습니다.
one-compiler 는 daily 로 매일 매일 새로운 패키지가 릴리즈됩니다. 사용자가 그중 어떤 버전을 사용하고자 할지는 알수가 없죠. 그래서 onecc-docker 에서 version 을 염두해둔다면 one-compiler version list 를 가져와서 사용자에게 보여주고 사용자가 선택하면 선택한 버전으로 Docker file 을 생성하는 식의 과정이 필요하게 됩니다. 또한 이렇게 구현이 되면 one docker 용 debian pkg 는 버전에 상관없이 하나만 존재할 수 있으니 ONE-vscode 에서는 prerequisites() 함수에서 one-docker pkg 를 설치하게 하고 사용자의 docker image list 를 가져와서 available toolchain 에 보이게 할 수 있는데,,,, 이 부분은 구현이 필요하거나 디자인이 필요한 상황에 따로 미팅을 잡고 함께 얘기해보면 좋을 것 같아요. ^^
- onecc-docker 구현 방향에 대해 2가지 경우의 수를 생각해보았습니다! 혹시 생각한 두가지 구현 방향중 하나가 맞는지 궁금합니다.
- a. onecc-docker 실행 시, 컨테이너 foreground 생성 → circlefile 변환 → 컨테이너 종료
- b. onecc-docker 실행 시, 컨테이너 background 생성 → attach로 접근 후 circlefile 변환 → 컨테이너 유지
제가 생각했던 안은 a 입니다. :) 컨테이너가 유지가 되어 이를 이용해서 할 수 있는게 있다면 b 도 고려해볼텐데 제가 생각했을 때에는 b 가 되었을 때의 이점은 없었어요. 혹시 b 가 되었을 때 이점이 있다면 공유해주세요~~ 저도 같이 고민해볼게요.
질문에 충분한 답이 되었을 지 모르겠어요. 글로 설명하자니 너무 어렵네요 ^^ 언제든 문의 주시면 답변 드릴게요 연락주세요. :)
3주차 질문&답변
참고
- one-build 는 deprectaed 된 툴이니 볼 필요 없음
Q. [Dockerizing] ONE 버전 관리 관련해서 issue에서 여러 피드백을 주셨는데, 버전관리 부분은 일단 빼고 최신 버전에서의 작동에 집중하는 것이 좋을까요?
A. Version 반영된 코드를 draft code 로 작성하신 부분 올려주시면 좋을것 같아요. 그리고 이슈에서 얘기된 것처럼 최신 버전에서의 작동에 대해서도 구현해서 올려주시면 좋구요. 사실 최신 버전을 이용하는 기능이 기본이고 거기에 추가로 구현이 필요한 것이어서, 기본 동작부터 구현하고 반영한 이후에 더 추가적인 기능을 넣는게 좋긴 할것 같아요.
PR 을 작성할 때 룰 중에 하나는, "한 PR 에서는 하나의 기능만을 구현하자" 라는게 있어요. 한 PR 에서 너무 많은 기능을 한번에 넣으면 코드를 리뷰하기도 어렵고 추후 상황에 따라 특정 PR 을 제거하거나 다른 조치를 해야할 때 다른 동작들도 영향을 받게 되거든요.
그래서 PR 을 나눠서 올려주시면 좋을것 같아요. 구현하신 코드도 방향성을 보기 위해 같이 공유해주셔도 좋을것 같아요. comment 에 version 에 대한 것은 정해진 것은 없으나 기능 동작 검증을 위해 테스트한 코드이다. 라고 붙여 주시면 될것 같아요.
Q. [Dockerizing] ONE-Dockerizing 의 목적에 대해 확인을 부탁드리고 싶습니다.
A. 사용자의 사용성을 높이기 위함 ONE 을 지원하지 않는 OS 에서도 사용할 수 있도록 하는 목적과 서로 다른 버전을 동시에 사용할 수 있도록 사용 편의성을 높이려는 목적, 그리고 안정적인 docker 를 이용해 간소화된 설치와 빠른 실행 등이 목적에 있습니다.
우리가 이것을 구현하더라도 지금 당장은 Windows 나 Mac 에서는 사용이 어려울거에요. 두 os 를 지원하기 위해서는 onecc-docker script 가 os 에 맞게 각각 구현이 필요하고 배포도 다양하게 되어야해서요. 하지만 여러분들께서 구현한 부분이 된다면 약간의 살만 붙이면 여러 os 에서 실행이 될거에요.
Q. [Dockerizing] PR 올리기 전에 테스팅할 수 있는 툴이나 방법이 있을까요?
A. issue 생성 -> fork 한 개인 repo 에서 구현 -> main repo 에 pr 생성 만약 구현한 기능에 문제가 없다고 생각하면 바로 PR 생성하셔도 되세요, 그런데 이 PR 을 계속 수정해서 더 작업을 하고자 하시면 draft PR 을 생성하시면 되세요.
테스트 코드를 작성할 수 있다면 기능 검증에 더할 나위 없이 좋을것 같습니다. 하지만 우리는 기간 내에 프로젝트를 완성시켜야 하기 때문에 test 를 작성하는데 너무 많은 노력이 들어간다면 일단은 배제하고 진행해도 좋을것 같아요.
구현하시면서 기본적으로 테스트는 해보실 거라고 생각해요. 테스트한 결과나 내용을 comment 로 공유한다면 리뷰에 더 도움이 될것 같습니다.
Q. [ONE-Vscode] ONE Toolchain Backend 를 구현할때 Backend.ts 에 Bacnend interface 의 구현체를 만들어야 할까요? 따로 ONEToolchainBAckend.ts 를 만들어야할까요?
A. 따로 만드시는게 좋을것 같아요. 하나의 파일은 하나의 목적? 구현을 위해 존재하는게 관리가 편하니까요. Backend directory 내에 ONE 이라고 dir 만드시고 그 안에 ONEToolchain.ts 를 만드시면 어떨까요?
Should I use SSDC-S002 repository for pull request? or can use my personal repository? and When I make draft pull request, Is there any commit message format? and How can I use -s in pull request? or just write ONE-DCO-1.0-Signed-off-by: on pull request like other people? Thank you
@jyoungyun
음, SSDC-S002 repository 가 ONE 을 fork 한 repository 인가요? 그럼 SSDC-S002 repo 에서 pull request 를 날리시면 되세요. 만약 아니시라면 ONE 을 fork 한 레포에서 작업하시면 되구요. ^^
commit message 포멧은,,,, header 에는 [prefix] 붙이시고 내용에는 적어도 한줄 이상 내용을 써주셔야 하세요. 그리고 Signed off 가 없으면 PR 올렸을때 check error 가 나니 git commit -S 로 signed off 붙여서 올려주세요. :)
추가)
morumoru 아이디 눌러서 들어가보면 repository 들이 보이는데, 아직 ONE 을 fork 한 repository 가 보이지 않네요~~~ 개인이 PR 을 올리려면 반드시 fork 를 먼저 해야해요 ^^ 이 페이지 오른쪽 상단에 보면 Fork 라는 버튼이 있는데 그 버튼 누르셔서 자기 계정으로 fork 먼저 하시면 되세요 :)
/cc @morumoru
음, onecc 의 -O 옵션은 string 을 input 으로 받는 것으로 보여요. optimization 폴더에 파일이 존재해야 한다는 내용은 어디서 확인하신 걸까요?
one-vscode에서 backend를 register를 하면, install 하지 않더라도 Toolchain view 밑에 등록된 backend이름 밑에 보이는 게 원래 의도된 사항인가요? 아니면 처음에 install 되지 않으면 보이지 않는 게 맞나요?
/cc @jyoungyun
one-vscode에서 backend를 register를 하면, install 하지 않더라도 Toolchain view 밑에 등록된 backend이름 밑에 보이는 게 원래 의도된 사항인가요? 아니면 처음에 install 되지 않으면 보이지 않는 게 맞나요?
아마도 getInstalledToolchains 에서 onecc-docker 를 리턴해주고 있는게 아닐까요?
/cc @lettersto
아마도
getInstalledToolchains에서 onecc-docker 를 리턴해주고 있는게 아닐까요?
맞습니다. Mock쪽이 그렇게 되어 있길래 원래도 그런지 궁금했습니다! 저희는 원래는 안 보이는 게 맞을 거 같다고 얘기가 나왔었습니다. 원래는 안 보이는 것이 맞는다는 거지요?
질문이 나온 이유는 저희가 해당 toolchain이 installed됐는지 여부를 체크하는 방법을 아직 찾지 못했기 때문입니다. 이 방법을 계속 모색 중입니다. getInstalledToolchains 함수가 Backend register를 하면 자동적으로 실행되는 것 같은데, parameter로 toolchainType도 자동적으로 넘어와서, toolchain type이 일치하면 바로 installedToolchain을 return해서요!
/cc @jyoungyun
음, onecc 의 -O 옵션은 string 을 input 으로 받는 것으로 보여요. optimization 폴더에 파일이 존재해야 한다는 내용은 어디서 확인하신 걸까요?
onecc 파일 내부에 _get_parser라는 합수가 있는데 해당 함수를 실행하면 utils.py의 _get_optimization_list 함수를 실행하여, optimization 리스트들을 가져오게 됩니다.
따라서, _get_optimization_list 함수를 확인했을 때, onecc가 설치된 위치 상위에 optimization 폴더를 위치시켜야된다고 파악했습니다.
[one hierarchy]
one
├── backends
├── bin
├── doc
├── include
├── lib
├── optimization
└── test
Optimization options must be placed in `optimization` folder
/cc @jyoungyun
그렇군요~~~ 이 부분은 인지하지 못하고 있었어요 ^^ 우선 다른 이슈에서 얘기드린바와 같이 우리 프로젝트에서는 optimization dir 은 보류하고 작업하는게 어떨까요?
그렇군요~~~ 이 부분은 인지하지 못하고 있었어요 ^^ 우선 다른 이슈에서 얘기드린바와 같이 우리 프로젝트에서는 optimization dir 은 보류하고 작업하는게 어떨까요?
네 그렇게 하겠습니다!! 신경써주셔서 감사합니다 :)
처음에 Backend를 등록하고(backendRegistrationAPI 중에 *registerBackend(Backend something)을 호출) 어떤 toolchain도 추가하지 않은 상태라면 Toolchain view에는 Backend 이름만 표출되고 하위에 toolchain이 보이지 않아야할 것 같습니다.
- registerBackend 수행시 gToolchainEnvMap['BackendName']에 ToochainEnv(compilerOfBackend) 인스턴스 assign
이후에, + 버튼을 눌러서 toolchain을 저희가 생각한 시나리오대로 추가한다고 하면,
- 이미 등록된 Backend 목록이 처음에 보여지고 Backend를 선택할 수 있습니다.
- Backend를 선택하면 Backend가 가지는 compiler의 getToolchainTypes의 return 값(toolchain의 타입) 중에 선택할 수 있습니다.
- type을 선택하면 선택한 Backend의 compiler의 getToolchains 함수의 return 값으로 선택한 type 중 사용 가능한 toolchain의 목록(ex. version 목록)을 보여주고 선택하면 설치가 이루어집니다.
Toolchain view는 이미 등록된 특정 백엔드가 가지는 컴파일러의 getInstalledToolchain의 return 값(Array<Toolchain>)을 가지고 그려지는 것으로 파악했습니다. 따라서 getInstalledToolchain의 return 값은 실제로 설치된 toolchain의 배열이어야할 것 같습니다.
그렇다면 toolchain을 추가/제거하는 과정에 따라서 올바른 Toolchain view가 보여지기 위해서는 getInstalledToolchain에서 사용가능한 toolchain(available toolchain) 중에서 실제 설치되어 있는 toolchain만 필터링하여 반환해주어야할 것 같은데
- 해당 로직을 getInstalledToolchain 안에 구현해야하는게 맞을까요?
- 필터링하는 로직을 구현해야하는게 맞다면 기존에 사용하신 방법이 있을까요?(저희가 생각해본 방법은 아래와 같습니다.)
생각해본 필터링 방식
toolchain.installed()의 결과로 만들어진 Command
dpkg-query $(package-name)=$(version.str()) && echo $?의 실행 결과에 따라 분기 (해당 command는 JobRunner로 실행하는게 맞을까요?)
/cc @jyoungyun
네, 잘 따라가보신 것 같아요 :) 위에서 설명한 것처럼 getInstalledToolchain 안에 설치된 패키지를 가져오도록 구현하면 되세요 ^^ 여기서 dpkg-query 와 같은 명령어를 수행할 때에는 JobRunner 로 호출하지 않고 child process 의 execSync 를 사용해 구현하시면 될 것 같아요. JobRunner 로 호출하게 되면 현재 구조에서는 원하는 결과값을 바로 가져오기 어려울 수도 있어 보여요.
만약에 onecc-docker debian pkg 가 이미 설치되어있다면 검색이 성공적으로 되어 onecc-docker 를 getInstalledToolchain 에서 반환하게 되고 그러면 Toolchain View 에서 이 반환된 아이템을 보여주게 될 거에요~~~
혹시 어려움 있으면 또 얘기주세요 :)
/cc @Psalmist-KIM
@Samsung/ootpg_docker
optimization directory 에 대해 추가로 알게 된 내용이 있어 공유드려요 :) 프로젝트와 관련이 있진 않지만 여러분들께서 찾아보셨던 내용이라 설계 의도를 마저 설명드리면 좋을것 같아서요.
optimization directory 에 설치되는 cfg 파일들은 사용자에 의해 생성되는 파일이 아니고 시스템 상에서 설치해주는 파일이라고 해요.
그럼 추후에 optimization 관련 기능이 완전히 구현이 되면 one-compiler 에 의해 optimization 내에 cfg 파일이 설치될 것이고
우리가 만든 docker image 에도 optimization dir 은 이미 생성되어있으며 cfg 도 설치되어있을 것 같아요.
사용자는 -O 옵션을 사용해 optimization/*.cfg 의 파일 이름으로 원하는 최적화 옵션을 골라서 실행하게 되구요.
따라서 처음에 우리가 하려던 바와 같이 HOME (= /tmp) 를 mount 하여 도커 이미지를 실행시킨다면 실행할 때 cfg 위치로 인한 문제는 없을 것 같아요.
설명이 도움이 되셨길 바래요~~
optimization directory 에 설치되는 cfg 파일들은 사용자에 의해 생성되는 파일이 아니고 시스템 상에서 설치해주는 파일이라고 해요.
아 그랬군요..! 뭔가 오해가 있었던 것 같네요 :) 알려주셔서 감사합니다 !
안녕하세요 멘토님! 즐거운 월요일입니다!!
PR 관련해서 질문이 있습니다!! 혹시 리뷰어는 다른 팀 멘토님도 같이 지정해도 될까요? 어느 범위까지 지정해야 되는 것인지 고민이 됩니다!!
그리고 draft를 올릴 때 PR test와 format이 아무리 해도 실패를 하는데, 원래 이런 상태로 올려도 괜찮을까요? /cc @jyoungyun
안녕하세요 멘토님! 저도 PR 관련해서 질문 있습니다! 저번에 onecc-docker와 Dockerfile을 따로 따로 PR을 올리시면 좋겠다고 피드백을 주셨는데, 또 같이 주신 피드백으로 Dockerfile에 Version 변수를 사용해서, 동적으로 Dockerfile을 작성하는 것이 아니라 빌드할 때 --build-arg 옵션으로 변수 값을 주시라는 피드백에 따라 코드를 수정해 보았습니다. 그런데 이렇게 되면 onecc-docker와 Dockerfile이 Version 변수를 통한 연관 관계가 생기는데, 이런 경우에도 PR을 따로 올리는 것이 좋을까요? 감사합니다! /cc @jyoungyun
안녕하세요 멘토님! PR 테스트에서 발생한 오류 공유드립니다. 저희가 생각한 바로는 저희가 만든 ONEToolchain을 extension이 activate 되는 시점에 Backend로 등록하면서 발생하는 것 같습니다.
관련 PR : Draft : [ONEToolchain] Introduce ONEToolchain
1. [Check PR Format / check-format (pull_request)]
Run bash infra/format
Run bash infra/format
[FAILED] Format checker failed and update code to follow convention.
You can find changes in format.patch
Error: Process completed with exit code 1.
2. [Check PR test / check-test (pull_request)]
=============================================================================
Run DISPLAY=:44 xvfb-run --server-num 44 npm test ci
DISPLAY=:44 xvfb-run --server-num 44 npm test ci
shell: /usr/bin/bash -e {0}
...
9 failing
1) Backend
backendRegistrationApi
registers a backend:
AssertionError: expected 1 to equal +0
+ expected - actual
-1
+0
at Context.<anonymous> (out/Tests/Backend/Backend.test.js:53:27)
at process.processImmediate (node:internal/timers:466:21)
2) Toolchain
NodeBuilder
#createBackendNodes()
creates BackendNode list:
AssertionError: expected 2 to equal 1
+ expected - actual
-2
+1
at Context.<anonymous> (out/Tests/Toolchain/ToolchainProvider.test.js:111:31)
at process.processImmediate (node:internal/timers:466:21)
3) Toolchain
NodeBuilder
#createToolchainNodes()
creates ToolchainNode list:
AssertionError: expected 2 to equal 1
+ expected - actual
-2
+1
at Context.<anonymous> (out/Tests/Toolchain/ToolchainProvider.test.js:118:31)
at process.processImmediate (node:internal/timers:466:21)
4) Toolchain
NodeBuilder
#createToolchainNodes()
NEG: creates ToolchainNode list using invalid backend node:
AssertionError: expected 2 to equal 1
+ expected - actual
-2
+1
at Context.<anonymous> (out/Tests/Toolchain/ToolchainProvider.test.js:131:31)
at process.processImmediate (node:internal/timers:466:21)
5) Toolchain
ToolchainProvider
#getChildren
gets Children with undefined:
Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (/home/runner/work/ONE-vscode/ONE-vscode/out/Tests/Toolchain/ToolchainProvider.test.js)
at listOnTimeout (node:internal/timers:559:17)
at process.processTimers (node:internal/timers:502:7)
6) Toolchain
ToolchainProvider
#getChildren
gets Children with BackendNode:
AssertionError: expected 2 to equal 1
+ expected - actual
-2
+1
at Context.<anonymous> (out/Tests/Toolchain/ToolchainProvider.test.js:190:31)
at process.processImmediate (node:internal/timers:466:21)
7) Toolchain
ToolchainProvider
#uninstall
requests uninstall:
AssertionError: expected 2 to equal 1
+ expected - actual
-2
+1
at Context.<anonymous> (out/Tests/Toolchain/ToolchainProvider.test.js:236:31)
at process.processImmediate (node:internal/timers:466:21)
8) Toolchain
ToolchainProvider
#setDefaultToolchain
request setDefaultToolchain:
AssertionError: expected 2 to equal 1
+ expected - actual
-2
+1
at Context.<anonymous> (out/Tests/Toolchain/ToolchainProvider.test.js:279:31)
at process.processImmediate (node:internal/timers:466:21)
9) View
InstallQuickInput
#getAllToolchainEnvNames()
gets all toolchain env names from global toolchain env:
AssertionError: expected 2 to equal 1
+ expected - actual
-2
+1
at Context.<anonymous> (out/Tests/View/InstallQuickInput.test.js:370:31)
at process.processImmediate (node:internal/timers:466:21)
Error: 9 tests failed
at /home/runner/work/ONE-vscode/ONE-vscode/out/Tests/index.js:151:93
at done (/home/runner/work/ONE-vscode/ONE-vscode/node_modules/mocha/lib/mocha.js:1058:7)
[main 2022-09-16T13:12:07.019Z] Waiting for extension host with pid 2123 to exit.
[main 2022-09-16T13:12:07.026Z] Extension host with pid 2123 exited with code: 0, signal: null.
Exit code: 1
Failed to run tests:
Error: Process completed with exit code 1.
=============================================================================
PR 관련해서 질문이 있습니다!! 혹시 리뷰어는 다른 팀 멘토님도 같이 지정해도 될까요? 어느 범위까지 지정해야 되는 것인지 고민이 됩니다!!
그리고 draft를 올릴 때 PR test와 format이 아무리 해도 실패를 하는데, 원래 이런 상태로 올려도 괜찮을까요? /cc @jyoungyun
one 의 경우에는 우선 저만 지정해주세요, one-vscode 의 경우에는 저와 @Samsung/one-vscode 를 함께 리뷰어로 지정해주세요.
PR 을 올릴때에는 모든 검증이 통과해야해요 ㅠㅠ format error 는 각 프로젝트마다 format 을 체크하는 방법이 있는데 이를 이용하셔서 코드 올리기 전에 미리 테스트 후 PASS 되면 올려주세요.
one
$ ./nnas format ./compiler/onecc-docker
one-vscode
$ bash infra/format <directory name>
그리고 PR 올리실때 commit message 에 signed off 추가하시게 되는데, 이때 one 과 one-vscode 각각 아래와 같이 Signed off 를 수정해주세요. :)
one
ONE-DCO-1.0-Signed-off-by:
one-vscode
ONE-vscode-DCO-1.0-Signed-off-by
그런데 이렇게 되면 onecc-docker와 Dockerfile이 Version 변수를 통한 연관 관계가 생기는데, 이런 경우에도 PR을 따로 올리는 것이 좋을까요? 감사합니다! /cc @jyoungyun
네, 연관 관계가 있어도 가독성을 위해서 별도로 올리셔도 되세요. ^^
2. [Check PR test / check-test (pull_request)]
이 경우에는 test code 를 함께 수정해주어야겠어요, 예전에는 backend 가 하나도 없는 상태에서 test 시에 하나만 등록하니 1 인지 체크했지만, 앞으로는 기본적으로 one 이라는 Toolchain 이 하나 등록된 상태에서 동작할테니 해당 값이 2가 되도록 수정해야 할것 같아요.
그밖에 test 들도 backend 추가에 의한거라면 함께 수정이 되어야 할것 같아요.
- Toolchain ToolchainProvider #getChildren gets Children with undefined: Error: Timeout of 2000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (/home/runner/work/ONE-vscode/ONE-vscode/out/Tests/Toolchain/ToolchainProvider.test.js) at listOnTimeout (node:internal/timers:559:17) at process.processTimers (node:internal/timers:502:7)
이 에러는 좀더 살펴봐야겠네요.
이 경우에는 test code 를 함께 수정해주어야겠어요, 예전에는 backend 가 하나도 없는 상태에서 test 시에 하나만 등록하니 1 인지 체크했지만, 앞으로는 기본적으로 one 이라는 Toolchain 이 하나 등록된 상태에서 동작할테니 해당 값이 2가 되도록 수정해야 할것 같아요.
*.test.ts에서 관련된 부분을 저희가 수정해서 같이 올리면 될까요?
특히 아래와 같은 부분이요!
// Backend.test.ts
let backend = new BackendMockup();
registrationAPI.registerBackend(backend);
const entries = Object.entries(globalBackendMap);
assert.strictEqual(entries.length, 1);
// MockCompiler.ts
assert(count === 1, 'Count must be 1');
네, 연관 관계가 있어도 가독성을 위해서 별도로 올리셔도 되세요. ^^
@jyoungyun 안녕하세요 멘토님 2개의 파일을 나눠서 PR을 올린다고 가정할 때, 한 파일을 커밋 후 PR을 요청하고, 다음 파일에 대한 PR을 할 때에는, 커밋을 리셋한 후 다음 파일을 커밋 후 PR을 드리는게 맞을까요?
방식에 혼란이 있어 여쭤봅니다!!
- Dockerfile 커밋 후 PR
- 커밋 되돌리기
- onecc-docker 커밋
- PR
아, 1번은 이 PR 대로 commit 후 merge 가 되어야하구요 3번 역시 1번과 build 상에서는 현재로써는 이슈가 없을거라서 별개로 commit 올리시고 merge가 되면 될 것 같아요~~
4주차 질문&답변
Dockerizing
Q. test 를 위한 디렉토리를 만들어주셨는데, 테스트 범위에 대해 궁금합니다.
A. onecc-docker 에 대한 테스트만 추가하면 될 것 같아요.
onecc 자체는 이미 다른 테스트에서 검증이 되고 있으므로 onecc-docker 에서 onecc 옵션을 받아 전달해서 잘 실행되는지에 대한 테스트만 넣으면 되는데 테스트 환경에 onecc 가 설치되어있지 않을거여서 잘 전달되었는지를 어떻게 테스트할지 고민이 필요할 것 같아요.
onecc-docker 에 다른 파라미터들이 생기면 그에 대한 검증도 추가가 되어야 하구요.
Q. argparser 를 이용해서 onecc-docker 만의 argument 를 받으라고 하신 말씀에 질문이 있습니다. 만약 -a 라는 플래그를 이용해 -C onecc.template.cfg 라는 argument를 onecc 에 전달하려고 한다면, -C도 플래그로 받아들여서 에러가 납니다. onecc에만 적용되는 플래그들을 argparser에 추가해서 다시 onecc의 argument 로 추가하게 만드는 식으로 해결해야 할까요?
A. 아니오. :) onecc-docker 에서 onecc 와 겹치지 않는 플래그를 추가하고 parse_known_args 를 이용해 onecc-docker 에 대한 argument 만 처리하고 onecc 의 argument 들은 onecc 로 전달해주면 되요~~
예를 들어,
onecc-docker --token <token> -C a.cfg
사용자가 이런 명령어를 입력하게 된다면 token 은 onecc-docker 에서 처리하고 이 argument 를 제외한 나머지를 onecc 에 전달하는 식이에요.
Q. Dockerfile 의 위치를 어디에 두어야 할까요?
A. 구현할 때에는 ./compiler/onecc-docker/docker/Dockerfile 정도에 위치해 있을 것 같구요.
나중에 debian package 로 설치할때 /usr/share/one/docker/Dockerfile 에 설치하면 되세요.
docker build 할 때 파일 위치를 입력하여 이미지 생성이 가능해요.
설치되는 위치는 고정이므로 onecc-docker 스크립트에서 명시적으로 위치를 기술해 사용하시면 됩니다. :)
ONE-vscode
Q. ONEToolchain.test.ts 는 ONEToolchain.ts 작성한 것처럼 src/Tests/Backend/ONE/ONEToolchain.test.ts 경로에 생성하면 될까요?
A. 네 :)
Q. Backend.test.ts에서 지금 for문 안에서 assert 체크가 백엔드가 하나였을 상황을 가정하고 만든 것 같습니다. 그렇지만 ONE 이 추가되서 에러가 발생하는데, -if 문으로 분기
- bakcendNameList, backendList 배열을 만든 다음에, for문을 돌면서 배열이 일치하는지 확인하는 방법 다른 좋은 방안이 있을까요?
A. 지금 현재 올려주신 방법으로 테스트를 적용하면 되지 않을까요? onebackend 일 경우에는 continue 하면 될것 같아요. 이 파일은 one toolchian 을 검증하려는 것이 아니니까요. :)
Q. ToolchainProvider.test.ts 파일에서 #setDefaultToolchain 과 #uninstall 수정을 했습니다. 그 과정에서 명확하지 않은 부분이 있어서 질문을 드립니다.
- test code 에서 toolchain 이 ONE 이었다가 new toolchian 으로 default toolchain 을 설정하는 것을 가정하나요?
- 아니면 ONE 을 default toolchain 으로 설정하는 것을 가정하나요?
A. 코드를 보면 bnodes[1] (dummy_backend) 에서 정의한 노드를 default toolchain 으로 설정하고 동일한 값이 설정되었는지 체크하는 부분입니다. 이 과정에서 toolchain 이 ONE 이었다가 새로운 툴체인으로 설정하는 내용은 들어가 있지 않습니다.
default toolchain 은 단순히 backend 만을 default 로 지정하는 것이 아니라 backend 에서 getInstalledToolchain 으로 반환한 toolchain 들 중에 특정 하나만을 default toolchain 으로 지정하는 것입니다. backend 와 관련된 내용은 아니어서 문제가 될 부분은 없어 보입니다. :)
Q. ToolchainProvider.test.ts 파일에서 #setDefaultToolchain 과 #uninstall 수정을 햇습니다. 그 과정에서 명확하지 않은 부분이 있어서 질문을 드립니다.
- uninstall 에서도 ONE 이 아닌 새 Toolchain 을 삭제하는 걸까요? 아니면 ONE 도 삭제하는 과정을 넣어야할까요?
A. 현재까지 구현을 봤을 때 ONE 은 toolchain 이 아니라 Backend 에요. 코드를 보면 backend 자체를 uninstall 하는 것이 아니라 backend 에 있는 toolchain node 를 uninstall 하는 거에요. 그런데 사실 테스트 코드에서 install 과 uninstall 은 정상적으로 테스트가 어려워 실행이 되었는지 정도만 판단하고 있어요. toolchain node 자체에 대한 테스트여서 현재까지 여러분들이 구현하신 Backend 부분과는 연관성이 없습니다. :)
onecc-docker 와 Dockerfile 설치와 관련해서 수정된 내용이 있어 업데이트해요~
onecc-docker 파일이 /usr/bin 에 설치되어야 한다고 했는데, /usr/share/one/bin/ 에 설치가 먼저 되고 /usr/bin/onecc-docker 로 link 해야해요~~~
실제 사용자 시스템에 설치할 때에는 debian 에서 설치하기 때문에 실제 구현되는 코드 위치랑은 관련이 없습니다. :)
/cc @Samsung/ootpg_docker
참고로 제가 생각하고 있는 onecc-docker 의 디렉토리 구조는 아래와 같아요.
onecc-docker/
docker/Dockerfile
onecc-docker
debian/
control
onecc-docker.install
onecc-docker.links
rules
changelog
copyright
혹시 제가 놓친 부분이 있거나 다른 의견이 있으시면 알려주세요 :)
from https://github.com/Samsung/ONE/pull/9753#discussion_r976158031
위 내용 관련해서 @seanshpark @mhs4670go 님과 오프라인으로 얘기한 내용 공유드립니다.
onecc-docker debian pkg 는 one compiler project 의 일환이기 때문에 one compiler 빌드시 debian pkg 가 생성되어야 합니다. 이를 위해서는 ./infra/debian/one-compiler 내에 내용이 추가되어야 합니다. 하지만 지금은 onecc-docker 를 개발하는 단계이고, one-vscode 에서 onecc-docker debian pkg 를 사용하기 위해서는 lauchpad 에 업로드 하는 등의 과정이 필요하지만 현재 one compiler 는 lanuchpad 업로드를 지원하지 않습니다. 따라서 개발 편의를 위해 임시로 ./onecc-docker 디렉토리 내에서 debian 디렉토리를 생성하기로 하였습니다. 다만 이는 임시로 구성하는 것이므로 이에 대한 내용을 readme 에 추가하고자 합니다.
처음 계획과 같이 debian directory 는 onecc-docker 아래에 위치하게 구현해주세요. 또한 이와 관련된 내용을 README 에 추가해주세요.
https://github.com/Samsung/ONE/pull/9753#discussion_r976256994
이상입니다. :)