Toolbox: coreos/toolbox와의 정렬/비교

이 문제를 제기하는 첫 번째 동기는 https://pagure.io/workstation-ostree-config/pull-request/106입니다 . "기본 이미지"에 무언가를 추가하는 것은 상당히 장기적인 지원을 의미합니다.

새로운 coreos-toolbox에 대한 약간의 배경 지식: 이는 모든 권한을 가진 매우 간단한 관리/디버그 컨테이너로 설계되었으며, 기본적으로 이전 버전(CL용)의 포트이지만 RHCOS/FCOS 시스템용입니다. 그런 의미에서 범위는 훨씬 작습니다.

여기에서 제가 가지고 있는 한 가지 광범위한 관심사는 프로젝트의 바로 그 이름입니다. 페도라에서
우리는 내부에 "Fedora" 브랜딩의 대부분을 갖기 위해 많은 노력을 기울입니다.
fedora-release , generic-release 있습니다.

(tl;dr: 다운스트림 불가지론적 이름으로 전환하게 되어 기쁩니다.)

글쎄, 이것은 특정 Fedora 릴리스를 정의하는 약간의 상표, 구성, 이름 및 버전 번호에 관한 것이 아닙니다. fedora 접두사가 붙은 여러 도구와 fedpkg 가 있는 fedora-packager 와 비슷 합니다.

도구 상자 컨테이너는 일반적인 개념이지만 업스트림 기술(예: Buildah, Podman)과 다운스트림 소비자(예: Fedora Silverblue)가 혼합되어 고유하게 "Fedora"가 됩니다. 예를 들어 데비안에서 이미 작동할 수 있지만 테스트하지 않았으며 도구가 존재하는 주된 이유도 아닙니다. 적어도 오늘은 그것이 나의 우선순위가 아니다.

따라서 fedora 접두사.

즉, fedora 접두사가 문제가 있는 것으로 간주되면 다운스트림에서 완전히 분리된 이름을 사용하게 되어 기쁩니다.

이것은 전체 데스크톱 로그인을 가정하고 루트가 아닌 사용자로 실행되는 것으로 보입니다.
여기서 coreos-toolbox는 대신 사용자가 실행 중이라고 가정합니다.
콘솔에서 루트로, 전체 시스템 전체 권한이 있어야 합니다.

(tl;dr: CoreOS의 요구 사항을 알고 있으며 기꺼이 해결해 드립니다.)

우리가 Silverblue용 도구 상자와 우리에게 필요한 것이 무엇인지 작업하고 있다는 것은 사실 비밀이 아니었습니다. :)

#fedora-coreos , #fedora-containers , fedora-coreos-tracker 등에서

Fedora CoreOS의 요구 사항이 Silverblue의 요구 사항과 다르다는 것을 알고 있습니다. 내 인상은 우리가 두 가지 맛에 대해 가능한 한 많은 도구 상자를 공유하게 되어 기쁩니다. 다만, 초기 논의 이후 CoreOS 팀으로부터 아무런 소식을 듣지 못했고, 현재 계획이나 우선순위가 무엇인지도 모릅니다. 바로 며칠 전에 fedora-toolbox 의 현재 상태에 대한 몇 가지 의견을 삭제했지만 업데이트 내용을 듣지 못했습니다.

한편, 실버블루 랜드에서는 툴박스가 상당히 중요합니다. 그렇지 않으면 Silverblue를 개발 환경으로 사용할 수 없으며 Silverblue를 실행하는 빛나는 XPS 13을 가능한 한 많이 사용하고 싶습니다. :) 그래서 우리는 이름을 선택하고 앞으로 나아가야 했습니다.

내 2c는 프로젝트 이름으로 "coreos-toolbox"라고 부르지만 그냥 "toolbox"입니다.
Fedora/CoreOS 컨텍스트에서 논의할 때 암시적으로.

앞서 언급했듯이 fedora-toolbox 는 coreos/toolbox 에서 느슨하게 영감을 coreos/toolbox 에는 root 했고 다른 기술 스택을 사용했기 때문입니다.

내가 원래 리포지토리를 포크하지 않고 계속 사용하지 않은 이유 중 하나는 거기에 있는 거버넌스 및 프로세스 관련 비트로 무엇을 해야 할지 확신이 없었기 때문입니다. 행동 강령, 기여 가이드라인 등이 중요하지만 이것이 Fedora 배너 아래에서 일어나고 있음을 분명히 하고 싶었습니다. Fedora 배너가 어떻게 생겼는지 정확히 알지 못하기 때문에 커밋에 이러한 비트를 git rm 포함하고 싶지 않았으며 사람들을 가리킬 Git 저장소가 절실히 필요했습니다. 나는 사람들에게 몇 주 동안 수동으로 업데이트된 tarball을 가리키고 있었습니다. :)

둘째, 기본 도구가 완전히 다르기 때문에 스크립트를 다시 작성해야 했습니다. 따라서 나는 Git 기록을 보존하는 것에 대해 너무 걱정하지 않았습니다.

나는 Debarshi가 여기서 말한 모든 것에 동의합니다.

나는 이것을 '일반화'하는 데 많은 가치가 있다고 생각하지 않습니다. 기성품 페도라 도구 컨테이너에 대한 액세스 권한을 부여하는 것이므로 fedora-toolbox라고 부르는 것이 당연하고 자연스러운 것 같습니다.

fwiw, 이것은 약간의 접선이지만 "도구 상자"라는 이름이 이상합니다. 도구 상자는 내부에서 작업하는 것이 아니라 도구를 꺼내는 것입니다. 개인적으로 workbox나 뭐 이런거였으면 좋겠습니다.

fwiw, 이것은 약간의 접선이지만 "도구 상자"라는 이름이 이상합니다.

(흠, 그래서 fedora 와 toolbox 놓으면 프로젝트는 - :wink: 라고 할 수 있습니다.)

(tl;dr: CoreOS의 요구 사항을 알고 있으며 기꺼이 해결해 드립니다.)
우리가 Silverblue용 도구 상자와 우리에게 필요한 것이 무엇인지 작업하고 있다는 것은 사실 비밀이 아니었습니다. :)

예, 토론이 있었다고 들었습니다. 죄송합니다. Silverblue PR을 보고 이제서야 이 토론으로 돌아가게 된 것입니다.

한편, 실버블루 랜드에서는 툴박스가 상당히 중요합니다.

동의합니다. 지금은 이에 대한 나만의 사용자 지정 스크립트를 사용하는 것이 차단된 것 같지는 않지만, 즉시 사용할 수 있는 독창적인 솔루션도 필요하다고 생각합니다.

이제 저는 이 의견에 동의합니다.
https://github.com/coreos/fedora-coreos-tracker/issues/38#issuecomment -417714930

기성품 페도라 도구 컨테이너에 대한 액세스 권한을 부여하는 것이므로 fedora-toolbox라고 부르는 것이 당연하고 자연스러운 것 같습니다.

그래서 저는 Red Hat CoreOS에서 일하고 있습니다. 그리고...저희가 도구를 출시할 때 Fedora 사용자 공간이 기본적으로 설정되어야 하는지 확신이 서지 않습니다. 그것에는 많은 의미가 있습니다. 일부는 좋고 일부는 나쁩니다.

이제 특히 명령줄에 대해 이야기할 때 Fedora 는 패키지이며 특히 Fedora 사용자 공간에 기본값을 제공하므로 "fedora-toolbox"라고 부르는 것이 합리적입니다. 하지만 여전히 브랜딩에 대한 우려가 있다고 말했습니다.

coreos-toolbox와 fedora-toolbox를 병합하고 "toolbox"라고 부르는 것으로 한 번에 두 가지 문제를 해결한다는 아이디어는 매력적입니다.

물론, 두 가지를 병합하는 것은 매우 의미가 있습니다. 그래서 우리는 앞서 논의하기 위해 손을 뻗었습니다. 이름이 문제라면 "워크샵" 같은 것은 도구 상자를 보관하고 작업을 수행하는 장소로 어떻습니까?

한편, 실버블루 랜드에서는 툴박스가 상당히 중요합니다.

동의합니다. 비록 지금은 나만의 커스텀이 있다는 것이 차단된 것 같지는 않지만
이에 대한 스크립트를 작성하려면 기본적으로 의견을 제시해야 한다고 생각합니다.
솔루션도.

글쎄요, 당신은 컨테이너와 최신 그래픽 OS에 정통한 아주 특별한 사람들 중 한 명입니다. 불행한 인간은 디스플레이 서버 소켓의 누수 등과 같은 작은 문제로 어려움을 겪는 것으로 알려져 있습니다. :)

이제 저는 이 의견에 동의합니다.
coreos/fedora-coreos-tracker#38(댓글)

네, 저도 더스티의 아이디어가 좋습니다.

그러나 이 경우 문제 해결이 정확히 어떤 모습인지 모르겠습니다.

공정하게 말해서, 개발에 대한 나의 이해는 기본적으로 "배포에서 일부 도구를 설치하고 별도의 접두사에 빌드 및 설치하고 실행"하는 "jhbuild 스타일 개발을 수행할 수 있어야 함"으로 치우쳐 있습니다. 다른 워크플로와 개발 설정을 가진 사람들이 사용해 보고 피드백을 주시면 정말 감사하겠습니다.

그래서 저는 Red Hat CoreOS에서 작업하고...우리가 언제
도구는 기본적으로 Fedora 사용자 공간으로 설정되어야 합니다. 시사하는 바가 많다
그것에 - 어떤 좋은, 어떤 나쁜.

이것은 fedpkg 및 rhpkg 와 약간 비슷합니다. 그러나 나는 그 두 사람이 어떻게 자신의 정체성을 주장하는지 연구하지 않았습니다.

내 가정은 Fedora CoreOS/Silverblue와 Red Hat CoreOS/Silverblue가 Fedora와 RHEL 간의 일반적인 관계를 공유할 것이라는 것이었습니다. 인정하는 바에 따르면 Red Hat CoreOS는 아마도 매우 현실적일 것이고 Red Hat Silverblue는 아마도 단순한 vapourware일 것입니다. :)

이제 특히 명령줄에 대해 이야기할 때 Fedora _is_
패키지 및 특히 Fedora 사용자 공간에 기본값을 부여하여 호출합니다.
"fedora-toolbox"는 의미가 있습니다. 그러나 그것은 내가 여전히
브랜딩.

네 이해했습니다. 제 운영 원칙은 도구 상자를 사용하여 친숙한 RPM 기반 환경을 모방하는 것이었습니다. 따라서 Fedora 도구 상자에는 Fedora RPM이 있고 RHEL 도구 상자에는 RHEL RPM이 있어야 합니다. 최소한 기본적으로는 항상 플래그를 조작하고 RHEL에 Fedora 도구 상자를 만들거나 만들 수 없기 때문입니다. 도구 상자의 기본값이 호스트의 VERSION_ID 것처럼.

저는 Silverblue에서 일하고 있고 Fedora Silverblue는 실제이지만 Red Hat Silverblue에 대해서는 들어본 적이 없습니다. 따라서 Fedora의 모든 것에 대한 편견은 단순함을 유지하고 공을 굴리려는 욕망에서 비롯됩니다. 기본적으로 RHEL 사용자에게 Fedora 콘텐츠를 적용하고 싶지는 않습니다.

coreos-toolbox와
fedora-toolbox를 사용하고 "toolbox"라고 부르기 때문에 많은 매력을 가지고 있습니다.

예, 단지 toolbox (또는 workshop )가 제게는 괜찮게 들립니다. Git 저장소, RPM 패키지 등의 이름도 바꾸겠습니까? 아니면 그냥 스크립트 이름을 바꿀까요?

글로벌 네임스페이스에서 한 자리를 차지하기가 두렵습니다. 특히 Git 저장소의 경우 toolbox 가 일반적인 이름이기 때문입니다.

그래서 이 프로그램의 범위는 페도라에서 작업하는 사람들만을 위한 것이 아닙니다. 그렇죠? 완전히 관련 없는 작업을 수행하기 위해 우연히 fedora를 사용하는 사람들을 위한 것입니다. fedpkg는 페도라용 프로그램을 패키징하는 사람들을 위한 것입니다. 사용자를 위한 것이 아니라 우리를 위한 것입니다. 이 프로그램은 사용자를 위한 것입니다.

따라서 이 프로그램의 범위는
페도라 맞죠? 주로 페도라를 사용하는 사람들을 위한 것입니다.
완전히 관련 없는 작업을 완료합니다. fedpkg는 사람들을 위한 것입니다.
페도라를 위한 패키징 프로그램. 사용자를 위한 것이 아니라 우리를 위한 것입니다.
이 프로그램은 사용자를 위한 것입니다.

네, 맞습니다.

그러나 적어도 당분간은 모든 단일 배포판에서 이 작업을 수행하는 데 중점을 두지 않습니다. 그리고 일부 구성(예: OCI 이미지 레지스트리의 URL, 기본 이미지의 이름 등)은 Fedora와 RHEL 간에 변경될 수 있습니다.

다른 문제에서(coreos 대 silverblue 관련):

예, #fedora-coreos에서 채팅하는 동안 차이점을 확인했지만 여전히 가능한 한 많이 공유하고 싶었습니다.

그래, 난 동의. 초기 논의를 잘못 해석한 점 사과드립니다. coreos 사용 사례가 훨씬 작았기 때문에 기존 파이프라인에 구축할 매우 간단한 도구 상자를 만들기로 결정했습니다. 앞으로 두 가지를 통합하는 것이 확실히 의미가 있다고 생각합니다.

그러나 이 경우 문제 해결이 정확히 어떤 모습인지 모르겠습니다.

그래서 저는 RHCOS가 원래 도구 상자를 사용하기 위해 구상한 용도에 대해서만 말할 수 있습니다. 본질적으로 openshift 클러스터의 실패한 호스트 내부에서 디버그 도구를 실행합니다. 그런 의미에서 toolbox 명령은 호스트 fs를 마운트할 수 있는 권한 있는 컨테이너만 실행하면 됩니다.

따라서 Fedora 도구 상자에는 Fedora RPM이 있고 RHEL 도구 상자에는 RHEL RPM이 있어야 합니다.

또는 fedora 도구 상자는 기본적으로 fedora 이미지를 실행할 수 있으며 rhel 이미지를 기본으로 하는 rhel 도구 상자도 작동할까요?

예, 도구 상자(또는 작업장)만 있으면 괜찮습니다.

coreos 관점에서의 주요 이유는 그 CL의 선택 이름이었다이다 : https://github.com/coreos/toolbox 내가 이름에 대해 어떤 강한 감정 중 하나 방법이 없습니다.

나는 이번 주 @debarshiray의 도구 상자 coreos 시스템에서 시도하고 호환성 문제가 있는지 확인할 수 있습니다. 다시 한 번, 후속 조치가 없는 점에 대해 사과드리며, 통합을 위해 노력해주셔서 감사합니다!

안녕,

그러나 적어도 당분간은 모든 단일 배포판에서 이 작업을 수행하는 데 중점을 두지 않습니다. 그리고 일부 구성(예: OCI 이미지 레지스트리의 URL, 기본 이미지의 이름 등)은 Fedora와 RHEL 간에 변경될 수 있습니다.

좋아, 내 생각은 그것이 이름에 fedora를 포함할 만큼 충분히 강력한 이유가 아니라는 것입니다. 기본 시작 페이지가 start.fedoraproject.org이기 때문에 우리는 firefox를 fedora-firefox라고 부르지 않습니다. 배포판은 소프트웨어의 배포판 사용자 지정을 수행할 것으로 예상됩니다.

다른 배포판에서도 작동하지 않는다면 큰 문제는 아니라고 생각합니다. 내 말은, 그들이 가치를 본다면 그것은 다른 배포판의 책임이라는 뜻입니다. 물론 명시적으로 페도라여야 하는 경우라면 이야기가 다릅니다.

나는 이번 주 @debarshiray의 도구 상자 coreos 시스템에서 시도하고 호환성 문제가 있는지 확인할 수 있습니다.

@yuqi-zhang 감사합니다!

몇 가지 초기 질문:

1. RHCOS 시스템에는 기본적으로 buildah가 없습니다. 이미지 생성과 컨테이너 생성을 기능적으로 분리하는 것이 더 나을 수 있습니까?
2. 설명자에 익숙하지 않습니다. 2>&42 는 오류를 어디로 파이프합니까? RHCOS 시스템에서 42: Bad file descriptor 오류가 발생합니까? 아니면 이것을 잘못 사용하고 있습니까?
3. 컨테이너를 생성하고 podman을 통해 볼 수 있음에도 불구하고 컨테이너가 존재하지 않는다고 주장하는 오류로 시작되지 않고 오류가 발생합니다. 일부 플래그가 문제를 일으키기 때문일 수 있으므로 더 자세히 조사하겠습니다.
4. 동적 마운트를 허용하는 것이 좋은 생각입니까? 아니면 일반 사용자 정의 환경 변수가 더 많거나 적습니까?

1. RHCOS 시스템에는 기본적으로 buildah가 없습니다. 하는 것이 더 좋을 수 있습니다.
   이미지 생성과 컨테이너 생성 사이에 분할이 있습니다.
   기능적으로?

물론이지.

buildah 로 로컬에서 생성된 사용자 정의 이미지는 각 사용자에게 특정한 부분을 채우기 위해 존재합니다. 예를 들어 호스트의 $USER와 일치하는 사용자를 생성합니다. 이러한 것들이 CoreOS에서 필요하지 않거나 다르게 수행될 수 있다면 중간 이미지는 필요하지 않습니다.

1. 설명자에 익숙하지 않습니다. 2>&42 파이프는 어디에 있습니까?
   에 오류? RHCOS 시스템에서는 42: Bad file descriptor 오류가 발생합니다.
   아니면 내가 이것을 잘못 사용하고 있습니까?

이것은 커밋 d7219ba512434315a3be0b4bcaa00b16cf7e478c에서 옵니다.

일반적으로 파일 설명자는 /dev/null 에서 42 포인트입니다. 당신이 통과하면 --verbose 플래그가를 가리키는 stderr . --verbose 를 구현하는 더 좋은 방법을 찾지 못했습니다. 아이디어 환영합니다.

하지만 CoreOS에서 작동하지 않는 이유가 궁금합니다.

1. 컨테이너가 시작되지 않고 존재하지 않는다고 주장하는 오류가 발생하더라도
   내가 만들었고 podman을 통해 볼 수 있지만. 이것은 아마도
   일부 플래그가 문제를 일으키고 있습니다. 더 자세히 조사하겠습니다.

흥미로운. 트리의 로컬 변경 사항이 있었습니까?

오랜만에 --sudo 툴박스를 시도하다가 다양한 podman 오류가 발생했습니다. fedora-toolbox --sudo create 작동했지만 sudo podman ps --all 및 fedora-toolbox --sudo enter 등이 다음과 같이 오류가 발생합니다.

[rishi<strong i="39">@bollard</strong> ~]$ fedora-toolbox --sudo create
[rishi<strong i="40">@bollard</strong> ~]$ sudo buildah images
IMAGE ID             IMAGE NAME                                               CREATED AT             SIZE
9ffedc39f7f2         registry.fedoraproject.org/f28/fedora-toolbox:28         Sep 26, 2018 18:07     602 MB
1b2c5602ac02         localhost/fedora-toolbox-rishi:28                        Nov 6, 2018 19:53      602 MB
[rishi<strong i="41">@bollard</strong> ~]$ sudo podman ps --all
error decoding container status for container dd1c6b885b53c712c177ce14ed23a63572802fd374d8086d1ddc9200e5a725f9: EOF
[rishi<strong i="42">@bollard</strong> ~]$ fedora-toolbox --sudo -v enter
unable to get container state: error decoding container status for container dd1c6b885b53c712c177ce14ed23a63572802fd374d8086d1ddc9200e5a725f9: EOF
/usr/bin/fedora-toolbox: failed to start container fedora-toolbox-rishi:28
[rishi<strong i="43">@bollard</strong> ~]$

나는 가지고있다:

[rishi<strong i="47">@bollard</strong> ~]$ rpm -q podman runc
podman-0.10.1.3-3.gitdb08685.fc28.x86_64
runc-1.0.0-57.dev.git9e5aa74.fc28.x86_64

보고해야 할 podman 버그인 것 같습니다.

1. 동적 마운트를 허용하는 것이 좋은 생각입니까? 또는
   일반적으로 사용자 정의 환경 변수가 더 많거나 적습니까?

음... 특정 사용 사례에 따라 다른 것 같은데요?

그렇다면 명명 문제에 대해 우리는 어디에 서 있습니까? toolbox 또는 workbox 가 전역 /usr/bin 네임스페이스에 넣을 정도로 일반적인 이름이 아니라고 생각하면 fedora 접두사를 삭제해도 됩니다.

아니면 당분간 fedora-toolbox 라는 이름을 삼키기로 선택했습니까?

나는 어느 쪽이든 강한 감정이 없으며 명명에 관해 더 경험이 많은 사람들에게 맡깁니다. 그러나 일반적인 "도구 상자" 이름이 대다수인 것처럼 보이는 것 같습니까?

답변이 늦어서 죄송합니다 저는 다음주까지 출장중입니다. 돌아올 때 위의 문제를 살펴보겠습니다.

나는 어느 쪽이든 강한 감정이 없으며 명명에 관해 더 경험이 많은 사람들에게 맡깁니다. 그러나 일반적인 "도구 상자" 이름이 대다수인 것처럼 보이는 것 같습니까?

toolbox 가) 적합합니다.

toolbox 이(가) 대다수의 인기를 얻었다고 생각한다는 사실에 놀랐습니다. - 에 대한 @cgwalters의 아이디어에 합의가 명확하게 정착

이름 변경 서류 작업을 시작했습니다. 0.0.5 릴리스가 막 나왔고 Fedora의 업데이트 테스트 저장소에 남아 있기 때문에 지금이 가장 좋은 시기입니다.

이 Git 리포지토리 자체의 이름이 이제 toolbox 로 변경되었습니다.

다음으로 저장소 내부의 다양한 부분(소스, 빌드 시스템 등)의 이름을 바꿀 것입니다. 그런 다음 새 tarball을 실행하고 Fedora 패키징 프로세스를 거치는 문제입니다.

이 Git 저장소의 내용은 #52에서 이름이 변경되었습니다.

남은 것은 새로운 타르볼과 다운스트림 패키징을 출시하는 것뿐입니다. 0.0.5 릴리스가 다음 릴리스를 롤링하기 전에 안정적인 업데이트 저장소에 도달할 수 있도록 조금 기다리고 싶습니다.

폐쇄.