[ovirt-devel] Re: repoman glitch?

2018-08-09 Thread Nir Soffer 
On Thu, Aug 9, 2018 at 10:10 PM Dan Kenigsberg  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!


>
> On Thu, Aug 9, 2018 at 1:36 PM, Barak Korren  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  wrote:
> >>
> >> On Thu, Aug 9, 2018 at 12:41 PM, Anton Marchukov 
> >> 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 (dan...@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

[ovirt-devel] Re: repoman glitch?

2018-08-09 Thread Dan Kenigsberg 
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  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  wrote:
>>
>> On Thu, Aug 9, 2018 at 12:41 PM, Anton Marchukov 
>> 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 (dan...@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-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/PQHTXDZ6SLWI53FRHIOE5HDUI5ZBM4Z6/
>> >> >
>> >> >

[ovirt-devel] Re: repoman glitch?

2018-08-09 Thread Barak Korren 
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  wrote:

> On Thu, Aug 9, 2018 at 12:41 PM, Anton Marchukov 
> 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 (dan...@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-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/
> 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-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:

[ovirt-devel] Re: repoman glitch?

2018-08-09 Thread Dan Kenigsberg 
On Thu, Aug 9, 2018 at 12:41 PM, Anton Marchukov  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 (dan...@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-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/PQHTXDZ6SLWI53FRHIOE5HDUI5ZBM4Z6/
>> >
>> >
>> >
>> >
>> > --
>> > 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-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/4ZCFK274LKXUGIUFW55AUBX6D6PFC5FI/

[ovirt-devel] Re: repoman glitch?

2018-08-09 Thread Anton Marchukov 
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/


On 9 August 2018 at 09:25:40, Dan Kenigsberg (dan...@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-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/PQHTXDZ6SLWI53FRHIOE5HDUI5ZBM4Z6/
> >
> >
> >
> >
> > --
> > 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-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/F3FIX5RA3YCQDBVWNCMBS7A57ZWYJXTI/

[ovirt-devel] Re: repoman glitch?

2018-08-09 Thread Eyal Edri 
Actually adding Anton this time.

On Thu, Aug 9, 2018 at 8:30 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?
>
>
>
>> ___
>> 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/PQHTXDZ6SLWI53FRHIOE5HDUI5ZBM4Z6/
>>
>
>
>
> --
> 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-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/2F7XQSVQZDD76WOVEJ3TSHGJY37I6SXG/
>


-- 

Eyal edri


MANAGER

RHV DevOps

EMEA VIRTUALIZATION R


Red Hat EMEA 
 TRIED. TESTED. TRUSTED. 
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
___
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/QVAWPGLIFZDZIGNC2ULFC6BBUOEMXB2Q/

[ovirt-devel] Re: repoman glitch?

2018-08-09 Thread Dan Kenigsberg 
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-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/PQHTXDZ6SLWI53FRHIOE5HDUI5ZBM4Z6/
>
>
>
>
> --
> 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-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/UBIKDPKA2PFF7EFSNCK5XZSC5UMHLMP3/

[ovirt-devel] Re: repoman glitch?

2018-08-08 Thread Barak Korren 
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?



> ___
> 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/PQHTXDZ6SLWI53FRHIOE5HDUI5ZBM4Z6/
>



-- 
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-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/2F7XQSVQZDD76WOVEJ3TSHGJY37I6SXG/