4:39 p.m.
We could on OST side create a repositories directory for each suite, which
will hold symlinks to one-suite-configuration-file: i..e
basic-suite-master/
repos/
000-main.repo -> ../common/repos/main.repo
001-ovirt-master.repo -> ../common/repos/ovirt-master.repo
On Lago's side it will require adding an option to load all
repositories(ordered) from a directory, before passing it to repoman.
How comfortable will this be to maintain - I'm not sure actually :)
On Sun, May 7, 2017 at 11:22 AM, Eyal Edri <eedri(a)redhat.com> wrote:
On Sun, May 7, 2017 at 9:30 AM, Yaniv Kaul <ykaul(a)redhat.com> wrote:
>
>
> On Sun, May 7, 2017 at 9:12 AM, Nadav Goldin <ngoldin(a)redhat.com> wrote:
>
>> On Sat, May 6, 2017 at 7:01 PM, Yaniv Kaul <ykaul(a)redhat.com> wrote:
>> >
>> > Obviously, if I'm syncing a single repo, why is it fetching metadata
>> from
>> > other repos?
>> > We perhaps need to start splitting the config files to multiple conf
>> files?
>> > It makes sense anyway, especially if we run the reposync per each repo
>> > independently anyway?
>>
>>
>> Yep, unfortunately reposync reads all repos in the config, despite the
>> fact only one is enabled for each run. Though I hope that we only pay
>> the penalty for the first repo, so that the next repos should already
>> use the metadata fetched during the first repo synchronization. Thus
>> the overall running time difference should be small. If it fetches the
>> metadata for all repos over and over again then it is a problem.
>>
>
> It indeed looks like it's only happening for the 1st run.
>
>
>>
>>
>> Splitting the repo file makes sense, but it might make it harder to
>> maintain, and as I said, I'm not sure if it will have significant
>> effect on the running time.
>>
>
> It might be actually easier, if different suites can share some repo
> configurations. Not sure.
>
I also had this idea on creating a single 'common' file so other files can
use/inject/inherit if possible.
We need to come up with a better way to manage the reposync files as
today's status of maintaining the list of packages and repo
across multiple suites is error prone and contains duplicated repos.
I don't have a design idea for it yet though..
> Y.
>
>
>
> _______________________________________________
> lago-devel mailing list
> lago-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/lago-devel
>
>
--
Eyal edri
ASSOCIATE 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 <+972%209-769-2018>
irc: eedri (on #tlv #rhev-dev #rhev-integ)