- Infra - oVirt List Archives

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

17 May '18

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)

1 0

[CQ]: 91277, 2 (ovirt-engine-api-model) failed "ovirt-master" system tests
by oVirt Jenkins 17 May '18

17 May '18

Change 91277,2 (ovirt-engine-api-model) is probably the reason behind recent system test failures in the "ovirt-master" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/91277/2 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/7622/

1 0

[JIRA] (OVIRT-2031) Use the systemd-nspawn mode for mock
by Barak Korren (oVirt JIRA) 17 May '18

17 May '18

Barak Korren created OVIRT-2031: ----------------------------------- Summary: Use the systemd-nspawn mode for mock Key: OVIRT-2031 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2031 Project: oVirt - virtualization made easy Issue Type: Improvement Components: mock_runner Reporter: Barak Korren Assignee: infra Mock has long had the ability to use a full container via systemd-nspawn as opposed to a plain chroot. If we can leverage this, we can get many of the benefits of using containers without rebuilding our whole system on a new container backend. There were many issue in the past that prevented us from using that functionality. This ticket if for collecting tickets tracking these issues together. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100085)

1 0

[JIRA] (OVIRT-2031) Use the systemd-nspawn mode for mock
by Barak Korren (oVirt JIRA) 17 May '18

17 May '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2031?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-2031: -------------------------------- Epic Link: OVIRT-400 > Use the systemd-nspawn mode for mock > ------------------------------------ > > Key: OVIRT-2031 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2031 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: mock_runner > Reporter: Barak Korren > Assignee: infra > Labels: tracker > > Mock has long had the ability to use a full container via systemd-nspawn as opposed to a plain chroot. If we can leverage this, we can get many of the benefits of using containers without rebuilding our whole system on a new container backend. > There were many issue in the past that prevented us from using that functionality. This ticket if for collecting tickets tracking these issues together. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100085)

1 0

[JIRA] (OVIRT-2029) Add cache pre-seed functionality to JJB
by Barak Korren (oVirt JIRA) 17 May '18

17 May '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2029?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-2029: -------------------------------- Issue Type: Improvement (was: Task) > Add cache pre-seed functionality to JJB > --------------------------------------- > > Key: OVIRT-2029 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2029 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: JJB > Reporter: Barak Korren > Assignee: infra > Labels: upstream-contribution > > Since we run JJB from STDCI, we cannot have it rely on the existence of a persistent cache from its previous operation. Since JJB is most efficient when it has such a cache, our STDCI script generates such a cache for it from the contents of the previous commit. > To do that we essentially had to implement parts of the JJB internals (The cache handling) on our own. It desirable to have an option in JJB that would do that instead. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100085)

1 0

[JIRA] (OVIRT-2030) Add cache-based deletion option to JJB
by Barak Korren (oVirt JIRA) 17 May '18

17 May '18

Barak Korren created OVIRT-2030: ----------------------------------- Summary: Add cache-based deletion option to JJB Key: OVIRT-2030 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2030 Project: oVirt - virtualization made easy Issue Type: Improvement Components: JJB Reporter: Barak Korren Assignee: infra JJB currently supports two ways to delete jobs: # The {{delete}} command which deletes specific jobs that are specified on the command line # The {{--delete-old}] option to the {{update}} command which delete all jobs in Jenkins that are not included in the current update. Both thes options do not do what we want whic is to delete all jobs not included in the current update that were previously manage by JJB. To get this functionality we've made our scripts check the difference between to current and previous commits to find out which jobs were deleted. Instead we would like JJB to have the option for the {{update}} command to inspect the job cache from previous run (Or generated as explained in OVIRT-2029), and delete jobs found there that are not included in current update. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100085)

1 0

[JIRA] (OVIRT-2030) Add cache-based deletion option to JJB
by Barak Korren (oVirt JIRA) 17 May '18

17 May '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2030?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-2030: -------------------------------- Epic Link: OVIRT-400 > Add cache-based deletion option to JJB > -------------------------------------- > > Key: OVIRT-2030 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2030 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: JJB > Reporter: Barak Korren > Assignee: infra > Labels: upstream-contribution > > JJB currently supports two ways to delete jobs: > # The {{delete}} command which deletes specific jobs that are specified on the command line > # The {{--delete-old}] option to the {{update}} command which delete all jobs in Jenkins that are not included in the current update. > Both thes options do not do what we want whic is to delete all jobs not included in the current update that were previously manage by JJB. > To get this functionality we've made our scripts check the difference between to current and previous commits to find out which jobs were deleted. Instead we would like JJB to have the option for the {{update}} command to inspect the job cache from previous run (Or generated as explained in OVIRT-2029), and delete jobs found there that are not included in current update. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100085)

1 0

[JIRA] (OVIRT-2029) Add cache pre-seed functionality to JJB
by Barak Korren (oVirt JIRA) 17 May '18

17 May '18

Barak Korren created OVIRT-2029: ----------------------------------- Summary: Add cache pre-seed functionality to JJB Key: OVIRT-2029 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2029 Project: oVirt - virtualization made easy Issue Type: Task Components: JJB Reporter: Barak Korren Assignee: infra Since we run JJB from STDCI, we cannot have it rely on the existence of a persistent cache from its previous operation. Since JJB is most efficient when it has such a cache, our STDCI script generates such a cache for it from the contents of the previous commit. To do that we essentially had to implement parts of the JJB internals (The cache handling) on our own. It desirable to have an option in JJB that would do that instead. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100085)

1 0

[JIRA] (OVIRT-2029) Add cache pre-seed functionality to JJB
by Barak Korren (oVirt JIRA) 17 May '18

17 May '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-2029?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-2029: -------------------------------- Epic Link: OVIRT-400 > Add cache pre-seed functionality to JJB > --------------------------------------- > > Key: OVIRT-2029 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2029 > Project: oVirt - virtualization made easy > Issue Type: Task > Components: JJB > Reporter: Barak Korren > Assignee: infra > Labels: upstream-contribution > > Since we run JJB from STDCI, we cannot have it rely on the existence of a persistent cache from its previous operation. Since JJB is most efficient when it has such a cache, our STDCI script generates such a cache for it from the contents of the previous commit. > To do that we essentially had to implement parts of the JJB internals (The cache handling) on our own. It desirable to have an option in JJB that would do that instead. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100085)

1 0

[JIRA] (OVIRT-2028) Re: [Infra-private] Please remove ykleinbe@redhat.com from infra@ovirt.org
by Barak Korren (oVirt JIRA) 17 May '18

17 May '18

Barak Korren created OVIRT-2028: ----------------------------------- Summary: Re: [Infra-private] Please remove ykleinbe(a)redhat.com from infra(a)ovirt.org Key: OVIRT-2028 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2028 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Barak Korren Assignee: infra Forwarding to infra-support to get a Jira ticet. On 15 May 2018 at 10:34, Yaniv Kaul <ykaul(a)redhat.com> wrote: > He has left Red Hat long ago, and his email has been forwarded to Allon, > which recently left Red Hat - and now I'm getting those emails. > > TIA, > Y. > > _______________________________________________ > Infra-private mailing list -- infra-private(a)ovirt.org > To unsubscribe send an email to infra-private-leave(a)ovirt.org > oVirt Code of Conduct: https://www.ovirt.org/community/about/community- > guidelines/ > List Archives: > > -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100085)

1 0