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