I've executed http://jenkins.ovirt.org/job/ovirt-system-tests_manual/3053/parameters/ using http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... as customer repo. The custom repo has vdsm-4.20.36-11.git9f9bbcc.el7.x86_64.rpm which I expected would be pulled onto ost hosts. However http://jenkins.ovirt.org/job/ovirt-system-tests_manual/3053/artifact/exporte... shows that this was not the case. Any idea why is that?
On 8 August 2018 at 22:53, Dan Kenigsberg <danken@redhat.com> wrote:
I've executed http://jenkins.ovirt.org/job/ovirt-system-tests_manual/ 3053/parameters/ using http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on- demand-el7-x86_64/44/artifact/exported-artifacts/ as customer repo.
The custom repo has vdsm-4.20.36-11.git9f9bbcc.el7.x86_64.rpm which I expected would be pulled onto ost hosts. However http://jenkins.ovirt.org/job/ovirt-system-tests_manual/ 3053/artifact/exported-artifacts/tests.test_vm_ operations/lago-network-suite-4-2-host-0/_var_log/yum.log shows that this was not the case.
Any idea why is that?
I can see the following in lago.log (in the section that includes the repoman log): 2018-08-08 18:47:02,357::INFO::repoman.common.repo::Resolving artifact source http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... 2018-08-08 18:47:02,493::INFO::repoman.common.sources.jenkins::Parsing jenkins URL: http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... 2018-08-08 18:47:02,493::WARNING::root:: No artifacts found 2018-08-08 18:47:02,493::INFO::root:: Done The fact that the log says 'Parsing jenkins URL' means that repoman properly detects that it is a URL to a Jenkins build, additionally when I run the following locally it seems to download the packages just fine: repoman ~/tmp/repo add http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... So this looks like a repoman bug. Adding Anton. @Dan - can you just retry?
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/PQHTXDZ6SLWI53FRHIOE5HDUI5ZBM4Z6/
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
On Thu, Aug 9, 2018 at 8:29 AM, Barak Korren <bkorren@redhat.com> wrote:
On 8 August 2018 at 22:53, Dan Kenigsberg <danken@redhat.com> wrote:
I've executed http://jenkins.ovirt.org/job/ovirt-system-tests_manual/3053/parameters/ using http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... as customer repo.
The custom repo has vdsm-4.20.36-11.git9f9bbcc.el7.x86_64.rpm which I expected would be pulled onto ost hosts. However
http://jenkins.ovirt.org/job/ovirt-system-tests_manual/3053/artifact/exporte... shows that this was not the case.
Any idea why is that?
I can see the following in lago.log (in the section that includes the repoman log):
2018-08-08 18:47:02,357::INFO::repoman.common.repo::Resolving artifact source http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... 2018-08-08 18:47:02,493::INFO::repoman.common.sources.jenkins::Parsing jenkins URL: http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... 2018-08-08 18:47:02,493::WARNING::root:: No artifacts found 2018-08-08 18:47:02,493::INFO::root:: Done
The fact that the log says 'Parsing jenkins URL' means that repoman properly detects that it is a URL to a Jenkins build, additionally when I run the following locally it seems to download the packages just fine:
repoman ~/tmp/repo add http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4...
So this looks like a repoman bug. Adding Anton.
@Dan - can you just retry?
I did try again, in https://jenkins.ovirt.org/job/ovirt-system-tests_manual/3054 which failed again. However, this time it has an empty lago.log.
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/PQHTXDZ6SLWI53...
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
Hello Barak, Dan. Repoman indeed expect the link to jenkins job only and cannot work with specific artifact path. So I think the last rerun [1] with just http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... worked on repoman side as I see from lago log, the artifacts were detected and downloaded: 2018-08-08 19:58:14,067::INFO::root::Saving /dev/shm/ost/deployment-network-suite-4.2/default/internal_repo/default/el7/x86_64/vdsm-4.20.36-11.git9f9bbcc.el7.x86_64.rpm 2018-08-08 19:58:14,068::INFO::root::Saving /dev/shm/ost/deployment-network-suite-4.2/default/internal_repo/default/el7/noarch/vdsm-api-4.20.36-11.git9f9bbcc.el7.noarch.rpm … That matches artifact names produced by the job Dan passed as the parameter: vdsm-4.20.36-11.git9f9bbcc.el7.x86_64.rpm vdsm-api-4.20.36-11.git9f9bbcc.el7.noarch.rpm ... [1] https://jenkins.ovirt.org/job/ovirt-system-tests_manual/3054/ On 9 August 2018 at 09:25:40, Dan Kenigsberg (danken@redhat.com) wrote:
On Thu, Aug 9, 2018 at 8:29 AM, Barak Korren wrote:
On 8 August 2018 at 22:53, Dan Kenigsberg wrote:
I've executed http://jenkins.ovirt.org/job/ovirt-system-tests_manual/3053/parameters/ using http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... as customer repo.
The custom repo has vdsm-4.20.36-11.git9f9bbcc.el7.x86_64.rpm which I expected would be pulled onto ost hosts. However
http://jenkins.ovirt.org/job/ovirt-system-tests_manual/3053/artifact/exporte... shows that this was not the case.
Any idea why is that?
I can see the following in lago.log (in the section that includes the repoman log):
2018-08-08 18:47:02,357::INFO::repoman.common.repo::Resolving artifact source http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... 2018-08-08 18:47:02,493::INFO::repoman.common.sources.jenkins::Parsing jenkins URL: http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... 2018-08-08 18:47:02,493::WARNING::root:: No artifacts found 2018-08-08 18:47:02,493::INFO::root:: Done
The fact that the log says 'Parsing jenkins URL' means that repoman properly detects that it is a URL to a Jenkins build, additionally when I run the following locally it seems to download the packages just fine:
repoman ~/tmp/repo add http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4...
So this looks like a repoman bug. Adding Anton.
@Dan - can you just retry?
I did try again, in https://jenkins.ovirt.org/job/ovirt-system-tests_manual/3054 which failed again. However, this time it has an empty lago.log.
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/PQHTXDZ6SLWI53...
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
On Thu, Aug 9, 2018 at 12:41 PM, Anton Marchukov <amarchuk@redhat.com> wrote:
Hello Barak, Dan.
Repoman indeed expect the link to jenkins job only and cannot work with specific artifact path. So I think the last rerun [1] with just http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... worked on repoman side as I see from lago log, the artifacts were detected and downloaded:
2018-08-08 19:58:14,067::INFO::root::Saving /dev/shm/ost/deployment-network-suite-4.2/default/internal_repo/default/el7/x86_64/vdsm-4.20.36-11.git9f9bbcc.el7.x86_64.rpm 2018-08-08 19:58:14,068::INFO::root::Saving /dev/shm/ost/deployment-network-suite-4.2/default/internal_repo/default/el7/noarch/vdsm-api-4.20.36-11.git9f9bbcc.el7.noarch.rpm …
That matches artifact names produced by the job Dan passed as the parameter:
vdsm-4.20.36-11.git9f9bbcc.el7.x86_64.rpm vdsm-api-4.20.36-11.git9f9bbcc.el7.noarch.rpm ...
[1] https://jenkins.ovirt.org/job/ovirt-system-tests_manual/3054/
Darn, you are right. The second job did take the correct vdsm. It failed due to a production bug that we need to fix.
On 9 August 2018 at 09:25:40, Dan Kenigsberg (danken@redhat.com) wrote:
On Thu, Aug 9, 2018 at 8:29 AM, Barak Korren wrote:
On 8 August 2018 at 22:53, Dan Kenigsberg wrote:
I've executed http://jenkins.ovirt.org/job/ovirt-system-tests_manual/3053/parameters/ using http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... as customer repo.
The custom repo has vdsm-4.20.36-11.git9f9bbcc.el7.x86_64.rpm which I expected would be pulled onto ost hosts. However
http://jenkins.ovirt.org/job/ovirt-system-tests_manual/3053/artifact/exporte... shows that this was not the case.
Any idea why is that?
I can see the following in lago.log (in the section that includes the repoman log):
2018-08-08 18:47:02,357::INFO::repoman.common.repo::Resolving artifact source http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... 2018-08-08 18:47:02,493::INFO::repoman.common.sources.jenkins::Parsing jenkins URL: http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... 2018-08-08 18:47:02,493::WARNING::root:: No artifacts found 2018-08-08 18:47:02,493::INFO::root:: Done
The fact that the log says 'Parsing jenkins URL' means that repoman properly detects that it is a URL to a Jenkins build, additionally when I run the following locally it seems to download the packages just fine:
repoman ~/tmp/repo add http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4...
So this looks like a repoman bug. Adding Anton.
@Dan - can you just retry?
I did try again, in https://jenkins.ovirt.org/job/ovirt-system-tests_manual/3054 which failed again. However, this time it has an empty lago.log.
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/PQHTXDZ6SLWI53...
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
I found out what happened here in the 1st run. The build job started at* 18:41:26* and finished at* 18:48:19* while artifacts were archived at* 18:48:18* The test job started at* 18:44:13*, finished at* 19:24:10*, so it had reached the point of trying to download the RPMs at* 18:46:36* so almost two minutes before they actually became available.... (All times are in UTC) Dan, you need to wait for the build job to finish before you can launch the test job... On 9 August 2018 at 12:46, Dan Kenigsberg <danken@redhat.com> wrote:
Hello Barak, Dan.
Repoman indeed expect the link to jenkins job only and cannot work with specific artifact path. So I think the last rerun [1] with just http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on- demand-el7-x86_64/44/ worked on repoman side as I see from lago log, the artifacts were detected and downloaded:
2018-08-08 19:58:14,067::INFO::root::Saving /dev/shm/ost/deployment-network-suite-4.2/default/ internal_repo/default/el7/x86_64/vdsm-4.20.36-11.git9f9bbcc.el7.x86_64.rpm 2018-08-08 19:58:14,068::INFO::root::Saving /dev/shm/ost/deployment-network-suite-4.2/default/ internal_repo/default/el7/noarch/vdsm-api-4.20.36-11. git9f9bbcc.el7.noarch.rpm …
That matches artifact names produced by the job Dan passed as the
On Thu, Aug 9, 2018 at 12:41 PM, Anton Marchukov <amarchuk@redhat.com> wrote: parameter:
vdsm-4.20.36-11.git9f9bbcc.el7.x86_64.rpm vdsm-api-4.20.36-11.git9f9bbcc.el7.noarch.rpm ...
[1] https://jenkins.ovirt.org/job/ovirt-system-tests_manual/3054/
Darn, you are right. The second job did take the correct vdsm. It failed due to a production bug that we need to fix.
On 9 August 2018 at 09:25:40, Dan Kenigsberg (danken@redhat.com) wrote:
On Thu, Aug 9, 2018 at 8:29 AM, Barak Korren wrote:
On 8 August 2018 at 22:53, Dan Kenigsberg wrote:
I've executed http://jenkins.ovirt.org/job/ovirt-system-tests_manual/
using http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on- demand-el7-x86_64/44/artifact/exported-artifacts/ as customer repo.
The custom repo has vdsm-4.20.36-11.git9f9bbcc.el7.x86_64.rpm which I expected would be pulled onto ost hosts. However
http://jenkins.ovirt.org/job/ovirt-system-tests_manual/ 3053/artifact/exported-artifacts/tests.test_vm_ operations/lago-network-suite-4-2-host-0/_var_log/yum.log shows that this was not the case.
Any idea why is that?
I can see the following in lago.log (in the section that includes the repoman log):
2018-08-08 18:47:02,357::INFO::repoman.common.repo::Resolving artifact source http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on- demand-el7-x86_64/44/ 2018-08-08 18:47:02,493::INFO::repoman.common.sources.jenkins:: Parsing jenkins URL: http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on- demand-el7-x86_64/44/ 2018-08-08 18:47:02,493::WARNING::root:: No artifacts found 2018-08-08 18:47:02,493::INFO::root:: Done
The fact that the log says 'Parsing jenkins URL' means that repoman
detects that it is a URL to a Jenkins build, additionally when I run
3053/parameters/ properly the
following locally it seems to download the packages just fine:
repoman ~/tmp/repo add http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on- demand-el7-x86_64/44/
So this looks like a repoman bug. Adding Anton.
@Dan - can you just retry?
I did try again, in https://jenkins.ovirt.org/job/ovirt-system-tests_manual/3054 which failed again. However, this time it has an empty lago.log.
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/
PQHTXDZ6SLWI53FRHIOE5HDUI5ZBM4Z6/
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
Thanks, Barak, for finding out my PEBCAK, and sorry for the noise. This might be a very good moment to request a "ci please ost" which would build a project, and on success shoot it into OST. This is a very typical use case, which does not seem terribly hard to implement with a jenkins job, and would make life easier to me and the other developers who love and depend on oVirt CI. On Thu, Aug 9, 2018 at 1:36 PM, Barak Korren <bkorren@redhat.com> wrote:
I found out what happened here in the 1st run.
The build job started at 18:41:26 and finished at 18:48:19 while artifacts were archived at 18:48:18
The test job started at 18:44:13, finished at 19:24:10, so it had reached the point of trying to download the RPMs at 18:46:36 so almost two minutes before they actually became available....
(All times are in UTC)
Dan, you need to wait for the build job to finish before you can launch the test job...
On 9 August 2018 at 12:46, Dan Kenigsberg <danken@redhat.com> wrote:
On Thu, Aug 9, 2018 at 12:41 PM, Anton Marchukov <amarchuk@redhat.com> wrote:
Hello Barak, Dan.
Repoman indeed expect the link to jenkins job only and cannot work with specific artifact path. So I think the last rerun [1] with just
http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... worked on repoman side as I see from lago log, the artifacts were detected and downloaded:
2018-08-08 19:58:14,067::INFO::root::Saving
/dev/shm/ost/deployment-network-suite-4.2/default/internal_repo/default/el7/x86_64/vdsm-4.20.36-11.git9f9bbcc.el7.x86_64.rpm 2018-08-08 19:58:14,068::INFO::root::Saving
/dev/shm/ost/deployment-network-suite-4.2/default/internal_repo/default/el7/noarch/vdsm-api-4.20.36-11.git9f9bbcc.el7.noarch.rpm …
That matches artifact names produced by the job Dan passed as the parameter:
vdsm-4.20.36-11.git9f9bbcc.el7.x86_64.rpm vdsm-api-4.20.36-11.git9f9bbcc.el7.noarch.rpm ...
[1] https://jenkins.ovirt.org/job/ovirt-system-tests_manual/3054/
Darn, you are right. The second job did take the correct vdsm. It failed due to a production bug that we need to fix.
On 9 August 2018 at 09:25:40, Dan Kenigsberg (danken@redhat.com) wrote:
On Thu, Aug 9, 2018 at 8:29 AM, Barak Korren wrote:
On 8 August 2018 at 22:53, Dan Kenigsberg wrote:
I've executed
http://jenkins.ovirt.org/job/ovirt-system-tests_manual/3053/parameters/ using
http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... as customer repo.
The custom repo has vdsm-4.20.36-11.git9f9bbcc.el7.x86_64.rpm which I expected would be pulled onto ost hosts. However
http://jenkins.ovirt.org/job/ovirt-system-tests_manual/3053/artifact/exporte... shows that this was not the case.
Any idea why is that?
I can see the following in lago.log (in the section that includes the repoman log):
2018-08-08 18:47:02,357::INFO::repoman.common.repo::Resolving artifact source
http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... 2018-08-08 18:47:02,493::INFO::repoman.common.sources.jenkins::Parsing jenkins URL:
http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... 2018-08-08 18:47:02,493::WARNING::root:: No artifacts found 2018-08-08 18:47:02,493::INFO::root:: Done
The fact that the log says 'Parsing jenkins URL' means that repoman properly detects that it is a URL to a Jenkins build, additionally when I run the following locally it seems to download the packages just fine:
repoman ~/tmp/repo add
http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4...
So this looks like a repoman bug. Adding Anton.
@Dan - can you just retry?
I did try again, in https://jenkins.ovirt.org/job/ovirt-system-tests_manual/3054 which failed again. However, this time it has an empty lago.log.
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/PQHTXDZ6SLWI53...
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
On Thu, Aug 9, 2018 at 10:10 PM Dan Kenigsberg <danken@redhat.com> wrote:
Thanks, Barak, for finding out my PEBCAK, and sorry for the noise.
This might be a very good moment to request a "ci please ost" which would build a project, and on success shoot it into OST. This is a very typical use case, which does not seem terribly hard to implement with a jenkins job, and would make life easier to me and the other developers who love and depend on oVirt CI.
Yes please!
I found out what happened here in the 1st run.
The build job started at 18:41:26 and finished at 18:48:19 while artifacts were archived at 18:48:18
The test job started at 18:44:13, finished at 19:24:10, so it had reached the point of trying to download the RPMs at 18:46:36 so almost two minutes before they actually became available....
(All times are in UTC)
Dan, you need to wait for the build job to finish before you can launch
test job...
On 9 August 2018 at 12:46, Dan Kenigsberg <danken@redhat.com> wrote:
On Thu, Aug 9, 2018 at 12:41 PM, Anton Marchukov <amarchuk@redhat.com> wrote:
Hello Barak, Dan.
Repoman indeed expect the link to jenkins job only and cannot work with specific artifact path. So I think the last rerun [1] with just
http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4...
worked on repoman side as I see from lago log, the artifacts were detected and downloaded:
2018-08-08 19:58:14,067::INFO::root::Saving
/dev/shm/ost/deployment-network-suite-4.2/default/internal_repo/default/el7/x86_64/vdsm-4.20.36-11.git9f9bbcc.el7.x86_64.rpm
2018-08-08 19:58:14,068::INFO::root::Saving
/dev/shm/ost/deployment-network-suite-4.2/default/internal_repo/default/el7/noarch/vdsm-api-4.20.36-11.git9f9bbcc.el7.noarch.rpm
…
That matches artifact names produced by the job Dan passed as the parameter:
vdsm-4.20.36-11.git9f9bbcc.el7.x86_64.rpm vdsm-api-4.20.36-11.git9f9bbcc.el7.noarch.rpm ...
[1] https://jenkins.ovirt.org/job/ovirt-system-tests_manual/3054/
Darn, you are right. The second job did take the correct vdsm. It failed due to a production bug that we need to fix.
On 9 August 2018 at 09:25:40, Dan Kenigsberg (danken@redhat.com)
wrote:
On Thu, Aug 9, 2018 at 8:29 AM, Barak Korren wrote:
On 8 August 2018 at 22:53, Dan Kenigsberg wrote: > > I've executed > >
http://jenkins.ovirt.org/job/ovirt-system-tests_manual/3053/parameters/
> using > > http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... > as customer repo. > > The custom repo has vdsm-4.20.36-11.git9f9bbcc.el7.x86_64.rpm which > I > expected would be pulled onto ost hosts. However > > > http://jenkins.ovirt.org/job/ovirt-system-tests_manual/3053/artifact/exporte... > shows that this was not the case. > > Any idea why is that?
I can see the following in lago.log (in the section that includes
On Thu, Aug 9, 2018 at 1:36 PM, Barak Korren <bkorren@redhat.com> wrote: the the
repoman log):
2018-08-08 18:47:02,357::INFO::repoman.common.repo::Resolving artifact source
http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4...
2018-08-08 18:47:02,493::INFO::repoman.common.sources.jenkins::Parsing jenkins URL:
http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4...
2018-08-08 18:47:02,493::WARNING::root:: No artifacts found 2018-08-08 18:47:02,493::INFO::root:: Done
The fact that the log says 'Parsing jenkins URL' means that repoman properly detects that it is a URL to a Jenkins build, additionally when I run the following locally it seems to download the packages just fine:
repoman ~/tmp/repo add
http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4...
So this looks like a repoman bug. Adding Anton.
@Dan - can you just retry?
I did try again, in https://jenkins.ovirt.org/job/ovirt-system-tests_manual/3054 which failed again. However, this time it has an empty lago.log.
> > _______________________________________________ > Devel mailing list -- devel@ovirt.org > To unsubscribe send an email to devel-leave@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/PQHTXDZ6SLWI53...
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/THY5E3XBWD52WJ...
Actually adding Anton this time. On Thu, Aug 9, 2018 at 8:30 AM Barak Korren <bkorren@redhat.com> wrote:
On 8 August 2018 at 22:53, Dan Kenigsberg <danken@redhat.com> wrote:
I've executed http://jenkins.ovirt.org/job/ovirt-system-tests_manual/3053/parameters/ using http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... as customer repo.
The custom repo has vdsm-4.20.36-11.git9f9bbcc.el7.x86_64.rpm which I expected would be pulled onto ost hosts. However
http://jenkins.ovirt.org/job/ovirt-system-tests_manual/3053/artifact/exporte... shows that this was not the case.
Any idea why is that?
I can see the following in lago.log (in the section that includes the repoman log):
2018-08-08 18:47:02,357::INFO::repoman.common.repo::Resolving artifact source http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... 2018-08-08 <http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/44/%0D2018-08-08> 18:47:02,493::INFO::repoman.common.sources.jenkins::Parsing jenkins URL: http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4... 2018-08-08 <http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/44/%0D2018-08-08> 18:47:02,493::WARNING::root:: No artifacts found 2018-08-08 18:47:02,493::INFO::root:: Done
The fact that the log says 'Parsing jenkins URL' means that repoman properly detects that it is a URL to a Jenkins build, additionally when I run the following locally it seems to download the packages just fine:
repoman ~/tmp/repo add http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on-demand-el7-x86_64/4...
So this looks like a repoman bug. Adding Anton.
@Dan - can you just retry?
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/PQHTXDZ6SLWI53...
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted _______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/2F7XQSVQZDD76W...
-- Eyal edri MANAGER RHV DevOps EMEA VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)
participants (5)
-
Anton Marchukov -
Barak Korren -
Dan Kenigsberg -
Eyal Edri -
Nir Soffer