[ovirt-devel] Re: master CQ fails due to missing ovirt-host-deploy
this is the current package in tested: ovirt-engine-0:4.2.0-0.0.master.20170712084142.git63b81ef.el7.centos.noarch and since all projects are now failing on this, it means the engine package in tested is a broken package. what I don't understand is how can CQ mark engine as failed since this patch: https://gerrit.ovirt.org/#/c/104391/ which is 4 weeks ago but I can see a new package in tested since 06-02-2020 with no passing cq test for ovirt-engine. If anyone is moving packages manually to tested they are breaking all projects by introducing broken packages. As the package in tested is now broken, we should start fixing the code on each failing issue. for now, the main thing that is failing is that we are looking for a package that no longer exists. Didi, is it possible its the typo Marcin was commenting on in this patch: https://gerrit.ovirt.org/#/c/106797/ Thanks, Dafna On Tue, Feb 11, 2020 at 9:03 AM Yedidyah Bar David wrote: > On Tue, Feb 11, 2020 at 10:22 AM Dusan Fodor wrote: > > > > Hello, > > master CQ is failing on initialize_engine due to missing > ovirt-host-deploy dependency. > > > > [ INFO ] Checking for an update for Setup... > > [ ERROR ] Yum Cannot queue package ovirt-host-deploy: Package > ovirt-host-deploy cannot be found > > > > > > I was under the impression that engine-setup should not require it > anymore, but it seems the related patch [1] doesn't work as intended. > Perhaps Marcin's comment there explains why? Can you please check this? > > How can I know which engine build was used for [2]? > > Checking lago.log there, I see: > > Installed: > net-snmp.x86_64 1:5.7.2-43.el7_7.3 > ntp.x86_64 0:4.2.6p5-29.el7.centos > otopi-debug-plugins.noarch 0:1.9.0-1.el7 > ovirt-engine.noarch 0:4.4.0-0.0.master.20200206140618.gitff1f0b4.el7 > ovirt-engine-extension-aaa-ldap.noarch 0:1.3.11-0.0.master.gitb9a171f.el7 > ovirt-engine-extension-aaa-ldap-setup.noarch > 0:1.3.11-0.0.master.gitb9a171f.el7 > ovirt-log-collector.noarch > 0:4.4.0-0.0.master.20191122133512.gitfc29382.el7 > > ff1f0b4 is a hash of a not-yet-merged patch: > > https://gerrit.ovirt.org/106794 > > It should be rebased. > > Also not sure how the change-queue-tester uses a not-merged-yet engine. > > (And also, [1] is not enough, Marcin Sobczyk later pushed a fix for > it, https://gerrit.ovirt.org/106809 ). > > > Job example [2] > > Thanks > > > > [1] https://gerrit.ovirt.org/#/c/106797/ > > [2] > https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/19724/testReport/(root)/001_initialize_engine/initialize_engine/ > > > > -- > Didi > ___ > Devel mailing list -- devel@ovirt.org > To unsubscribe send an email to devel-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/devel@ovirt.org/message/I5NOUPCLFXQDKDBHNIQC2XL56YZYLGOT/ > ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-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/devel@ovirt.org/message/XZWUOLX4SCRKX53E3OXVBNAUAOUBOULA/
[ovirt-devel] Re: master CQ fails due to missing ovirt-host-deploy
On Wed, Feb 12, 2020 at 11:39 AM Dafna Ron wrote: > > this is the current package in tested: > ovirt-engine-0:4.2.0-0.0.master.20170712084142.git63b81ef.el7.centos.noarch > and since all projects are now failing on this, it means the engine package > in tested is a broken package. > what I don't understand is how can CQ mark engine as failed since this patch: > https://gerrit.ovirt.org/#/c/104391/ which is 4 weeks ago but I can see a new > package in tested since 06-02-2020 with no passing cq test for ovirt-engine. > If anyone is moving packages manually to tested they are breaking all > projects by introducing broken packages. > > As the package in tested is now broken, we should start fixing the code on > each failing issue. > for now, the main thing that is failing is that we are looking for a package > that no longer exists. > Didi, is it possible its the typo Marcin was commenting on in this patch: > https://gerrit.ovirt.org/#/c/106797/ I already addressed this, > > Thanks, > Dafna > > > > > > > > On Tue, Feb 11, 2020 at 9:03 AM Yedidyah Bar David wrote: >> >> On Tue, Feb 11, 2020 at 10:22 AM Dusan Fodor wrote: >> > >> > Hello, >> > master CQ is failing on initialize_engine due to missing ovirt-host-deploy >> > dependency. >> > >> > [ INFO ] Checking for an update for Setup... >> > [ ERROR ] Yum Cannot queue package ovirt-host-deploy: Package >> > ovirt-host-deploy cannot be found >> > >> > >> > I was under the impression that engine-setup should not require it >> > anymore, but it seems the related patch [1] doesn't work as intended. >> > Perhaps Marcin's comment there explains why? Can you please check this? >> >> How can I know which engine build was used for [2]? >> >> Checking lago.log there, I see: >> >> Installed: >> net-snmp.x86_64 1:5.7.2-43.el7_7.3 >> ntp.x86_64 0:4.2.6p5-29.el7.centos >> otopi-debug-plugins.noarch 0:1.9.0-1.el7 >> ovirt-engine.noarch 0:4.4.0-0.0.master.20200206140618.gitff1f0b4.el7 >> ovirt-engine-extension-aaa-ldap.noarch 0:1.3.11-0.0.master.gitb9a171f.el7 >> ovirt-engine-extension-aaa-ldap-setup.noarch >> 0:1.3.11-0.0.master.gitb9a171f.el7 >> ovirt-log-collector.noarch 0:4.4.0-0.0.master.20191122133512.gitfc29382.el7 >> >> ff1f0b4 is a hash of a not-yet-merged patch: >> >> https://gerrit.ovirt.org/106794 >> >> It should be rebased. >> >> Also not sure how the change-queue-tester uses a not-merged-yet engine. >> >> (And also, [1] is not enough, Marcin Sobczyk later pushed a fix for >> it, https://gerrit.ovirt.org/106809 ). here ^^. Already merged as well. >> >> > Job example [2] >> > Thanks >> > >> > [1] https://gerrit.ovirt.org/#/c/106797/ >> > [2] >> > https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/19724/testReport/(root)/001_initialize_engine/initialize_engine/ >> >> >> >> -- >> Didi >> ___ >> Devel mailing list -- devel@ovirt.org >> To unsubscribe send an email to devel-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/devel@ovirt.org/message/I5NOUPCLFXQDKDBHNIQC2XL56YZYLGOT/ -- Didi ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-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/devel@ovirt.org/message/C2M2KXJ34JWFXY7XTZ4V4EP4BO2OZN32/
[ovirt-devel] Re: master CQ fails due to missing ovirt-host-deploy
Then another possibility is that the package is now suppose to be coming from somewhere else and its not available? where is it suppose to come from? from what I understood, it should be deployed by ansible, is that correct? I can see an abandoned patch but cannot see a patch that was merged for ansible: https://gerrit.ovirt.org/#/q/ovirt-host-deploy It seems patch: https://gerrit.ovirt.org/#/c/102959/ was abandoned for no activity - was anything else actually merged on ansible side? Thanks, Dafna On Wed, Feb 12, 2020 at 9:47 AM Yedidyah Bar David wrote: > On Wed, Feb 12, 2020 at 11:39 AM Dafna Ron wrote: > > > > this is the current package in tested: > ovirt-engine-0:4.2.0-0.0.master.20170712084142.git63b81ef.el7.centos.noarch > and since all projects are now failing on this, it means the engine package > in tested is a broken package. > > what I don't understand is how can CQ mark engine as failed since this > patch: https://gerrit.ovirt.org/#/c/104391/ which is 4 weeks ago but I > can see a new package in tested since 06-02-2020 with no passing cq test > for ovirt-engine. > > If anyone is moving packages manually to tested they are breaking all > projects by introducing broken packages. > > > > As the package in tested is now broken, we should start fixing the code > on each failing issue. > > for now, the main thing that is failing is that we are looking for a > package that no longer exists. > > Didi, is it possible its the typo Marcin was commenting on in this > patch: https://gerrit.ovirt.org/#/c/106797/ > > I already addressed this, > > > > > Thanks, > > Dafna > > > > > > > > > > > > > > > > On Tue, Feb 11, 2020 at 9:03 AM Yedidyah Bar David > wrote: > >> > >> On Tue, Feb 11, 2020 at 10:22 AM Dusan Fodor wrote: > >> > > >> > Hello, > >> > master CQ is failing on initialize_engine due to missing > ovirt-host-deploy dependency. > >> > > >> > [ INFO ] Checking for an update for Setup... > >> > [ ERROR ] Yum Cannot queue package ovirt-host-deploy: Package > ovirt-host-deploy cannot be found > >> > > >> > > >> > I was under the impression that engine-setup should not require it > anymore, but it seems the related patch [1] doesn't work as intended. > Perhaps Marcin's comment there explains why? Can you please check this? > >> > >> How can I know which engine build was used for [2]? > >> > >> Checking lago.log there, I see: > >> > >> Installed: > >> net-snmp.x86_64 1:5.7.2-43.el7_7.3 > >> ntp.x86_64 0:4.2.6p5-29.el7.centos > >> otopi-debug-plugins.noarch 0:1.9.0-1.el7 > >> ovirt-engine.noarch 0:4.4.0-0.0.master.20200206140618.gitff1f0b4.el7 > >> ovirt-engine-extension-aaa-ldap.noarch > 0:1.3.11-0.0.master.gitb9a171f.el7 > >> ovirt-engine-extension-aaa-ldap-setup.noarch > >> 0:1.3.11-0.0.master.gitb9a171f.el7 > >> ovirt-log-collector.noarch > 0:4.4.0-0.0.master.20191122133512.gitfc29382.el7 > >> > >> ff1f0b4 is a hash of a not-yet-merged patch: > >> > >> https://gerrit.ovirt.org/106794 > >> > >> It should be rebased. > >> > >> Also not sure how the change-queue-tester uses a not-merged-yet engine. > >> > >> (And also, [1] is not enough, Marcin Sobczyk later pushed a fix for > >> it, https://gerrit.ovirt.org/106809 ). > > here ^^. Already merged as well. > > >> > >> > Job example [2] > >> > Thanks > >> > > >> > [1] https://gerrit.ovirt.org/#/c/106797/ > >> > [2] > https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/19724/testReport/(root)/001_initialize_engine/initialize_engine/ > >> > >> > >> > >> -- > >> Didi > >> ___ > >> Devel mailing list -- devel@ovirt.org > >> To unsubscribe send an email to devel-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/devel@ovirt.org/message/I5NOUPCLFXQDKDBHNIQC2XL56YZYLGOT/ > > > > -- > Didi > > ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-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/devel@ovirt.org/message/ZAXMQR773ODCQSDK7TK7QV62LRFGOYOV/
[ovirt-devel] Re: OST network suite is failing
was the package created from this patch manually moved into tested repo? I can see the package in tested and yet this patch https://gerrit.ovirt.org/#/c/106794/ has not been merged On Thu, Feb 6, 2020 at 6:22 PM Michal Skrivanek wrote: > Just note that from this time on engine is going through breaking changes > to bring it to el8. The CQ works in mysterious ways so in case anything new > ends up in master repo it’s unlikely that you’ll get anywhere far in OST. > Until the transition is finished > > On 6 Feb 2020, at 11:37, Andrej Krejcir wrote: > > This patch should fix the NPE: > > https://gerrit.ovirt.org/#/c/106794/ > > On Thu, 6 Feb 2020 at 10:59, Benny Zlotnik wrote: > >> I think it was fixed[1], is the patch rebased? >> >> [1] https://gerrit.ovirt.org/#/c/106772/ >> >> On Thu, Feb 6, 2020 at 11:53 AM Dominik Holler >> wrote: >> > >> > Hello Tal and Andrej, >> > can you please have a look at the failing >> > >> https://jenkins.ovirt.org/job/ovirt-system-tests_network-suite-master/1260/ >> > >> > 2020-02-05 21:03:12,798-05 ERROR >> [org.ovirt.engine.core.bll.storage.disk.AddDiskCommand] (default task-2) >> [03a09eb0-7ccd-44db-a8fd-c01dc8ce82c7] Error during ValidateFailure.: >> java.lang.NullPointerException >> > at >> deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.validator.storage.DiskVmElementValidator.isVirtIoScsiValid(DiskVmElementValidator.java:54) >> > at >> deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.storage.disk.AddDiskCommand.checkIfImageDiskCanBeAdded(AddDiskCommand.java:299) >> > at >> deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.storage.disk.AddDiskCommand.validate(AddDiskCommand.java:195) >> > >> > >> > >> > Thanks, >> > >> > Dominik >> > >> > ___ >> > Devel mailing list -- devel@ovirt.org >> > To unsubscribe send an email to devel-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/devel@ovirt.org/message/V42PCHW23M5XVSQMQ3IRJ4ZYTEPLMJQC/ >> >> ___ > Devel mailing list -- devel@ovirt.org > To unsubscribe send an email to devel-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/devel@ovirt.org/message/GTVQZ7ERY4HKRA2WGZQ7E3HHX5UZB5ER/ > > ___ > Devel mailing list -- devel@ovirt.org > To unsubscribe send an email to devel-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/devel@ovirt.org/message/KDSI6KRRGZNCBMGE23TME7FN7OJXPTWE/ > ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-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/devel@ovirt.org/message/ETRCDZ4PFM4JICWMWLSL3BDT3BYSKXAP/
[ovirt-devel] Re: master CQ fails due to missing ovirt-host-deploy
On Wed, Feb 12, 2020 at 11:07 AM Dafna Ron wrote: > Then another possibility is that the package is now suppose to be coming > from somewhere else and its not available? > where is it suppose to come from? from what I understood, it should be > deployed by ansible, is that correct? > I can see an abandoned patch but cannot see a patch that was merged for > ansible: > https://gerrit.ovirt.org/#/q/ovirt-host-deploy > > It seems patch: https://gerrit.ovirt.org/#/c/102959/ was abandoned for no > activity - was anything else actually merged on ansible side? > > Thanks, > Dafna > > > On Wed, Feb 12, 2020 at 9:47 AM Yedidyah Bar David > wrote: > >> On Wed, Feb 12, 2020 at 11:39 AM Dafna Ron wrote: >> > >> > this is the current package in tested: >> ovirt-engine-0:4.2.0-0.0.master.20170712084142.git63b81ef.el7.centos.noarch >> and since all projects are now failing on this, it means the engine package >> in tested is a broken package. >> > what I don't understand is how can CQ mark engine as failed since this >> patch: https://gerrit.ovirt.org/#/c/104391/ which is 4 weeks ago but I >> can see a new package in tested since 06-02-2020 with no passing cq test >> for ovirt-engine. >> > If anyone is moving packages manually to tested they are breaking all >> projects by introducing broken packages. >> > >> > As the package in tested is now broken, we should start fixing the code >> on each failing issue. >> > for now, the main thing that is failing is that we are looking for a >> package that no longer exists. >> > Didi, is it possible its the typo Marcin was commenting on in this >> patch: https://gerrit.ovirt.org/#/c/106797/ >> >> I already addressed this, >> > https://gerrit.ovirt.org/106809 was a fix for that issue, if it still didn't pass the CQ, then let's pass the engine build this patch through CQ manually >> > >> > Thanks, >> > Dafna >> > >> > >> > >> > >> > >> > >> > >> > On Tue, Feb 11, 2020 at 9:03 AM Yedidyah Bar David >> wrote: >> >> >> >> On Tue, Feb 11, 2020 at 10:22 AM Dusan Fodor >> wrote: >> >> > >> >> > Hello, >> >> > master CQ is failing on initialize_engine due to missing >> ovirt-host-deploy dependency. >> >> > >> >> > [ INFO ] Checking for an update for Setup... >> >> > [ ERROR ] Yum Cannot queue package ovirt-host-deploy: Package >> ovirt-host-deploy cannot be found >> >> > >> >> > >> >> > I was under the impression that engine-setup should not require it >> anymore, but it seems the related patch [1] doesn't work as intended. >> Perhaps Marcin's comment there explains why? Can you please check this? >> >> >> >> How can I know which engine build was used for [2]? >> >> >> >> Checking lago.log there, I see: >> >> >> >> Installed: >> >> net-snmp.x86_64 1:5.7.2-43.el7_7.3 >> >> ntp.x86_64 0:4.2.6p5-29.el7.centos >> >> otopi-debug-plugins.noarch 0:1.9.0-1.el7 >> >> ovirt-engine.noarch 0:4.4.0-0.0.master.20200206140618.gitff1f0b4.el7 >> >> ovirt-engine-extension-aaa-ldap.noarch >> 0:1.3.11-0.0.master.gitb9a171f.el7 >> >> ovirt-engine-extension-aaa-ldap-setup.noarch >> >> 0:1.3.11-0.0.master.gitb9a171f.el7 >> >> ovirt-log-collector.noarch >> 0:4.4.0-0.0.master.20191122133512.gitfc29382.el7 >> >> >> >> ff1f0b4 is a hash of a not-yet-merged patch: >> >> >> >> https://gerrit.ovirt.org/106794 >> >> >> >> It should be rebased. >> >> >> >> Also not sure how the change-queue-tester uses a not-merged-yet engine. >> >> >> >> (And also, [1] is not enough, Marcin Sobczyk later pushed a fix for >> >> it, https://gerrit.ovirt.org/106809 ). >> >> here ^^. Already merged as well. >> >> >> >> >> > Job example [2] >> >> > Thanks >> >> > >> >> > [1] https://gerrit.ovirt.org/#/c/106797/ >> >> > [2] >> https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/19724/testReport/(root)/001_initialize_engine/initialize_engine/ >> >> >> >> >> >> >> >> -- >> >> Didi >> >> ___ >> >> Devel mailing list -- devel@ovirt.org >> >> To unsubscribe send an email to devel-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/devel@ovirt.org/message/I5NOUPCLFXQDKDBHNIQC2XL56YZYLGOT/ >> >> >> >> -- >> Didi >> >> ___ > Devel mailing list -- devel@ovirt.org > To unsubscribe send an email to devel-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/devel@ovirt.org/message/ZAXMQR773ODCQSDK7TK7QV62LRFGOYOV/ > -- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o. ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@ovirt.org Privacy Statement: https://www.ovirt.
[ovirt-devel] Re: master CQ fails due to missing ovirt-host-deploy
The problem is that the package which is currently in tested is an un-authorised package that is actually breaking all the projects and not just engine. it has been transferred manually as I cannot see a passing ovirt-engine cq test for over a month and the package that is there is pointing at an un-merged change. We should not touch CQ manually ever as doing that breaks it completely and makes it more difficult to find and fix any other issues and breaks all other projects as well. I have re-merged the fix that you pointed to to see what is causing it to fail CQ and will update once it goes through cq and we can see what other issues we have. Thanks, Dafna On Wed, Feb 12, 2020 at 1:02 PM Martin Perina wrote: > > > On Wed, Feb 12, 2020 at 11:07 AM Dafna Ron wrote: > >> Then another possibility is that the package is now suppose to be coming >> from somewhere else and its not available? >> where is it suppose to come from? from what I understood, it should be >> deployed by ansible, is that correct? >> I can see an abandoned patch but cannot see a patch that was merged for >> ansible: >> https://gerrit.ovirt.org/#/q/ovirt-host-deploy >> >> It seems patch: https://gerrit.ovirt.org/#/c/102959/ was abandoned for >> no activity - was anything else actually merged on ansible side? >> >> Thanks, >> Dafna >> >> >> On Wed, Feb 12, 2020 at 9:47 AM Yedidyah Bar David >> wrote: >> >>> On Wed, Feb 12, 2020 at 11:39 AM Dafna Ron wrote: >>> > >>> > this is the current package in tested: >>> ovirt-engine-0:4.2.0-0.0.master.20170712084142.git63b81ef.el7.centos.noarch >>> and since all projects are now failing on this, it means the engine package >>> in tested is a broken package. >>> > what I don't understand is how can CQ mark engine as failed since this >>> patch: https://gerrit.ovirt.org/#/c/104391/ which is 4 weeks ago but I >>> can see a new package in tested since 06-02-2020 with no passing cq test >>> for ovirt-engine. >>> > If anyone is moving packages manually to tested they are breaking all >>> projects by introducing broken packages. >>> > >>> > As the package in tested is now broken, we should start fixing the >>> code on each failing issue. >>> > for now, the main thing that is failing is that we are looking for a >>> package that no longer exists. >>> > Didi, is it possible its the typo Marcin was commenting on in this >>> patch: https://gerrit.ovirt.org/#/c/106797/ >>> >>> I already addressed this, >>> >> > https://gerrit.ovirt.org/106809 was a fix for that issue, if it still > didn't pass the CQ, then let's pass the engine build this patch through CQ > manually > > >>> > >>> > Thanks, >>> > Dafna >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > On Tue, Feb 11, 2020 at 9:03 AM Yedidyah Bar David >>> wrote: >>> >> >>> >> On Tue, Feb 11, 2020 at 10:22 AM Dusan Fodor >>> wrote: >>> >> > >>> >> > Hello, >>> >> > master CQ is failing on initialize_engine due to missing >>> ovirt-host-deploy dependency. >>> >> > >>> >> > [ INFO ] Checking for an update for Setup... >>> >> > [ ERROR ] Yum Cannot queue package ovirt-host-deploy: Package >>> ovirt-host-deploy cannot be found >>> >> > >>> >> > >>> >> > I was under the impression that engine-setup should not require it >>> anymore, but it seems the related patch [1] doesn't work as intended. >>> Perhaps Marcin's comment there explains why? Can you please check this? >>> >> >>> >> How can I know which engine build was used for [2]? >>> >> >>> >> Checking lago.log there, I see: >>> >> >>> >> Installed: >>> >> net-snmp.x86_64 1:5.7.2-43.el7_7.3 >>> >> ntp.x86_64 0:4.2.6p5-29.el7.centos >>> >> otopi-debug-plugins.noarch 0:1.9.0-1.el7 >>> >> ovirt-engine.noarch 0:4.4.0-0.0.master.20200206140618.gitff1f0b4.el7 >>> >> ovirt-engine-extension-aaa-ldap.noarch >>> 0:1.3.11-0.0.master.gitb9a171f.el7 >>> >> ovirt-engine-extension-aaa-ldap-setup.noarch >>> >> 0:1.3.11-0.0.master.gitb9a171f.el7 >>> >> ovirt-log-collector.noarch >>> 0:4.4.0-0.0.master.20191122133512.gitfc29382.el7 >>> >> >>> >> ff1f0b4 is a hash of a not-yet-merged patch: >>> >> >>> >> https://gerrit.ovirt.org/106794 >>> >> >>> >> It should be rebased. >>> >> >>> >> Also not sure how the change-queue-tester uses a not-merged-yet >>> engine. >>> >> >>> >> (And also, [1] is not enough, Marcin Sobczyk later pushed a fix for >>> >> it, https://gerrit.ovirt.org/106809 ). >>> >>> here ^^. Already merged as well. >>> >>> >> >>> >> > Job example [2] >>> >> > Thanks >>> >> > >>> >> > [1] https://gerrit.ovirt.org/#/c/106797/ >>> >> > [2] >>> https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/19724/testReport/(root)/001_initialize_engine/initialize_engine/ >>> >> >>> >> >>> >> >>> >> -- >>> >> Didi >>> >> ___ >>> >> Devel mailing list -- devel@ovirt.org >>> >> To unsubscribe send an email to devel-le...@ovirt.org >>> >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >>> >> oVirt Code of Conduct: >>> https:
[ovirt-devel] please stop merging
Hi all, Engine has been failing for a while and someone has also moved the broken package manually to the tested repo which broke all projects in cq. At this time, until we stabilise engine and get a new package into tested, all projects will continue failing cq and no new packages will be moved to the stable repo (tested). if you continue to merge, we not only risk adding more regression but it also makes it more difficult to debug and fix as there are a lot of changes in the queue waiting to be tested and very little resources to run it. Please stop merging on all projects until this is resolved. Thanks, Dafna ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-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/devel@ovirt.org/message/D76I2SGVNK4DEXGBMYE4DTRELJ4B56WU/
[ovirt-devel] Re: please stop merging
Hi, I'm probably missing something here, so please correct me if I'm wrong: 1. CQ is running OST to detect failures and if OST will not pass, RPM with the change will not land in tested repo, right? 2. OST is still running engine on EL7, right? 3. We have dropped EL7 builds from engine on Feb 6th https://gerrit.ovirt.org/106795 So no matter what we push to engine repo, it will not pass the CQ, because it will still be testing the old broken version (because new builds will produce packages only for FC30 and EL8 repos). Am I right or missing something? Right now we are doing our best to make engine running on CentOS 8 (my personal estimation is Friday), so after that we should be able to merge OST patch https://gerrit.ovirt.org/106824 so OST will use EL8 for engine. So unless I'm missing something it doesn't make sense to block merging to engine and its dependencies, because we need to make them running on EL8 and switch engine on EL8 in OST to unblock CQ. Am I right or am I missing something? Regards, Martin On Wed, Feb 12, 2020 at 4:03 PM Dafna Ron wrote: > Hi all, > > Engine has been failing for a while and someone has also moved the broken > package manually to the tested repo which broke all projects in cq. > At this time, until we stabilise engine and get a new package into tested, > all projects will continue failing cq and no new packages will be moved to > the stable repo (tested). > if you continue to merge, we not only risk adding more regression but it > also makes it more difficult to debug and fix as there are a lot of changes > in the queue waiting to be tested and very little resources to run it. > > Please stop merging on all projects until this is resolved. > > Thanks, > Dafna > > > > -- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o. ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-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/devel@ovirt.org/message/4Y3P3QEFUDJSAWAUPXKLS7VZEFUYLI6N/
[ovirt-devel] Re: please stop merging
On Wed, Feb 12, 2020 at 5:03 PM Martin Perina wrote: > Hi, > > I'm probably missing something here, so please correct me if I'm wrong: > > 1. CQ is running OST to detect failures and if OST will not pass, RPM with > the change will not land in tested repo, right? > unless someone manually moves packages into the tested repo - which caused all projects to fail on engine deploy. > > 2. OST is still running engine on EL7, right? > yes > > 3. We have dropped EL7 builds from engine on Feb 6th > https://gerrit.ovirt.org/106795 > So no matter what we push to engine repo, it will not pass the CQ, > because it will still be testing the old broken version (because new builds > will produce packages only for FC30 and EL8 repos). Am I right or missing > something? > > Actually, engine has been failing for more then 4 weeks already on unrelated issues. currently its failing on a package which is deprecated because the change has not passed CQ and the package that is tested is based on some un-merged change. so fixing the issues now, have nothing to do with the missing el8 packages and the longer you wait to fix the failures, the more regressions you will introduce and harder it will be to fix it. At this point, I need to have patch https://gerrit.ovirt.org/#/c/106809/ run in CQ so I can see why its failing. Right now we are doing our best to make engine running on CentOS 8 (my > personal estimation is Friday), so after that we should be able to merge > OST patch https://gerrit.ovirt.org/106824 so OST will use EL8 for engine. > > So unless I'm missing something it doesn't make sense to block merging to > engine and its dependencies, because we need to make them running on EL8 > and switch engine on EL8 in OST to unblock CQ. Am I right or am I missing > something? > lets first get to a point where we are blocked by rl8 related issues instead of merging more changes which we later on cannot track. Lets see what the change is failing as for now, you are blocking all other projects (not just engine and its deps). > Regards, > Martin > > > On Wed, Feb 12, 2020 at 4:03 PM Dafna Ron wrote: > >> Hi all, >> >> Engine has been failing for a while and someone has also moved the broken >> package manually to the tested repo which broke all projects in cq. >> At this time, until we stabilise engine and get a new package into >> tested, all projects will continue failing cq and no new packages will be >> moved to the stable repo (tested). >> if you continue to merge, we not only risk adding more regression but it >> also makes it more difficult to debug and fix as there are a lot of changes >> in the queue waiting to be tested and very little resources to run it. >> >> Please stop merging on all projects until this is resolved. >> >> Thanks, >> Dafna >> >> >> >> > > -- > Martin Perina > Manager, Software Engineering > Red Hat Czech s.r.o. > ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-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/devel@ovirt.org/message/JAD2GZ3MQQ7U3NXWUHPZWUW2LVZEJDZS/
[ovirt-devel] Re: please stop merging
On Wed, Feb 12, 2020 at 6:33 PM Dafna Ron wrote: > > > On Wed, Feb 12, 2020 at 5:03 PM Martin Perina wrote: > >> Hi, >> >> I'm probably missing something here, so please correct me if I'm wrong: >> >> 1. CQ is running OST to detect failures and if OST will not pass, RPM >> with the change will not land in tested repo, right? >> > unless someone manually moves packages into the tested repo - which caused > all projects to fail on engine deploy. > >> >> 2. OST is still running engine on EL7, right? >> > yes > >> >> 3. We have dropped EL7 builds from engine on Feb 6th >> https://gerrit.ovirt.org/106795 >> So no matter what we push to engine repo, it will not pass the CQ, >> because it will still be testing the old broken version (because new builds >> will produce packages only for FC30 and EL8 repos). Am I right or missing >> something? >> >> Actually, engine has been failing for more then 4 weeks already on > unrelated issues. currently its failing on a package which is deprecated > because the change has not passed CQ and the package that is tested is > based on some un-merged change. so fixing the issues now, have nothing to > do with the missing el8 packages and the longer you wait to fix the > failures, the more regressions you will introduce and harder it will be to > fix it. > > At this point, I need to have patch https://gerrit.ovirt.org/#/c/106809/ > run in CQ so I can see why its failing. > Well, there are other fixes after this patch which fixes known issues, so I'm not sure if only this fix will make the OST to run successfully. > Right now we are doing our best to make engine running on CentOS 8 (my >> personal estimation is Friday), so after that we should be able to merge >> OST patch https://gerrit.ovirt.org/106824 so OST will use EL8 for engine. >> > >> So unless I'm missing something it doesn't make sense to block merging to >> engine and its dependencies, because we need to make them running on EL8 >> and switch engine on EL8 in OST to unblock CQ. Am I right or am I missing >> something? >> > > lets first get to a point where we are blocked by rl8 related issues > instead of merging more changes which we later on cannot track. > Lets see what the change is failing as for now, you are blocking all other > projects (not just engine and its deps). > Well maybe, but again I don't believe that we are able to stabilize OST before we get to engine EL8, because since last week there were merged several patches which might have help OST but also several fixes which broke engine on EL7. And all those fixes are mixed. So from my point right now the biggest priority is to make engine running on EL8 asap and only afterwards focus on OST stabilization and fixing other less important dependencies > > > >> Regards, >> Martin >> >> >> On Wed, Feb 12, 2020 at 4:03 PM Dafna Ron wrote: >> >>> Hi all, >>> >>> Engine has been failing for a while and someone has also moved the >>> broken package manually to the tested repo which broke all projects in cq. >>> At this time, until we stabilise engine and get a new package into >>> tested, all projects will continue failing cq and no new packages will be >>> moved to the stable repo (tested). >>> if you continue to merge, we not only risk adding more regression but it >>> also makes it more difficult to debug and fix as there are a lot of changes >>> in the queue waiting to be tested and very little resources to run it. >>> >>> Please stop merging on all projects until this is resolved. >>> >>> Thanks, >>> Dafna >>> >>> >>> >>> >> >> -- >> Martin Perina >> Manager, Software Engineering >> Red Hat Czech s.r.o. >> > -- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o. ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-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/devel@ovirt.org/message/KQG6Q6C7P3D6CXMKCQT3Y5GI735CU3CC/
[ovirt-devel] Re: please stop merging
On Wed, Feb 12, 2020 at 6:38 PM Martin Perina wrote: > > > On Wed, Feb 12, 2020 at 6:33 PM Dafna Ron wrote: > >> >> >> On Wed, Feb 12, 2020 at 5:03 PM Martin Perina wrote: >> >>> Hi, >>> >>> I'm probably missing something here, so please correct me if I'm wrong: >>> >>> 1. CQ is running OST to detect failures and if OST will not pass, RPM >>> with the change will not land in tested repo, right? >>> >> unless someone manually moves packages into the tested repo - which >> caused all projects to fail on engine deploy. >> >>> >>> 2. OST is still running engine on EL7, right? >>> >> yes >> >>> >>> 3. We have dropped EL7 builds from engine on Feb 6th >>> https://gerrit.ovirt.org/106795 >>> So no matter what we push to engine repo, it will not pass the CQ, >>> because it will still be testing the old broken version (because new builds >>> will produce packages only for FC30 and EL8 repos). Am I right or missing >>> something? >>> >>> Actually, engine has been failing for more then 4 weeks already on >> unrelated issues. currently its failing on a package which is deprecated >> because the change has not passed CQ and the package that is tested is >> based on some un-merged change. so fixing the issues now, have nothing to >> do with the missing el8 packages and the longer you wait to fix the >> failures, the more regressions you will introduce and harder it will be to >> fix it. >> >> At this point, I need to have patch https://gerrit.ovirt.org/#/c/106809/ >> run in CQ so I can see why its failing. >> > > Well, there are other fixes after this patch which fixes known issues, so > I'm not sure if only this fix will make the OST to run successfully. > > >> Right now we are doing our best to make engine running on CentOS 8 (my >>> personal estimation is Friday), so after that we should be able to merge >>> OST patch https://gerrit.ovirt.org/106824 so OST will use EL8 for >>> engine. >>> >> >>> So unless I'm missing something it doesn't make sense to block merging >>> to engine and its dependencies, because we need to make them running on EL8 >>> and switch engine on EL8 in OST to unblock CQ. Am I right or am I missing >>> something? >>> >> >> lets first get to a point where we are blocked by rl8 related issues >> instead of merging more changes which we later on cannot track. >> Lets see what the change is failing as for now, you are blocking all >> other projects (not just engine and its deps). >> > > Well maybe, but again I don't believe that we are able to stabilize OST > before we get to engine EL8, because since last week there were merged > several patches which might have help OST but also several fixes which > broke engine on EL7. And all those fixes are mixed. > > So from my point right now the biggest priority is to make engine running > on EL8 asap and only afterwards focus on OST stabilization and fixing other > less important dependencies > OST is not related at all to this and its not about stabilizing OST but about stabilizing engine as these are code issues and not random OST failures. The failures in cq are engine related and the rest of the projects are also failing because a faulty engine package has been introduced to the rest of the projects so everyone are merging "blind" because of the current failures. you can continue merging if you like, but note that all the projects in CQ have no testing coverage at all at this time and you are merging without any CI testing. > Regards, > Martin > > > On Wed, Feb 12, 2020 at 4:03 PM Dafna Ron wrote: > >> Hi all, >> >> Engine has been failing for a while and someone has also moved the broken >> package manually to the tested repo which broke all projects in cq. >> At this time, until we stabilise engine and get a new package into >> tested, all projects will continue failing cq and no new packages will be >> moved to the stable repo (tested). >> if you continue to merge, we not only risk adding more regression but it >> also makes it more difficult to debug and fix as there are a lot of changes >> in the queue waiting to be tested and very little resources to run it. >> >> Please stop merging on all projects until this is resolved. >> >> Thanks, >> Dafna >> >> >> >> > > -- > Martin Perina > Manager, Software Engineering > Red Hat Czech s.r.o. > > > -- > Martin Perina > Manager, Software Engineering > Red Hat Czech s.r.o. > ___ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-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/devel@ovirt.org/message/OJXQXGU4KG6WLFKNK2UAYPYXK4UQTGR6/
[ovirt-devel] Re: master CQ fails due to missing ovirt-host-deploy
On 12 Feb 2020, at 08:02, Martin Perina wrote: On Wed, Feb 12, 2020 at 11:07 AM Dafna Ron wrote: > Then another possibility is that the package is now suppose to be coming > from somewhere else and its not available? > where is it suppose to come from? from what I understood, it should be > deployed by ansible, is that correct? > I can see an abandoned patch but cannot see a patch that was merged for > ansible: > https://gerrit.ovirt.org/#/q/ovirt-host-deploy > > It seems patch: https://gerrit.ovirt.org/#/c/102959/ was abandoned for no > activity - was anything else actually merged on ansible side? > > Thanks, > Dafna > > > On Wed, Feb 12, 2020 at 9:47 AM Yedidyah Bar David > wrote: > >> On Wed, Feb 12, 2020 at 11:39 AM Dafna Ron wrote: >> > >> > this is the current package in tested: >> ovirt-engine-0:4.2.0-0.0.master.20170712084142.git63b81ef.el7.centos.noarch >> and since all projects are now failing on this, it means the engine package >> in tested is a broken package. >> > what I don't understand is how can CQ mark engine as failed since this >> patch: https://gerrit.ovirt.org/#/c/104391/ which is 4 weeks ago but I >> can see a new package in tested since 06-02-2020 with no passing cq test >> for ovirt-engine. >> > If anyone is moving packages manually to tested they are breaking all >> projects by introducing broken packages. >> > >> > As the package in tested is now broken, we should start fixing the code >> on each failing issue. >> > for now, the main thing that is failing is that we are looking for a >> package that no longer exists. >> > Didi, is it possible its the typo Marcin was commenting on in this >> patch: https://gerrit.ovirt.org/#/c/106797/ >> >> I already addressed this, >> > https://gerrit.ovirt.org/106809 was a fix for that issue, if it still didn't pass the CQ, then let's pass the engine build this patch through CQ manually So the thing is that all that is moot since we stopped building el7 engine. It’s very unfortunate that the last el7 build is failing so early, but in reality OST hasn’t been passing for weeks. We absolutely need to focus to getting it up and running on el8 asap. It’s been really close to a working state right before the el7 removal >> > >> > Thanks, >> > Dafna >> > >> > >> > >> > >> > >> > >> > >> > On Tue, Feb 11, 2020 at 9:03 AM Yedidyah Bar David >> wrote: >> >> >> >> On Tue, Feb 11, 2020 at 10:22 AM Dusan Fodor >> wrote: >> >> > >> >> > Hello, >> >> > master CQ is failing on initialize_engine due to missing >> ovirt-host-deploy dependency. >> >> > >> >> > [ INFO ] Checking for an update for Setup... >> >> > [ ERROR ] Yum Cannot queue package ovirt-host-deploy: Package >> ovirt-host-deploy cannot be found >> >> > >> >> > >> >> > I was under the impression that engine-setup should not require it >> anymore, but it seems the related patch [1] doesn't work as intended. >> Perhaps Marcin's comment there explains why? Can you please check this? >> >> >> >> How can I know which engine build was used for [2]? >> >> >> >> Checking lago.log there, I see: >> >> >> >> Installed: >> >> net-snmp.x86_64 1:5.7.2-43.el7_7.3 >> >> ntp.x86_64 0:4.2.6p5-29.el7.centos >> >> otopi-debug-plugins.noarch 0:1.9.0-1.el7 >> >> ovirt-engine.noarch 0:4.4.0-0.0.master.20200206140618.gitff1f0b4.el7 >> >> ovirt-engine-extension-aaa-ldap.noarch >> 0:1.3.11-0.0.master.gitb9a171f.el7 >> >> ovirt-engine-extension-aaa-ldap-setup.noarch >> >> 0:1.3.11-0.0.master.gitb9a171f.el7 >> >> ovirt-log-collector.noarch >> 0:4.4.0-0.0.master.20191122133512.gitfc29382.el7 >> >> >> >> ff1f0b4 is a hash of a not-yet-merged patch: >> >> >> >> https://gerrit.ovirt.org/106794 >> >> >> >> It should be rebased. >> >> >> >> Also not sure how the change-queue-tester uses a not-merged-yet engine. >> >> >> >> (And also, [1] is not enough, Marcin Sobczyk later pushed a fix for >> >> it, https://gerrit.ovirt.org/106809 ). >> >> here ^^. Already merged as well. >> >> >> >> >> > Job example [2] >> >> > Thanks >> >> > >> >> > [1] https://gerrit.ovirt.org/#/c/106797/ >> >> > [2] >> https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change-queue-tester/19724/testReport/(root)/001_initialize_engine/initialize_engine/ >> >> >> >> >> >> >> >> -- >> >> Didi >> >> ___ >> >> Devel mailing list -- devel@ovirt.org >> >> To unsubscribe send an email to devel-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/devel@ovirt.org/message/I5NOUPCLFXQDKDBHNIQC2XL56YZYLGOT/ >> >> >> >> -- >> Didi >> >> ___ > Devel mailing list -- devel@ovirt.org > To unsubscribe send an email to devel-le...@ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/abou
[ovirt-devel] Re: master CQ fails due to missing ovirt-host-deploy
On 12 Feb 2020, at 09:26, Dafna Ron wrote: The problem is that the package which is currently in tested is an un-authorised package that is actually breaking all the projects and not just engine. it has been transferred manually as I cannot see a passing ovirt-engine cq test for over a month and the package that is there is pointing at an un-merged change. And it’s only possible to fix that now manually since we no longer build el7 in CI. I’m not sure it’s worth the effort now when we are, hopefully, real close on having working el8 deployment. All the other suites need to adapt to el8 engine as well We should not touch CQ manually ever as doing that breaks it completely and makes it more difficult to find and fix any other issues and breaks all other projects as well. I have re-merged the fix that you pointed to to see what is causing it to fail CQ and will update once it goes through cq and we can see what other issues we have. enabling el7 builds? If yes then it should really help. For OST though, you’d also need to fix(or comment out) the ovf import test Thanks, michal Thanks, Dafna On Wed, Feb 12, 2020 at 1:02 PM Martin Perina wrote: > > > On Wed, Feb 12, 2020 at 11:07 AM Dafna Ron wrote: > >> Then another possibility is that the package is now suppose to be coming >> from somewhere else and its not available? >> where is it suppose to come from? from what I understood, it should be >> deployed by ansible, is that correct? >> I can see an abandoned patch but cannot see a patch that was merged for >> ansible: >> https://gerrit.ovirt.org/#/q/ovirt-host-deploy >> >> It seems patch: https://gerrit.ovirt.org/#/c/102959/ was abandoned for >> no activity - was anything else actually merged on ansible side? >> >> Thanks, >> Dafna >> >> >> On Wed, Feb 12, 2020 at 9:47 AM Yedidyah Bar David >> wrote: >> >>> On Wed, Feb 12, 2020 at 11:39 AM Dafna Ron wrote: >>> > >>> > this is the current package in tested: >>> ovirt-engine-0:4.2.0-0.0.master.20170712084142.git63b81ef.el7.centos.noarch >>> and since all projects are now failing on this, it means the engine package >>> in tested is a broken package. >>> > what I don't understand is how can CQ mark engine as failed since this >>> patch: https://gerrit.ovirt.org/#/c/104391/ which is 4 weeks ago but I >>> can see a new package in tested since 06-02-2020 with no passing cq test >>> for ovirt-engine. >>> > If anyone is moving packages manually to tested they are breaking all >>> projects by introducing broken packages. >>> > >>> > As the package in tested is now broken, we should start fixing the >>> code on each failing issue. >>> > for now, the main thing that is failing is that we are looking for a >>> package that no longer exists. >>> > Didi, is it possible its the typo Marcin was commenting on in this >>> patch: https://gerrit.ovirt.org/#/c/106797/ >>> >>> I already addressed this, >>> >> > https://gerrit.ovirt.org/106809 was a fix for that issue, if it still > didn't pass the CQ, then let's pass the engine build this patch through CQ > manually > > >>> > >>> > Thanks, >>> > Dafna >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > On Tue, Feb 11, 2020 at 9:03 AM Yedidyah Bar David >>> wrote: >>> >> >>> >> On Tue, Feb 11, 2020 at 10:22 AM Dusan Fodor >>> wrote: >>> >> > >>> >> > Hello, >>> >> > master CQ is failing on initialize_engine due to missing >>> ovirt-host-deploy dependency. >>> >> > >>> >> > [ INFO ] Checking for an update for Setup... >>> >> > [ ERROR ] Yum Cannot queue package ovirt-host-deploy: Package >>> ovirt-host-deploy cannot be found >>> >> > >>> >> > >>> >> > I was under the impression that engine-setup should not require it >>> anymore, but it seems the related patch [1] doesn't work as intended. >>> Perhaps Marcin's comment there explains why? Can you please check this? >>> >> >>> >> How can I know which engine build was used for [2]? >>> >> >>> >> Checking lago.log there, I see: >>> >> >>> >> Installed: >>> >> net-snmp.x86_64 1:5.7.2-43.el7_7.3 >>> >> ntp.x86_64 0:4.2.6p5-29.el7.centos >>> >> otopi-debug-plugins.noarch 0:1.9.0-1.el7 >>> >> ovirt-engine.noarch 0:4.4.0-0.0.master.20200206140618.gitff1f0b4.el7 >>> >> ovirt-engine-extension-aaa-ldap.noarch >>> 0:1.3.11-0.0.master.gitb9a171f.el7 >>> >> ovirt-engine-extension-aaa-ldap-setup.noarch >>> >> 0:1.3.11-0.0.master.gitb9a171f.el7 >>> >> ovirt-log-collector.noarch >>> 0:4.4.0-0.0.master.20191122133512.gitfc29382.el7 >>> >> >>> >> ff1f0b4 is a hash of a not-yet-merged patch: >>> >> >>> >> https://gerrit.ovirt.org/106794 >>> >> >>> >> It should be rebased. >>> >> >>> >> Also not sure how the change-queue-tester uses a not-merged-yet >>> engine. >>> >> >>> >> (And also, [1] is not enough, Marcin Sobczyk later pushed a fix for >>> >> it, https://gerrit.ovirt.org/106809 ). >>> >>> here ^^. Already merged as well. >>> >>> >> >>> >> > Job example [2] >>> >> > Thanks >>> >> > >>> >> > [1] https://gerrit.ovirt.org/#/c/106797/ >>> >> > [2] >>> https://jenkins.ovir
[ovirt-devel] Re: please stop merging
On 12 Feb 2020, at 13:48, Dafna Ron wrote: On Wed, Feb 12, 2020 at 6:38 PM Martin Perina wrote: > > > On Wed, Feb 12, 2020 at 6:33 PM Dafna Ron wrote: > >> >> >> On Wed, Feb 12, 2020 at 5:03 PM Martin Perina wrote: >> >>> Hi, >>> >>> I'm probably missing something here, so please correct me if I'm wrong: >>> >>> 1. CQ is running OST to detect failures and if OST will not pass, RPM >>> with the change will not land in tested repo, right? >>> >> unless someone manually moves packages into the tested repo - which >> caused all projects to fail on engine deploy. >> >>> >>> 2. OST is still running engine on EL7, right? >>> >> yes >> >>> >>> 3. We have dropped EL7 builds from engine on Feb 6th >>> https://gerrit.ovirt.org/106795 >>> So no matter what we push to engine repo, it will not pass the CQ, >>> because it will still be testing the old broken version (because new builds >>> will produce packages only for FC30 and EL8 repos). Am I right or missing >>> something? >>> >>> Actually, engine has been failing for more then 4 weeks already on >> unrelated issues. currently its failing on a package which is deprecated >> because the change has not passed CQ and the package that is tested is >> based on some un-merged change. so fixing the issues now, have nothing to >> do with the missing el8 packages and the longer you wait to fix the >> failures, the more regressions you will introduce and harder it will be to >> fix it. >> >> At this point, I need to have patch https://gerrit.ovirt.org/#/c/106809/ >> run in CQ so I can see why its failing. >> > > Well, there are other fixes after this patch which fixes known issues, so > I'm not sure if only this fix will make the OST to run successfully. > > >> Right now we are doing our best to make engine running on CentOS 8 (my >>> personal estimation is Friday), so after that we should be able to merge >>> OST patch https://gerrit.ovirt.org/106824 so OST will use EL8 for >>> engine. >>> >> >>> So unless I'm missing something it doesn't make sense to block merging >>> to engine and its dependencies, because we need to make them running on EL8 >>> and switch engine on EL8 in OST to unblock CQ. Am I right or am I missing >>> something? >>> >> >> lets first get to a point where we are blocked by rl8 related issues >> instead of merging more changes which we later on cannot track. >> Lets see what the change is failing as for now, you are blocking all >> other projects (not just engine and its deps). >> > > Well maybe, but again I don't believe that we are able to stabilize OST > before we get to engine EL8, because since last week there were merged > several patches which might have help OST but also several fixes which > broke engine on EL7. And all those fixes are mixed. > > So from my point right now the biggest priority is to make engine running > on EL8 asap and only afterwards focus on OST stabilization and fixing other > less important dependencies > However we should (engine maintainers should) be cautious about merging other stuff unrelated to el8. If it’s not essential I would suggest to postpone merging exactly for that reason that we don’t have any validation beyond unit tests. OST is not related at all to this and its not about stabilizing OST but about stabilizing engine as these are code issues and not random OST failures. It’s related in a sense that as soon as we get OST on el8 running we can sleep a bit better when merging engine patches. The failures in cq are engine related and the rest of the projects are also failing because a faulty engine package has been introduced to the rest of the projects so everyone are merging "blind" because of the current failures. You’re right about the other projects, but we can as well just go back to a previous build then. Just remove the last ovirt-engine manually? you can continue merging if you like, but note that all the projects in CQ have no testing coverage at all at this time and you are merging without any CI testing. > Regards, > Martin > > > On Wed, Feb 12, 2020 at 4:03 PM Dafna Ron wrote: > >> Hi all, >> >> Engine has been failing for a while and someone has also moved the broken >> package manually to the tested repo which broke all projects in cq. >> At this time, until we stabilise engine and get a new package into >> tested, all projects will continue failing cq and no new packages will be >> moved to the stable repo (tested). >> if you continue to merge, we not only risk adding more regression but it >> also makes it more difficult to debug and fix as there are a lot of changes >> in the queue waiting to be tested and very little resources to run it. >> >> Please stop merging on all projects until this is resolved. >> >> Thanks, >> Dafna >> >> >> >> > > -- > Martin Perina > Manager, Software Engineering > Red Hat Czech s.r.o. > > > -- > Martin Perina > Manager, Software Engineering > Red Hat Czech s.r.o. > ___ Devel mailing list -- devel
