- Infra - oVirt List Archives

[JIRA] (OVIRT-2034) Recreate the transactional CI mirrors with Pulp
by Barak Korren (oVirt JIRA) 17 May '18

17 May '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2034?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-2034: -------------------------------- Epic Link: OVIRT-403 > 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)

1 0

[JIRA] (OVIRT-2034) Recreate the transactional CI mirrors with Pulp
by Barak Korren (oVirt JIRA) 17 May '18

17 May '18

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)

1 0

[oVirt Jenkins] ovirt-system-tests_network-suite-4.2 - Build # 213 - Failure!
by jenkins＠jenkins.phx.ovirt.org 17 May '18

17 May '18

Project: http://jenkins.ovirt.org/job/ovirt-system-tests_network-suite-4.2/ Build: http://jenkins.ovirt.org/job/ovirt-system-tests_network-suite-4.2/213/ Build Number: 213 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #213 [Sandro Bonazzola] new suite: he-basic-iscsi-suite-4.2 ----------------- Failed Tests: ----------------- No tests ran.

1 2

[oVirt Jenkins] ovirt-system-tests_network-suite-master - Build # 212 - Failure!
by jenkins＠jenkins.phx.ovirt.org 17 May '18

17 May '18

Project: http://jenkins.ovirt.org/job/ovirt-system-tests_network-suite-master/ Build: http://jenkins.ovirt.org/job/ovirt-system-tests_network-suite-master/212/ Build Number: 212 Build Status: Failure Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #212 [Gal Ben Haim] run_suite: Print lago status on exit ----------------- Failed Tests: ----------------- No tests ran.

1 5

[JIRA] (OVIRT-2033) Provide a "tagging" mecahnism for transactional mirrors.
by Barak Korren (oVirt JIRA) 17 May '18

17 May '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2033?page=com.atlassian.jira.… ] 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)

1 0

[JIRA] (OVIRT-2033) Provide a "tagging" mecahnism for transactional mirrors.
by Barak Korren (oVirt JIRA) 17 May '18

17 May '18

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)

1 0

Change in ds-jenkins-stg[master]: Updated US source to: 28865d2 testing asdf
by review＠gerrit-staging.phx.ovirt.org 17 May '18

17 May '18

From Daniel Belenky <dbelenky(a)redhat.com>: Daniel Belenky has posted comments on this change. ( https://gerrit-staging.phx.ovirt.org/155 ) Change subject: Updated US source to: 28865d2 testing asdf ...................................................................... Patch Set 1: ci test please -- To view, visit https://gerrit-staging.phx.ovirt.org/155 To unsubscribe, visit https://gerrit-staging.phx.ovirt.org/settings Gerrit-Project: ds-jenkins-stg Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I245e8658317dc9ac36fb0e9607c5386255bae8f4 Gerrit-Change-Number: 155 Gerrit-PatchSet: 1 Gerrit-Owner: Jenkins CI <infra(a)ovirt.org> Gerrit-Reviewer: Daniel Belenky <dbelenky(a)redhat.com> Gerrit-Reviewer: Jenkins CI <infra(a)ovirt.org> Gerrit-Comment-Date: Thu, 17 May 2018 08:34:31 +0000 Gerrit-HasComments: No

1 0

[JIRA] (OVIRT-2032) Mounting device files prevents using systemd-nspawn in mock
by Barak Korren (oVirt JIRA) 17 May '18

17 May '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2032?page=com.atlassian.jira.… ] 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)

1 0

[JIRA] (OVIRT-2032) Mounting device files prevents using systemd-nspawn in mock
by Barak Korren (oVirt JIRA) 17 May '18

17 May '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2032?page=com.atlassian.jira.… ] 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)

1 0

[JIRA] (OVIRT-2032) Mounting device files prevents using systemd-nspawn in mock
by Barak Korren (oVirt JIRA) 17 May '18

17 May '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2032?page=com.atlassian.jira.… ] 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)

1 0