Drop reposync command
Hi everyone, I'd like to start a discussion about dropping (at least temporarily) the reposync command. The reposync command is used in lago for two things: * Downloads locally all the packages defined in the repo conf passed (yum config file format) * Creates an internal_repo dir in the prefix and copies over all the packages that match the distros used in the prefix The advantage is that once synced, this allows installing any packages on the vms without having connection to the internet. The downside is that right now, it downloads everything, needed or not, so it takes a lot of space and time the first run to cache all the packages. For that reason on the ovirt system tests we removed the epel/centos base repos from the reposync (it was ~20G) but as that already makes the tests require an internet connection, makes the reposync command obsolete (it is caching only some part of the packages). So the idea is to drop the reposync command until we have a better alternative (maybe a small local proxy that caches everything on the first run or something similar) -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com IRC: dcaro|dcaroest@{freenode|oftc|redhat} Web: www.redhat.com RHT Global #: 82-62605
On Mon, Mar 7, 2016 at 11:36 AM, David Caro <dcaro@redhat.com> wrote:
Hi everyone,
I'd like to start a discussion about dropping (at least temporarily) the reposync command.
The reposync command is used in lago for two things: * Downloads locally all the packages defined in the repo conf passed (yum config file format) * Creates an internal_repo dir in the prefix and copies over all the packages that match the distros used in the prefix
The advantage is that once synced, this allows installing any packages on the vms without having connection to the internet. The downside is that right now, it downloads everything, needed or not, so it takes a lot of space and time the first run to cache all the packages.
For that reason on the ovirt system tests we removed the epel/centos base repos from the reposync (it was ~20G) but as that already makes the tests require an internet connection, makes the reposync command obsolete (it is caching only some part of the packages).
So the idea is to drop the reposync command until we have a better alternative (maybe a small local proxy that caches everything on the first run or something similar)
Generally, I'm in favor. I'm wondering if we can make use of the the already existing yum/dnf local cache? Since I really don't want to download the packages EVERY time. What about an interim solution - create an (ISO?) with some base packages - especially for the released (3.6) binaries, that will not change as often as master and can be used? So even if some are outdated - at least it's some of them and not all of them. And we can update that ISO with newer content once ... a month or a quarter or so. Y.
-- David Caro
Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605 Email: dcaro@redhat.com IRC: dcaro|dcaroest@{freenode|oftc|redhat} Web: www.redhat.com RHT Global #: 82-62605
_______________________________________________ lago-devel mailing list lago-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/lago-devel
What about an interim solution - create an (ISO?) with some base packages - especially for the released (3.6) binaries, that will not change as often as master and can be used? So even if some are outdated - at least it's some of them and not all of them. And we can update that ISO with newer content once ... a month or a quarter or so. Y.
Here are other forms for the same idea: 1. Create a repo VM image 2. Make the test VMs with a pre-seeded yum cache. 3. Make the test VM images be pre-installed wit everything you may ever need The common thing about all theses solutions they are test-environment/application specific (You are talking specifically about oVirt here. Lago is already used for other things, and hopefully will be used for more) and not suitable as a generic Lago core capability. I think we will need to try out and implement multiple solutions before we land on something generally useful, in the meantime its better to make tests and CI work faster, so I strongly +1 this move. -- Barak Korren bkorren@redhat.com RHEV-CI Team
participants (3)
-
Barak Korren -
David Caro -
Yaniv Kaul