On Thu, Sep 28, 2017 at 1:30 PM, Haïkel <hguemar(a)fedoraproject.org> wrote:
2017-09-28 18:07 GMT+02:00 Alfredo Moralejo Alonso
<amoralej(a)redhat.com>:
> On Thu, Sep 28, 2017 at 4:39 PM, Wesley Hayutin <whayutin(a)redhat.com>
wrote:
>> Greetings,
>>
>> Had a brief discussion on the release delivery meeting this morning
with Jon
>> Schlueter where as the rel-del had a requirement for the CI to
constantly
>> execute to retest any potential changes to the delorean-deps yum repo.
>> This is required because it informs the import process.
>>
>> Ideally we don't have to constantly tax both our hardware and people
>> resources because we have have an unpinned repo that can change at any
>> moment.
>>
>> A static delorean-deps repo married to a delorean repo would be more
>> efficient for everyone. How that is achieved is under discussion.
>>
>
> Having static delorean-deps repo for a RDO Trunk hash may be
> problematic also because centos, virtualization and ceph repos are
> changing repos and we may need to introduce new
> dependencies for the same hash.
>
Actually, it can be done for third-party repo (See below). We just
need a step to retrieve,
save yum metadata. Possibly, we may have to mangle base url but it's easy
to do
(yum metadata are just sqlite and xml databases).
> What i'd propose is to have versioned dependencies repos so that jobs
> can easily report the version of deps used and replay the job with a
> specific dependencies snapshot if needed.
>
Just to clarify to the readers, we don't need to version the whole
repositories only the yum
metadata. By convention, published packages are not removed from
public repos, and
yum/dnf won't see newer packages that are not in metadata.
So it's quite a storage-efficient way to handle the issue mentioned by Wes.
Haikel,
Would we be able to version the CentOS base repos as well via metadata?
To Alfredo's point, if somethign changes in CentOS that requires a change to
the delorean deps then we may have an issue.
I'm not sure how often a change in CentOS requires a change to
delorean-deps.
I suspect if that happens often we will hit a lot failures.
Thanks for the comments and feedback thus far!
>> This email is only to serve as an entry point for a public discussion
around
>> that issue.
>>
>> Thanks all!
>>
>> _______________________________________________
>> rdo-list mailing list
>> rdo-list(a)redhat.com
>>
https://www.redhat.com/mailman/listinfo/rdo-list
>>
>> To unsubscribe: rdo-list-unsubscribe(a)redhat.com
>
> _______________________________________________
> rdo-list mailing list
> rdo-list(a)redhat.com
>
https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe(a)redhat.com