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/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
>> > 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/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
>> >> > 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/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
_______________________________________________
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/THY5E3XBWD52WJMMYSZ4RSCC75ESIPPE/