[JIRA] (OVIRT-2034) Recreate the transactional CI mirrors with Pulp
by Barak Korren (oVirt JIRA)
Barak Korren created OVIRT-2034:
-----------------------------------
Summary: Recreate the transactional CI mirrors with Pulp
Key: OVIRT-2034
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2034
Project: oVirt - virtualization made easy
Issue Type: New Feature
Components: CI Mirrors
Reporter: Barak Korren
Assignee: infra
Right now, the CI mirrors are created and maintained by a set of custom scripts and jobs.
It seems that [Pulp|https://pulpproject.org/] can do what our current system does. The reason behind not using it when we first made the mirrors system was out desire to provide a quick solution and avoid adding more services to maintain.
There are however, quite a few reasons to want to switch to pulp:
# Aside from RPMs it can also manage other interesting kinds of resources like Containers, DEB packages and Python packages.
# If it works well for us - we can maintain less code by dropping the existing mirror management code
# It has built-in distribution mechanisms that can be useful to scale it up.
# It seems it has support for assigning packages to multiple repos. This cab be used as a tagging mechanism to implement OVIRT-2033
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100085)
6 years, 7 months
[JIRA] (OVIRT-2033) Provide a "tagging" mecahnism for transactional
mirrors.
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2033?page=com.atlassian.jir... ]
Barak Korren updated OVIRT-2033:
--------------------------------
Epic Link: OVIRT-400
> Provide a "tagging" mecahnism for transactional mirrors.
> --------------------------------------------------------
>
> Key: OVIRT-2033
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2033
> Project: oVirt - virtualization made easy
> Issue Type: New Feature
> Components: CI Mirrors
> Reporter: Barak Korren
> Assignee: infra
>
> Right now when using the CI mirrors, one can either:
> # Use the latest snapshots from all mirrors as mock_runner and all the jobs do.
> # Use a specific snapshot by using the direct URL to it as we do on slaves.
> It is desirable to be able to mark or tag specific mirror snapshots for various uses. The primary use for this is to track which mirror snapshots have been tested successfully by the change queue in a similar fashion to the way we track passing packages by storing them in the 'tested' repo. The motivation behind doing this is described in OVIRT-1444
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100085)
6 years, 7 months
[JIRA] (OVIRT-2033) Provide a "tagging" mecahnism for transactional
mirrors.
by Barak Korren (oVirt JIRA)
Barak Korren created OVIRT-2033:
-----------------------------------
Summary: Provide a "tagging" mecahnism for transactional mirrors.
Key: OVIRT-2033
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2033
Project: oVirt - virtualization made easy
Issue Type: New Feature
Components: CI Mirrors
Reporter: Barak Korren
Assignee: infra
Right now when using the CI mirrors, one can either:
# Use the latest snapshots from all mirrors as mock_runner and all the jobs do.
# Use a specific snapshot by using the direct URL to it as we do on slaves.
It is desirable to be able to mark or tag specific mirror snapshots for various uses. The primary use for this is to track which mirror snapshots have been tested successfully by the change queue in a similar fashion to the way we track passing packages by storing them in the 'tested' repo. The motivation behind doing this is described in OVIRT-1444
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100085)
6 years, 7 months
[JIRA] (OVIRT-2032) Mounting device files prevents using
systemd-nspawn in mock
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2032?page=com.atlassian.jir... ]
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)
6 years, 7 months
[JIRA] (OVIRT-2032) Mounting device files prevents using
systemd-nspawn in mock
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2032?page=com.atlassian.jir... ]
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)
6 years, 7 months
[JIRA] (OVIRT-2032) Mounting device files prevents using
systemd-nspawn in mock
by Barak Korren (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-2032?page=com.atlassian.jir... ]
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)
6 years, 7 months
[JIRA] (OVIRT-2032) Mounting device files prevents using
systemd-nspawn in mock
by Barak Korren (oVirt JIRA)
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)
6 years, 7 months