Please comment there:
https://github.com/rpm-software-management/mock/issues/331
Copy of Comment #0: This is Request For Comments.
When systemd-nspawn has been added to mock, it brought a lot of bugs. For the transition period we introduced --old-chroot and --new-chroot. The intent was to steer toward the new chroot as mock running containers is more secure and everything. And maybe one day allow choosing between nspawn, docker, podman and others.
But the world went another way. When people are interested in containers, they usually do not want mock to run a container, but they run mock inside of a container. When mock is running inside of container then there is no need for additional isolation and no one really wants to run another container inside of a container. Therefore the --old-chroot is a good choice when you run inside of a container.
My intention is to keep --old-chroot indefinitely and actually recommend it when mock is running in a container. And maybe later automatically choose old or new one depending on if mock is running in a container or on bare metal.
In this situation, the names old/new are quite misleading. As it hints that you should rather use the new stuff rather than the old ones.
Therefore I want to rename (in fact, make alias) for those command-line options.
--old-chroot -> --simple-chroot --new-chroot -> --container-chroot ??? I want to avoid confusion here whether this option use container for chroot (nspawn) or it is recommended to use when running in container.
I would like to hear your comments and ideas.
Dne 11. 09. 19 v 11:56 Miroslav Suchý napsal(a):
Please comment there:
https://github.com/rpm-software-management/mock/issues/331
Copy of Comment #0: This is Request For Comments.
When systemd-nspawn has been added to mock, it brought a lot of bugs. For the transition period we introduced --old-chroot and --new-chroot. The intent was to steer toward the new chroot as mock running containers is more secure and everything. And maybe one day allow choosing between nspawn, docker, podman and others.
But the world went another way. When people are interested in containers, they usually do not want mock to run a container, but they run mock inside of a container. When mock is running inside of container then there is no need for additional isolation and no one really wants to run another container inside of a container. Therefore the --old-chroot is a good choice when you run inside of a container.
My intention is to keep --old-chroot indefinitely and actually recommend it when mock is running in a container. And maybe later automatically choose old or new one depending on if mock is running in a container or on bare metal.
In this situation, the names old/new are quite misleading. As it hints that you should rather use the new stuff rather than the old ones.
Therefore I want to rename (in fact, make alias) for those command-line options.
--old-chroot -> --simple-chroot --new-chroot -> --container-chroot ??? I want to avoid confusion here whether this option use container for chroot
(nspawn) or it is recommended to use when running in container.
I would like to hear your comments and ideas.
My first idea was:
--old-chroot -> --chroot --new-chroot -> --container
But that is probably the confusion you are talking about. So should you change this to something like `--isolation=[chroot,nspawn]`? At the and, there are tools/technologies such as chroot and nspawn, which mock facilitates to "isolate" (of course we can debate what level of isolation chroot provides ...) the build environment from the rest of the system.
BTW the mock manpage is full of references such as "mock - build SRPMs in a chroot" which using nspawn on background is not entirely precise IMO. May be you should reconsider what is actually the purpose of mock, because it is not simple wrapper above chroot anymore.
Vít
On 9/11/19 6:14 AM, Vít Ondruch wrote:
Dne 11. 09. 19 v 11:56 Miroslav Suchý napsal(a):
Please comment there:
https://github.com/rpm-software-management/mock/issues/331
Copy of Comment #0: This is Request For Comments.
When systemd-nspawn has been added to mock, it brought a lot of bugs. For the transition period we introduced --old-chroot and --new-chroot. The intent was to steer toward the new chroot as mock running containers is more secure and everything. And maybe one day allow choosing between nspawn, docker, podman and others.
But the world went another way. When people are interested in containers, they usually do not want mock to run a container, but they run mock inside of a container. When mock is running inside of container then there is no need for additional isolation and no one really wants to run another container inside of a container. Therefore the --old-chroot is a good choice when you run inside of a container.
My intention is to keep --old-chroot indefinitely and actually recommend it when mock is running in a container. And maybe later automatically choose old or new one depending on if mock is running in a container or on bare metal.
In this situation, the names old/new are quite misleading. As it hints that you should rather use the new stuff rather than the old ones.
Therefore I want to rename (in fact, make alias) for those command-line options.
--old-chroot -> --simple-chroot --new-chroot -> --container-chroot ??? I want to avoid confusion here whether this option use container for chroot
(nspawn) or it is recommended to use when running in container.
I would like to hear your comments and ideas.
My first idea was:
--old-chroot -> --chroot --new-chroot -> --container
But that is probably the confusion you are talking about. So should you change this to something like `--isolation=[chroot,nspawn]`? At the and, there are tools/technologies such as chroot and nspawn, which mock facilitates to "isolate" (of course we can debate what level of isolation chroot provides ...) the build environment from the rest of the system.
I like the idea of `--isolation=`. To me this affords the best clarity and also makes room for values of {none,{auto|detect}} or whatever as well should those ever seem appropriate.
+1 for --isolation
st 18. 9. 2019 v 15:33 odesílatel John Florian jflorian@doubledog.org napsal:
On 9/11/19 6:14 AM, Vít Ondruch wrote:
Dne 11. 09. 19 v 11:56 Miroslav Suchý napsal(a):
Please comment there:
https://github.com/rpm-software-management/mock/issues/331
Copy of Comment #0: This is Request For Comments.
When systemd-nspawn has been added to mock, it brought a lot of bugs.
For the transition period we introduced
--old-chroot and --new-chroot. The intent was to steer toward the new
chroot as mock running containers is more secure
and everything. And maybe one day allow choosing between nspawn,
docker, podman and others.
But the world went another way. When people are interested in
containers, they usually do not want mock to run a
container, but they run mock inside of a container. When mock is
running inside of container then there is no need for
additional isolation and no one really wants to run another container
inside of a container. Therefore the --old-chroot
is a good choice when you run inside of a container.
My intention is to keep --old-chroot indefinitely and actually
recommend it when mock is running in a container. And
maybe later automatically choose old or new one depending on if mock is
running in a container or on bare metal.
In this situation, the names old/new are quite misleading. As it hints
that you should rather use the new stuff rather
than the old ones.
Therefore I want to rename (in fact, make alias) for those command-line
options.
--old-chroot -> --simple-chroot --new-chroot -> --container-chroot ??? I want to avoid confusion
here whether this option use container for chroot
(nspawn) or it is recommended to use when running in container.
I would like to hear your comments and ideas.
My first idea was:
--old-chroot -> --chroot --new-chroot -> --container
But that is probably the confusion you are talking about. So should you change this to something like `--isolation=[chroot,nspawn]`? At the and, there are tools/technologies such as chroot and nspawn, which mock facilitates to "isolate" (of course we can debate what level of isolation chroot provides ...) the build environment from the rest of the system.
I like the idea of `--isolation=`. To me this affords the best clarity and also makes room for values of {none,{auto|detect}} or whatever as well should those ever seem appropriate. _______________________________________________ buildsys mailing list -- buildsys@lists.fedoraproject.org To unsubscribe send an email to buildsys-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/buildsys@lists.fedoraproject.o...
ditto
On 9/24/19 10:21 AM, Tomas Kopecek wrote:
+1 for --isolation
st 18. 9. 2019 v 15:33 odesílatel John Florian <jflorian@doubledog.org mailto:jflorian@doubledog.org> napsal:
On 9/11/19 6:14 AM, Vít Ondruch wrote: > Dne 11. 09. 19 v 11:56 Miroslav Suchý napsal(a): >> Please comment there: >> >> https://github.com/rpm-software-management/mock/issues/331 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_rpm-2Dsoftware-2Dmanagement_mock_issues_331&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=CFqnvDcwpIUThNP6puXj4dTdUaOtEpPKICud-AoZEos&s=HiZkwVNNW4tTTpH8P3vYaFd0Tqi-ZxjIupGUv1UR5sQ&e=> >> >> Copy of Comment #0: >> This is Request For Comments. >> >> When systemd-nspawn has been added to mock, it brought a lot of bugs. For the transition period we introduced >> --old-chroot and --new-chroot. The intent was to steer toward the new chroot as mock running containers is more secure >> and everything. And maybe one day allow choosing between nspawn, docker, podman and others. >> >> But the world went another way. When people are interested in containers, they usually do not want mock to run a >> container, but they run mock inside of a container. When mock is running inside of container then there is no need for >> additional isolation and no one really wants to run another container inside of a container. Therefore the --old-chroot >> is a good choice when you run inside of a container. >> >> My intention is to keep --old-chroot indefinitely and actually recommend it when mock is running in a container. And >> maybe later automatically choose old or new one depending on if mock is running in a container or on bare metal. >> >> In this situation, the names old/new are quite misleading. As it hints that you should rather use the new stuff rather >> than the old ones. >> >> Therefore I want to rename (in fact, make alias) for those command-line options. >> >> --old-chroot -> --simple-chroot >> --new-chroot -> --container-chroot ??? I want to avoid confusion here whether this option use container for chroot >> (nspawn) or it is recommended to use when running in container. >> >> I would like to hear your comments and ideas. >> > My first idea was: > > --old-chroot -> --chroot > --new-chroot -> --container > > But that is probably the confusion you are talking about. So should you > change this to something like `--isolation=[chroot,nspawn]`? At the and, > there are tools/technologies such as chroot and nspawn, which mock > facilitates to "isolate" (of course we can debate what level of > isolation chroot provides ...) the build environment from the rest of > the system. I like the idea of `--isolation=`. To me this affords the best clarity and also makes room for values of {none,{auto|detect}} or whatever as well should those ever seem appropriate. _______________________________________________ buildsys mailing list -- buildsys@lists.fedoraproject.org <mailto:buildsys@lists.fedoraproject.org> To unsubscribe send an email to buildsys-leave@lists.fedoraproject.org <mailto:buildsys-leave@lists.fedoraproject.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.org_en-2DUS_project_code-2Dof-2Dconduct_&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=CFqnvDcwpIUThNP6puXj4dTdUaOtEpPKICud-AoZEos&s=6ZnXk3bfOXg_mEEnHcPsSzxq_hT-Ro-QFlj1uqZkkj4&e=> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines <https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Mailing-5Flist-5Fguidelines&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=CFqnvDcwpIUThNP6puXj4dTdUaOtEpPKICud-AoZEos&s=vIAtO23c1Y0iCK6lmVSJoJZblPzS0GflYdzvbP64L8w&e=> List Archives: https://lists.fedoraproject.org/archives/list/buildsys@lists.fedoraproject.org <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org_archives_list_buildsys-40lists.fedoraproject.org&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=CFqnvDcwpIUThNP6puXj4dTdUaOtEpPKICud-AoZEos&s=rD8oPOGXyz6W_qDI6Lsu-xHmEPNrL3DGxcXeSSTtJsA&e=>
--
Tomas Kopecek <tkopecek@redhat.com mailto:tkopecek@redhat.com> Release Engineering Development, RedHat
buildsys mailing list -- buildsys@lists.fedoraproject.org To unsubscribe send an email to buildsys-leave@lists.fedoraproject.org Fedora Code of Conduct: https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.org_... List Guidelines: https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_... List Archives: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org...
buildsys@lists.fedoraproject.org