7:05 a.m.
The latest I'm interested in is 0.15.0-4.el7:
mini@ykaul-mini:~/ovirt-system-tests$ find /var/lib/lago/reposync -name
"ioprocess*.rpm"
/var/lib/lago/reposync/ovirt-3.6-el7/x86_64/ioprocess-0.15.0-2.el7.x86_64.rpm
/var/lib/lago/reposync/epel-el7/i/ioprocess-0.15.0-4.el7.x86_64.rpm
/var/lib/lago/reposync/epel-el6/ioprocess-0.14.0-1.el6.x86_64.rpm
/var/lib/lago/reposync/ovirt-3.6-el6/x86_64/ioprocess-0.15.0-2.el6.x86_64.rpm
But merge picks 0.15.0-2.el7 instead:
2016-03-21
13:14:11,458::merge_repos.py::merge::123::ovirtlago.merge_repos::DEBUG::Copying
/var/lib/lago/reposync/ovirt-3.6-el7/x86_64/ioprocess-0.15.0-2.el7.x86_64.rpm
to output directory
2016-03-21
13:14:12,224::merge_repos.py::merge::123::ovirtlago.merge_repos::DEBUG::Copying
/var/lib/lago/reposync/ovirt-3.6-el7/noarch/python-ioprocess-0.15.0-2.el7.noarch.rpm
to output directory
Which causes the VM to take the right one from EPEL directly (and not via
the localsync).
Thoughts?
7:07 a.m.
On 03/21 14:05, Yaniv Kaul wrote:
The latest I'm interested in is 0.15.0-4.el7:
mini@ykaul-mini:~/ovirt-system-tests$ find /var/lib/lago/reposync -name
"ioprocess*.rpm"
/var/lib/lago/reposync/ovirt-3.6-el7/x86_64/ioprocess-0.15.0-2.el7.x86_64.rpm
/var/lib/lago/reposync/epel-el7/i/ioprocess-0.15.0-4.el7.x86_64.rpm
/var/lib/lago/reposync/epel-el6/ioprocess-0.14.0-1.el6.x86_64.rpm
/var/lib/lago/reposync/ovirt-3.6-el6/x86_64/ioprocess-0.15.0-2.el6.x86_64.rpm
But merge picks 0.15.0-2.el7 instead:
2016-03-21
13:14:11,458::merge_repos.py::merge::123::ovirtlago.merge_repos::DEBUG::Copying
/var/lib/lago/reposync/ovirt-3.6-el7/x86_64/ioprocess-0.15.0-2.el7.x86_64.rpm
to output directory
2016-03-21
13:14:12,224::merge_repos.py::merge::123::ovirtlago.merge_repos::DEBUG::Copying
/var/lib/lago/reposync/ovirt-3.6-el7/noarch/python-ioprocess-0.15.0-2.el7.noarch.rpm
to output directory
Which causes the VM to take the right one from EPEL directly (and not via
the localsync).
Thoughts?
Probably this is what's happening?
https://github.com/lago-project/lago/issues/93
_______________________________________________
lago-devel mailing list
lago-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/lago-devel
--
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605
Email: dcaro(a)redhat.com
IRC: dcaro|dcaroest@{freenode|oftc|redhat}
Web: www.redhat.com
RHT Global #: 82-62605
8:29 a.m.
On Mon, Mar 21, 2016 at 2:07 PM, David Caro <dcaro(a)redhat.com> wrote:
On 03/21 14:05, Yaniv Kaul wrote:
> The latest I'm interested in is 0.15.0-4.el7:
>
> mini@ykaul-mini:~/ovirt-system-tests$ find /var/lib/lago/reposync -name
> "ioprocess*.rpm"
>
/var/lib/lago/reposync/ovirt-3.6-el7/x86_64/ioprocess-0.15.0-2.el7.x86_64.rpm
> /var/lib/lago/reposync/epel-el7/i/ioprocess-0.15.0-4.el7.x86_64.rpm
> /var/lib/lago/reposync/epel-el6/ioprocess-0.14.0-1.el6.x86_64.rpm
>
/var/lib/lago/reposync/ovirt-3.6-el6/x86_64/ioprocess-0.15.0-2.el6.x86_64.rpm
>
> But merge picks 0.15.0-2.el7 instead:
>
> 2016-03-21
>
13:14:11,458::merge_repos.py::merge::123::ovirtlago.merge_repos::DEBUG::Copying
>
/var/lib/lago/reposync/ovirt-3.6-el7/x86_64/ioprocess-0.15.0-2.el7.x86_64.rpm
> to output directory
> 2016-03-21
>
13:14:12,224::merge_repos.py::merge::123::ovirtlago.merge_repos::DEBUG::Copying
>
/var/lib/lago/reposync/ovirt-3.6-el7/noarch/python-ioprocess-0.15.0-2.el7.noarch.rpm
> to output directory
>
> Which causes the VM to take the right one from EPEL directly (and not via
> the localsync).
> Thoughts?
Probably this is what's happening?
https://github.com/lago-project/lago/issues/93
Probably.
I'm wondering if there's any point in the merge process. Simply throwing
all the RPMs into a single directory should be good enough for the hosts to
take the latest greatest anyway, no?
Y.
> _______________________________________________
> lago-devel mailing list
> lago-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/lago-devel
--
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605
Email: dcaro(a)redhat.com
IRC: dcaro|dcaroest@{freenode|oftc|redhat}
Web: www.redhat.com
RHT Global #: 82-62605
9:06 a.m.
On 03/21 15:29, Yaniv Kaul wrote:
On Mon, Mar 21, 2016 at 2:07 PM, David Caro <dcaro(a)redhat.com>
wrote:
Probably.
I'm wondering if there's any point in the merge process. Simply throwing
all the RPMs into a single directory should be good enough for the hosts to
take the latest greatest anyway, no?
Yes, I agree
I think that the original idea was to have a 'generic' reposync, then sync
everything, and only extract the rpms for the distros that run in the prefix to
create the internal repo, but right now we are using a custom reposync conf per
job, tailored down already.
Y.
>
>
> > _______________________________________________
> > lago-devel mailing list
> > lago-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/lago-devel
>
>
> --
> David Caro
>
> Red Hat S.L.
> Continuous Integration Engineer - EMEA ENG Virtualization R&D
>
> Tel.: +420 532 294 605
> Email: dcaro(a)redhat.com
> IRC: dcaro|dcaroest@{freenode|oftc|redhat}
> Web: www.redhat.com
> RHT Global #: 82-62605
>
--
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605
Email: dcaro(a)redhat.com
IRC: dcaro|dcaroest@{freenode|oftc|redhat}
Web: www.redhat.com
RHT Global #: 82-62605
2951
days inactive
2951
days old
3 comments
2 participants
participants (2)
-
David Caro -
Yaniv Kaul