[JIRA] (OVIRT-2032) Mounting device files prevents using systemd-nspawn in mock
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barak Korren updated OVIRT-2032: Assignee: Barak Korren (was: infra) Status: In Progress (was: To Do) > Mounting device files prevents using systemd-nspawn in mock > --- > > Key: OVIRT-2032 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2032 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: mock_runner >Reporter: Barak Korren >Assignee: Barak Korren > Labels: upstream-issue > > The systemd-nspawn functionality in mock is introduced in OVIRT-2031. > When using systemd-nspawn mock uses some kind of a layered FS that is created > when it starts and removed when it exits. This is different from the way it > works when using chroot where the directory that the chroot is configured in > stays around until it is explicitly removed. > mock had an issue where if you tried to bind-mount something into the mock > environment, you had to have the mount point ready for it. We worked around > this in {{mock_runner}} by using the fact the chroot was persistent, going > into it and setting up the mount points as needed before actually starting to > use it to run the STDCI script. > Since the mock authors were aware of the issue when the implemented the > systemd-nspawn functionality, they made mock pre-create mount point in the > container as needed. However, they only supported directory mount points, so > if we tried to bind-mount a socket we would get en error message failing to > mount a socket file on a directory. > We reported this issue to the mock developers as issue > [#87|https://github.com/rpm-software-management/mock/issues/87] -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/HJ5CQ5G2XJLIQHN4YJ6XGFCF4OALICTR/
[JIRA] (OVIRT-2032) Mounting device files prevents using systemd-nspawn in mock
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barak Korren updated OVIRT-2032: Epic Link: OVIRT-2189 (was: OVIRT-400) > Mounting device files prevents using systemd-nspawn in mock > --- > > Key: OVIRT-2032 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2032 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: mock_runner >Reporter: Barak Korren >Assignee: infra > Labels: upstream-issue > > The systemd-nspawn functionality in mock is introduced in OVIRT-2031. > When using systemd-nspawn mock uses some kind of a layered FS that is created > when it starts and removed when it exits. This is different from the way it > works when using chroot where the directory that the chroot is configured in > stays around until it is explicitly removed. > mock had an issue where if you tried to bind-mount something into the mock > environment, you had to have the mount point ready for it. We worked around > this in {{mock_runner}} by using the fact the chroot was persistent, going > into it and setting up the mount points as needed before actually starting to > use it to run the STDCI script. > Since the mock authors were aware of the issue when the implemented the > systemd-nspawn functionality, they made mock pre-create mount point in the > container as needed. However, they only supported directory mount points, so > if we tried to bind-mount a socket we would get en error message failing to > mount a socket file on a directory. > We reported this issue to the mock developers as issue > [#87|https://github.com/rpm-software-management/mock/issues/87] -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/QGQHTMCEQNXVEARXFNY3TJ3NDPWOB6VI/
[JIRA] (OVIRT-2032) Mounting device files prevents using systemd-nspawn in mock
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barak Korren updated OVIRT-2032: Epic Link: OVIRT-2189 (was: OVIRT-400) > Mounting device files prevents using systemd-nspawn in mock > --- > > Key: OVIRT-2032 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2032 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: mock_runner >Reporter: Barak Korren >Assignee: infra > Labels: upstream-issue > > The systemd-nspawn functionality in mock is introduced in OVIRT-2031. > When using systemd-nspawn mock uses some kind of a layered FS that is created > when it starts and removed when it exits. This is different from the way it > works when using chroot where the directory that the chroot is configured in > stays around until it is explicitly removed. > mock had an issue where if you tried to bind-mount something into the mock > environment, you had to have the mount point ready for it. We worked around > this in {{mock_runner}} by using the fact the chroot was persistent, going > into it and setting up the mount points as needed before actually starting to > use it to run the STDCI script. > Since the mock authors were aware of the issue when the implemented the > systemd-nspawn functionality, they made mock pre-create mount point in the > container as needed. However, they only supported directory mount points, so > if we tried to bind-mount a socket we would get en error message failing to > mount a socket file on a directory. > We reported this issue to the mock developers as issue > [#87|https://github.com/rpm-software-management/mock/issues/87] -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/N6UDU7ER7GHIBHHCPQ3IQDZBXKKLBZEA/
[JIRA] (OVIRT-2032) Mounting device files prevents using systemd-nspawn in mock
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=37008#comment-37008 ] Barak Korren commented on OVIRT-2032: - The fix was included in mock-1.4.10 which was already released to EPEL: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-28fdd00a4b > Mounting device files prevents using systemd-nspawn in mock > --- > > Key: OVIRT-2032 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2032 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: mock_runner >Reporter: Barak Korren >Assignee: infra > Labels: upstream-issue > > The systemd-nspawn functionality in mock is introduced in OVIRT-2031. > When using systemd-nspawn mock uses some kind of a layered FS that is created > when it starts and removed when it exits. This is different from the way it > works when using chroot where the directory that the chroot is configured in > stays around until it is explicitly removed. > mock had an issue where if you tried to bind-mount something into the mock > environment, you had to have the mount point ready for it. We worked around > this in {{mock_runner}} by using the fact the chroot was persistent, going > into it and setting up the mount points as needed before actually starting to > use it to run the STDCI script. > Since the mock authors were aware of the issue when the implemented the > systemd-nspawn functionality, they made mock pre-create mount point in the > container as needed. However, they only supported directory mount points, so > if we tried to bind-mount a socket we would get en error message failing to > mount a socket file on a directory. > We reported this issue to the mock developers as issue > [#87|https://github.com/rpm-software-management/mock/issues/87] -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100087) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/OZOMGIF7MR7OCCMEUTGXSS4XC52OUL56/
[JIRA] (OVIRT-2032) Mounting device files prevents using systemd-nspawn in mock
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barak Korren updated OVIRT-2032: Labels: upstream-issue (was: ) > Mounting device files prevents using systemd-nspawn in mock > --- > > Key: OVIRT-2032 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2032 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: mock_runner >Reporter: Barak Korren >Assignee: infra > Labels: upstream-issue > > The systemd-nspawn functionality in mock is introduced in OVIRT-2031. > When using systemd-nspawn mock uses some kind of a layered FS that is created > when it starts and removed when it exits. This is different from the way it > works when using chroot where the directory that the chroot is configured in > stays around until it is explicitly removed. > mock had an issue where if you tried to bind-mount something into the mock > environment, you had to have the mount point ready for it. We worked around > this in {{mock_runner}} by using the fact the chroot was persistent, going > into it and setting up the mount points as needed before actually starting to > use it to run the STDCI script. > Since the mock authors were aware of the issue when the implemented the > systemd-nspawn functionality, they made mock pre-create mount point in the > container as needed. However, they only supported directory mount points, so > if we tried to bind-mount a socket we would get en error message failing to > mount a socket file on a directory. > We reported this issue to the mock developers as issue > [#87|https://github.com/rpm-software-management/mock/issues/87] -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100085) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org
[JIRA] (OVIRT-2032) Mounting device files prevents using systemd-nspawn in mock
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=36587#comment-36587 ] Barak Korren commented on OVIRT-2032: - Issue [#87|https://github.com/rpm-software-management/mock/issues/87] has been resolved with PR [#171|https://github.com/rpm-software-management/mock/pull/171]. We need to check: # If we can now remove our mount point creation code from {{mock_runner}}. # If this paves the way to using {{systemd-nspawn}} in {{mock_runner}}. > Mounting device files prevents using systemd-nspawn in mock > --- > > Key: OVIRT-2032 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2032 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: mock_runner >Reporter: Barak Korren >Assignee: infra > Labels: upstream-issue > > The systemd-nspawn functionality in mock is introduced in OVIRT-2031. > When using systemd-nspawn mock uses some kind of a layered FS that is created > when it starts and removed when it exits. This is different from the way it > works when using chroot where the directory that the chroot is configured in > stays around until it is explicitly removed. > mock had an issue where if you tried to bind-mount something into the mock > environment, you had to have the mount point ready for it. We worked around > this in {{mock_runner}} by using the fact the chroot was persistent, going > into it and setting up the mount points as needed before actually starting to > use it to run the STDCI script. > Since the mock authors were aware of the issue when the implemented the > systemd-nspawn functionality, they made mock pre-create mount point in the > container as needed. However, they only supported directory mount points, so > if we tried to bind-mount a socket we would get en error message failing to > mount a socket file on a directory. > We reported this issue to the mock developers as issue > [#87|https://github.com/rpm-software-management/mock/issues/87] -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100085) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org
[JIRA] (OVIRT-2032) Mounting device files prevents using systemd-nspawn in mock
Barak Korren created OVIRT-2032: --- Summary: Mounting device files prevents using systemd-nspawn in mock Key: OVIRT-2032 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2032 Project: oVirt - virtualization made easy Issue Type: Bug Components: mock_runner Reporter: Barak Korren Assignee: infra The systemd-nspawn functionality in mock is introduced in OVIRT-2031. When using systemd-nspawn mock uses some kind of a layered FS that is created when it starts and removed when it exits. This is different from the way it works when using chroot where the directory that the chroot is configured in stays around until it is explicitly removed. mock had an issue where if you tried to bind-mount something into the mock environment, you had to have the mount point ready for it. We worked around this in {{mock_runner}} by using the fact the chroot was persistent, going into it and setting up the mount points as needed before actually starting to use it to run the STDCI script. Since the mock authors were aware of the issue when the implemented the systemd-nspawn functionality, they made mock pre-create mount point in the container as needed. However, they only supported directory mount points, so if we tried to bind-mount a socket we would get en error message failing to mount a socket file on a directory. We reported this issue to the mock developers as issue [#87|https://github.com/rpm-software-management/mock/issues/87] -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100085) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org
[JIRA] (OVIRT-2032) Mounting device files prevents using systemd-nspawn in mock
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barak Korren updated OVIRT-2032: Epic Link: OVIRT-400 > Mounting device files prevents using systemd-nspawn in mock > --- > > Key: OVIRT-2032 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2032 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: mock_runner >Reporter: Barak Korren >Assignee: infra > > The systemd-nspawn functionality in mock is introduced in OVIRT-2031. > When using systemd-nspawn mock uses some kind of a layered FS that is created > when it starts and removed when it exits. This is different from the way it > works when using chroot where the directory that the chroot is configured in > stays around until it is explicitly removed. > mock had an issue where if you tried to bind-mount something into the mock > environment, you had to have the mount point ready for it. We worked around > this in {{mock_runner}} by using the fact the chroot was persistent, going > into it and setting up the mount points as needed before actually starting to > use it to run the STDCI script. > Since the mock authors were aware of the issue when the implemented the > systemd-nspawn functionality, they made mock pre-create mount point in the > container as needed. However, they only supported directory mount points, so > if we tried to bind-mount a socket we would get en error message failing to > mount a socket file on a directory. > We reported this issue to the mock developers as issue > [#87|https://github.com/rpm-software-management/mock/issues/87] -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100085) ___ Infra mailing list -- infra@ovirt.org To unsubscribe send an email to infra-le...@ovirt.org