[ OST Failure Report ] [ ovirt master ] [17.02.17 ] [ external deoendencies missed ]
Hello, Many dependencies are missed [1] Suspected patch is one of the Sandro's fc24 deprecation patches most likely https://gerrit.ovirt.org/#/c/73142 link to first failed build: http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_experi... Changes: http://jenkins.ovirt.org/job/ovirt-engine_master_build-artifacts-el7-x86_64/... Log: http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_experi... [1] [ ERROR ] Yum [u'ovirt-engine-4.2.0-0.0.master.20170227145042.giteb5e384.el7.centos.noarch requires collectd-postgresql', u'ovirt-engine-4.2.0-0.0.master.20170227145042.giteb5e384.el7.centos.noarch requires collectd-write_http', u'ovirt-engine-4.2.0-0.0.master.20170227145042.giteb5e384.el7.centos.noarch requires rubygem-fluent-plugin-secure-forward', u'ovirt-engine-4.2.0-0.0.master.20170227145042.giteb5e384.el7.centos.noarch requires collectd', u'ovirt-engine-4.2.0-0.0.master.20170227145042.giteb5e384.el7.centos.noarch requires collectd-disk', u'ovirt-engine-4.2.0-0.0.master.20170227145042.giteb5e384.el7.centos.noarch requires fluentd'] -- Pavel Zhukov Software Engineer RHV DevOps IRC: landgraf
On Tue, Feb 28, 2017 at 9:36 AM, Pavel Zhukov <pzhukov@redhat.com> wrote:
Hello, Many dependencies are missed [1] Suspected patch is one of the Sandro's fc24 deprecation patches most likely https://gerrit.ovirt.org/#/c/73142
link to first failed build: http://jenkins.ovirt.org/view/experimental%20jobs/job/test- repo_ovirt_experimental_master/5563/ Changes: http://jenkins.ovirt.org/job/ovirt-engine_master_build- artifacts-el7-x86_64/2864/changes#detail Log: http://jenkins.ovirt.org/view/experimental%20jobs/job/test- repo_ovirt_experimental_master/5563/artifact/exported- artifacts/upgrade-from-prevrelease-suit-master-el7/test_logs/upgrade-from- prevrelease-suite-master/post-001_upgrade_engine.py/lago_logs/lago.log
[1] [ ERROR ] Yum [u'ovirt-engine-4.2.0-0.0.master.20170227145042.giteb5e384.el7.centos.noarch requires collectd-postgresql', u'ovirt-engine-4.2.0-0.0. master.20170227145042.giteb5e384.el7.centos.noarch requires collectd-write_http', u'ovirt-engine-4.2.0-0.0.master.20170227145042.giteb5e384.el7.centos.noarch requires rubygem-fluent-plugin-secure-forward', u'ovirt-engine-4.2.0-0.0. master.20170227145042.giteb5e384.el7.centos.noarch requires collectd', u'ovirt-engine-4.2.0-0.0.master.20170227145042.giteb5e384.el7.centos.noarch requires collectd-disk', u'ovirt-engine-4.2.0-0.0.master.20170227145042.giteb5e384.el7.centos.noarch requires fluentd']
I worked on fc24 only, not on el7. ovirt-system-tests is missing collectd and fluents dependencies which are available on a standard installation. Please fix ovirt-system-test including missing packages.
-- Pavel Zhukov Software Engineer RHV DevOps IRC: landgraf
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
Thank you, Seems like the problem is in infra/OST layer. Reposync doesn't sync some Centos packages for some reason. On Tue, Feb 28 2017, Sandro Bonazzola wrote:
On Tue, Feb 28, 2017 at 9:36 AM, Pavel Zhukov <pzhukov@redhat.com> wrote:
Hello, Many dependencies are missed [1] Suspected patch is one of the Sandro's fc24 deprecation patches most likely https://gerrit.ovirt.org/#/c/73142
link to first failed build: http://jenkins.ovirt.org/view/experimental%20jobs/job/test- repo_ovirt_experimental_master/5563/ Changes: http://jenkins.ovirt.org/job/ovirt-engine_master_build- artifacts-el7-x86_64/2864/changes#detail Log: http://jenkins.ovirt.org/view/experimental%20jobs/job/test- repo_ovirt_experimental_master/5563/artifact/exported- artifacts/upgrade-from-prevrelease-suit-master-el7/test_logs/upgrade-from- prevrelease-suite-master/post-001_upgrade_engine.py/lago_logs/lago.log
[1] [ ERROR ] Yum [u'ovirt-engine-4.2.0-0.0.master.20170227145042.giteb5e384.el7.centos.noarch requires collectd-postgresql', u'ovirt-engine-4.2.0-0.0. master.20170227145042.giteb5e384.el7.centos.noarch requires collectd-write_http', u'ovirt-engine-4.2.0-0.0.master.20170227145042.giteb5e384.el7.centos.noarch requires rubygem-fluent-plugin-secure-forward', u'ovirt-engine-4.2.0-0.0. master.20170227145042.giteb5e384.el7.centos.noarch requires collectd', u'ovirt-engine-4.2.0-0.0.master.20170227145042.giteb5e384.el7.centos.noarch requires collectd-disk', u'ovirt-engine-4.2.0-0.0.master.20170227145042.giteb5e384.el7.centos.noarch requires fluentd']
I worked on fc24 only, not on el7. ovirt-system-tests is missing collectd and fluents dependencies which are available on a standard installation. Please fix ovirt-system-test including missing packages.
-- Pavel Zhukov Software Engineer RHV DevOps IRC: landgraf
-- Pavel Zhukov Software Engineer RHV DevOps IRC: landgraf
On 28 February 2017 at 12:16, Pavel Zhukov <pzhukov@redhat.com> wrote:
Thank you, Seems like the problem is in infra/OST layer. Reposync doesn't sync some Centos packages for some reason.
Packages are white-listed in the reposync-config.repo file for the relevat OST suit (most are symlinks to a common file). If we'd download the entire CentOS repo during OST, the jobs would take much longer. -- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
On 28 Feb 2017, at 11:40, Barak Korren <bkorren@redhat.com> wrote:
On 28 February 2017 at 12:16, Pavel Zhukov <pzhukov@redhat.com> wrote:
Thank you, Seems like the problem is in infra/OST layer. Reposync doesn't sync some Centos packages for some reason.
Packages are white-listed in the reposync-config.repo file for the relevat OST suit (most are symlinks to a common file). If we'd download the entire CentOS repo during OST, the jobs would take much longer.
Don’t we have a cache around it? whitelist is hard to maintain. We do not track every packaging change in CentOS Thanks, michal
-- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On 28 February 2017 at 13:04, Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
Don’t we have a cache around it? whitelist is hard to maintain. We do not track every packaging change in CentOS
Yes it is cached, but even with a cache CentOS contains mountains of stuff we don't need and just slows things down. An yes, the white list can be hard to maintain. The thing is that the way OST is built currently it pre-syncs everything it needs and then runs the tests themselves offline. Because of this we need to maintain lists of what is needed anyway. This offline operation feature is something some people find very useful, so we're probably not going to remove it any time soon, despite the difficulty of maintaining the white lists. -- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
On 28 Feb 2017, at 12:49, Barak Korren <bkorren@redhat.com> wrote:
On 28 February 2017 at 13:04, Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
Don’t we have a cache around it? whitelist is hard to maintain. We do not track every packaging change in CentOS
Yes it is cached, but even with a cache CentOS contains mountains of stuff we don't need and just slows things down. An yes, the white list can be hard to maintain.
The thing is that the way OST is built currently it pre-syncs everything it needs and then runs the tests themselves offline.
Shouldn’t be a problem to have a full cache of all CentOS packages on the same host or somewhere close for CI. We do not need a different sync for subsequent runs.
Because of this we need to maintain lists of what is needed anyway. This offline operation feature is something some people find very useful, so we're probably not going to remove it any time soon,
No, I wouldn’t want to remove that. Sure. But if it keeps the cache then why would it take a long time to sync once you do the initial first run?
despite the difficulty of maintaining the white lists.
-- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
On 28 February 2017 at 13:52, Michal Skrivanek <michal.skrivanek@redhat.com>
Shouldn’t be a problem to have a full cache of all CentOS packages on the same host or somewhere close for CI. We do not need a different sync for subsequent runs.
We have that, but OST is not only used in the CI system.
No, I wouldn’t want to remove that. Sure. But if it keeps the cache then why would it take a long time to sync once you do the initial first run?
Well I guess Its a UX issue, do we want a person running OST for the 1st time ever to sit around for a couple of hours to wait for everything to sync? Do we want to take up this much disk space? Also the rate of change is CentOS and the other upstreams can be quite high, so many packages can change between subsequent runs, of which only a fraction is relevant to oVirt. Some packages also take a heavy toll bandwidth-wise when they are updated, consider the LibreOffice family of packages for example... In any case I don`t disagree that the white list approach has its issues. But over time we've found that actual failures that arise from it are few in far between, and are typically easy to resolve. -- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
participants (4)
-
Barak Korren -
Michal Skrivanek -
Pavel Zhukov -
Sandro Bonazzola