Toolbox: coretoolbox와 병합할지 여부

우리는 오늘 Fedora CoreOS 회의 에서 이에 대해 논의했습니다.

  * AGREED: regarding golang vs rust that is up to the author of
    toolbox. we do care about size and exploding the number of
    container-runtime implementations. If Golang is chosen we prefer
    that we don't vendor libpod, but rather either shell out or use the
    varlink API to manage containers.  (dustymabe, 17:33:38)

그래서 @debarshiray @cgwalters 는 조사할 주제를 말하는 것으로 충분합니다.

1. debarshiray/toolbox 프로젝트는 도구 상자의 크기를 부풀리지 않도록 libpod를 판매하지 않아도 괜찮습니까(예: 셸 아웃하거나 varlink 사용)?
2. 1번 항목에 대한 합의를 얻을 수 있다면 @cgwalters 는 rust 또는 golang이 충분한 도구라는 데 동의합니까(개인 "선호도" 무시)

1번 항목에 대한 합의를 얻을 수 있다면 @cgwalters 는 rust 또는 golang이 충분한 도구라는 데 동의합니까(개인 "선호도" 무시)

네, 물론입니다.

1. will the debarshiray/toolbox project be ok with not vendoring libpod

(즉, 쉘 아웃하거나 varlink를 사용하여) 도구 상자의 크기를 부풀리지 않도록 하시겠습니까?

libpod 의 벤더링에서 부풀려진 크기가 CoreOS의 거래 차단기이기 때문에 래퍼 Go 바이너리에서 Podman으로 쉘 아웃하게 되어 기쁩니다.

libpod의 벤더링에서 부풀려진 크기가 CoreOS의 거래 차단기이기 때문에 래퍼 Go 바이너리에서 Podman으로 쉘 아웃하게 되어 기쁩니다.

다시 작성하는 경우 기존 Rust 구현을 사용하지 않는 이유는 무엇입니까? 이것이 중요한 점입니다. 저는 이미 적극적으로 사용하는 작업 코드를 가지고 있습니다.

Rust BTW의 좋은 점은 업스트림 varlink 항목에 훌륭한 Rust 코드가 많이 있다는 것입니다. varlink-go도 존재합니다.

다시 작성하는 경우 기존 Rust 구현을 사용하지 않는 이유는 무엇입니까? 이것이 중요한 점입니다. 저는 이미 적극적으로 사용하는 작업 코드를 가지고 있습니다.

이것을 더 구체화하기 위해 제안이 있습니다. debarshiray/toolbox를 coreos/toolbox로 이동한 다음 대부분의 코드를 cgwalters/coretoolbox로 바꾸는 커밋을 가집니다. @debarshiray 는 CoreOS 그룹의 다른 사람들과 함께 공동 유지 관리자가 됩니다. (또는 fedora-silverblue/ GH org로 이동할 수 있습니다. 현재 더 많이 연관되어 있기 때문입니다. 그러나 우리는 더 coreos/인 호스트 루트 사례도 캡처하고 싶습니다.)

나는 coretoolbox 를 사방에 밀어붙이려는 이 끊임없는 수동적 공격적 어조와 이 프로젝트를 인수하려는 것처럼 보이는 행동에 지쳤습니다.

중지하십시오!

우리가 최근에 이것에 대해 몇 번이나 이야기했는지, 그리고 당신의 이상하게 회피적이고 공격적인 행동을 고려할 때 더 이상 잘 추측할 수 없습니다.

Toolbox 프로젝트가 존재하는 이유는 Silverblue가 개발자에게 자체 개발 환경을 설정할 수 있는 방법을 절대적으로 필요했기 때문입니다. Silverblue에서 작업하는 우리 중 일부는 Podman 팀의 많은 도움을 받아 우리에게 필요한 것을 제공하는 루트 없는 Podman을 사용하여 무언가를 해킹했습니다. 이 노력의 큰 부분은 루트가 없는 Podman이 작동하도록 하는 것이었습니다. Silverblue 사용자에게 이제 쉘을 얻으려면 갑자기 루트가 되어야 한다고 말할 수 없기 때문입니다.

coretoolbox 가 2019년 4월에야 나타났기 때문에 당신은 아마 현실을 알지 못할 것입니다. 그때까지 많은 주요 난기류가 가라앉았습니다. 그러나 뿌리 없는 Podman이 거의 존재하지 않았던 2018년 여름, 상황은 매우 폭풍우였습니다.

쉘 스크립트에 대해 원하는 것을 말하십시오. 스크립트를 공유하고 상대방이 이를 조정하고 실행할 수 있기를 기대하는 것은 매우 쉽습니다. 그리고 개발 워크플로가 주로 임의의 Podman 주문을 던지고 무엇이 붙고 무엇이 붙지 않는지, 왜 그렇지 않은지 확인하는 것과 관련되어 있을 때 이러한 용이함은 진행을 위해 절대적으로 중요합니다. 임의의 사람에게 Rust나 Go 또는 기타 코드를 가져와서 몇 분 안에 시도해 볼 수 있도록 요청할 수 있는 방법은 없습니다. 많은 사람들이 빌드 방법을 모르는 것을 주저할 것이고 올바른 Podman 빌드나 일부 구성 수정 등을 통해 손을 잡고 있는 지점에 도달하는 것을 잊어버릴 수 있습니다.

또한 CoreOS 팀에서 실제 피드백을 본 적이 없음을 지적합니다. 절대.

지난 1년 동안 저는 여러 IRC 회의에 참석했고 실생활에서 다양한 사람들과 이야기를 나눴습니다. 제가 들은 것은 기본적으로 예, 그렇습니다. 우리는 Toolbox를 사랑하고 CoreOS에서 작동하도록 패치를 보낼 것 입니다. 그 외에는 패치를 한 번도 본 적이 없습니다.

첫 번째 실제 피드백은 올해 7월 8일에 도구 상자 RPM에 의해 끌어온 부풀려진 종속성 에 대한 것이었습니다. 제가 추적하여 수정했습니다.

한편 Silverblue 팀은 Podman 개발을 지속적으로 추적하고, 지원되는 모든 분기에서 Podman 릴리스를 테스트하고, 자동화된 테스트를 개선하고, 어려운 마이그레이션을 차례로 통과하는 작업으로 바빴습니다. 목록은 계속됩니다.

작동하는 코드가 있다고 생각하십니까? 문서가 있습니까? 시험 이 있습니까?

아, 그리고 사용자가 몇 명입니까? 일부 오래된 컨테이너가 더 이상 새 도구와 함께 작동하지 않는 이유를 알아보기 위해 얼마나 많은 사용자가 야생에서 손을 잡고 있습니까? GNOME에서 OCI 런타임까지 스택을 위아래로 얼마나 많은 회귀를 추적했습니까?

실제로 Toolbox를 사용하는 많은 실제 최종 사용자가 있습니다. 그냥 일어나서 갑자기 모든 것을 바꿀 수는 없습니다. Fedora 31 에서 절대적으로 그리고 시급하게 해결해야 하는 Cgroups v2 버그가 많이 있습니다.

Toolbox가 여전히 POSIX 셸로 작성된 이유가 궁금하십니까? 당신의 대답이 있습니다 - 우리는 바빴습니다.

Silverblue 사용자는 일반적으로 운영 체제의 작동 방식이나 컨테이너 기술의 내부 및 외부를 알아야 할 필요가 없습니다. 그들은 toolbox enter 를 실행하고 쉘을 얻을 것으로 예상합니다. 그들은 껍질을 얻지 못하고 손을 들고 불평합니다.

레거시 Workstation과 비교하여 Silverblue를 사용하는 데 있어 모든 임의의 장애물은 채택의 장애물입니다.

Toolbox가 얼마나 중요한지 아십니까? 날 믿어, 우리는 알고있다. Silverblue의 경우 Toolbox는 Bash만큼 중요합니다.

또한 CoreOS의 구체적인 사양 목록도 본 적이 없습니다. https://github.com/coreos/fedora-coreos-tracker/issues/38 이 어려운 요구 사항을 지정하지 않고 한 세부 사항에서 다른 세부 사항으로 구불구불한 것은 당연합니다.

https://fedoraproject.org/wiki/Workstation/Desktop_Containers 와 비교하십시오.

Toolbox가 Silverblue에 얼마나 중요한지, 아마도 CoreOS보다 훨씬 더 중요할 수 있다는 것은 꽤 분명하다고 생각합니다.

libpod 공급업체와 함께 Go에서 작성하는 것과 같이 CoreOS에 근본적으로 문제가 있는 방향으로 Toolbox를 쉽게 사용할 수 있었지만 그렇게 하지 않았습니까? 당신이 할 수 있는 모든 것이 당신의 실제 필요가 무엇인지 지정하지 않고 Rust 팬보이즘일 때조차도.

우리는 또한 한 손가락을 떼지 않고도 완전한 어트리뷰션을 제공하는 coretoolbox에서 많은 흥미로운 아이디어를 흡수 했습니다.

먼저 감사 의 마음을 전하는 법을 배워보는 건 어떨까요?

툴박스의 향후 방향은...

Toolbox는 Go에서 다시 작성됩니다. Podman을 포함한 OCI 생태계의 나머지 부분이 작성된 언어입니다. Podman 스택을 건드리지 않고 Toolbox에서 작업하는 것과 같은 것은 없습니다. 가능한 한 일치 상태를 유지하는 것이 우리의 최선의 이익입니다. 기여자들에게 Toolbox에서 작업하려면 Rust와 Go에 대한 지식이 있어야 한다고 말하는 것은 불필요한 장애물이 될 것입니다.

피할 수만 있다면 Varlink를 사용하고 싶지 않습니다. 그것은 우리가 현재 Silverblue에서 전혀 사용하지 않는 것이지만, Podman 팀은 그것에 대해 별로 만족하지 않으며, 그럼에도 불구하고 근본적으로 새로운 기술을 매우 중요한 것의 한가운데에 두는 것은 위험할 것입니다. Podman을 가능한 한 강력하게 만드는 데 노력을 집중하고 싶습니다.

libpod 대 podman 에 관해서 는 CoreOS 회의 에서 논의한 것처럼 /usr/bin/toolbox 를 가능한 한 작게 유지하기 위해 후자를 고수할 것입니다.

저는 개인적으로 CoreOS가 Toolbox를 사용하는 것을 보게 되어 기쁩니다. 계속해서 CoreOS의 요구 사항에 최대한 귀를 기울이고 수용할 것입니다. 물론 기여를 환영합니다. CoreOS가 어떤 이유로든 Toolbox를 사용하지 않기로 결정한 경우에도 나는 당신을 원망하지 않을 것입니다.

그러나 나는 이 프로젝트를 막연하고 막연한 이유로 다른 곳으로 옮기지 않을 것입니다. 또는 인터넷의 누군가가 뿌리 없는 Podman이 물건이라는 것을 발견했기 때문입니다. 모든 지루한 어려움을 처리하기 위해 매일 나타나는 사람들이 결정합니다.

폐쇄.

먼저 감사의 마음을 전하는 법을 배워보는 건 어떨까요?

감사합니다!

우리가 최근에 이것에 대해 몇 번이나 이야기했고, 당신의 이상하게 회피적이고 공격적인 행동을 감안할 때 더 이상 잘 추측할 수 없습니다.

흠, 바꾸자! 회피형이 뭔지 모르겠네요. 당신이 공격성을 인식해서 유감입니다. 나는 확실히 종종 기술적인 견해를 강하게 주장했지만, 아무 것도 개인적으로 받아들이지 마십시오. 가장 중요한 것은; 계속 이런 대화를 나누는 이유는 함께 일하고 싶기 때문입니다!

나는 coretoolbox를 사방으로 밀어붙이려는 이 끊임없는 수동적 공격적인 어조와 이 프로젝트를 인수하려는 것처럼 보이는 행동에 지쳤습니다.

아, 하지만 우리는 여기서 꽤 중요한 것에 대해 이야기하고 있습니다. 나는 당신이 한 모든 일에 절대적으로 감사합니다. 그러나 우리는 기술적인 불일치가 있습니다.

분명히 말하겠습니다. 저는 개인적으로 이 프로젝트의 미래 방향에 대해 더 많은 통제권을 갖고 싶습니다. 그것은 완전한 통제와 동일하지 않습니다. 나는 "거친 합의와 작업 코드"를 믿습니다. 함께 할 수 있을 것 같아요! 당신과 나는 서로를 알고 있습니다. 당신이 동의하기를 바랍니다.

아시다시피 coretoolbox는 패치를 제공하려고 했지만 병합되지 않았기 때문에 시작되었습니다. 그러니 명심하자! 먼저 쉘 스크립트를 해킹 해 보았습니다.

아, 그리고 사용자가 몇 명입니까?

아, 많지 않습니다. 그러나 예를 들어 이 댓글이 있습니다.

당신이 할 수 있는 모든 것이 당신의 실제 필요가 무엇인지 지정하지 않고 Rust 팬보이즘일 때조차도.

흠, 이제는 불필요합니다. 우리는 이미 옵션 파싱, 설정 파일, 정상적인 오류 처리 등과 같은 실제 언어를 사용하는 이유에 대해 살펴보았습니다. 제가 또한 Rust를 좋아한다는 것은 사실입니다 :wink:

그러나 나는 이 프로젝트를 막연하고 막연한 이유로 다른 곳으로 옮기지 않을 것입니다. 또는 인터넷의 누군가가 뿌리 없는 Podman이 물건이라는 것을 발견했기 때문입니다. 모든 지루한 어려움을 처리하기 위해 매일 나타나는 사람들이 결정합니다.

여기 또 다른 방법이 있습니다. 다시 한 번, 중요도를 고려할 때 프로젝트는 귀하와 귀하의 github 개인 도메인이 아닌 유지 관리로 옮겨야 한다고 생각합니다. 나는 절대적으로 그러한 프로젝트에 기여하고 싶습니다.

Toolbox는 Go에서 다시 작성됩니다. Podman을 포함한 OCI 생태계의 나머지 부분이 작성된 언어입니다. Podman 스택을 건드리지 않고 Toolbox에서 작업하는 것과 같은 것은 없습니다. 가능한 한 일치 상태를 유지하는 것이 우리의 최선의 이익입니다. 기여자들에게 Toolbox에서 작업하려면 Rust와 Go에 대한 지식이 있어야 한다고 말하는 것은 불필요한 장애물이 될 것입니다.

그래서 이것은 분명히 우리가 계속 막히게 된 부분입니다. 그러나 언어 문제는 유지 관리 이후에 와야 한다고 생각합니다. 이 프로젝트가 귀하의 개인 GH에 남아 있다고 보십니까, 아니면 coreos/GH org 또는 fedora-silverblue/GH org로 이동하고 여러 관리자가 있는 것으로 보십니까?

FCOS aws ami(v31.20200223.3.0)에서 도구 상자를 실행하는 가장 좋은 방법은 무엇입니까?

도구 상자를 실행하려고했지만 작동하지 않습니다

toolbox create
toolbox: TOOLBOX_PATH not set

TOOLBOX_PATH=/usr/bin/toolbox toolbox create
toolbox: this is not a toolbox container