[rdo-list] static delorean-deps repos

[Wesley Hayutin]

On Thu, Sep 28, 2017 at 12:07 PM, Alfredo Moralejo Alonso <
amoralej at redhat.com> wrote:

> On Thu, Sep 28, 2017 at 4:39 PM, Wesley Hayutin <whayutin at 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.
>

Makes sense


>
> 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.
>

Knowing if the delorean-deps have changed from one step to the next would
certainly be
a step in the right direction so thank you!  This is a huge improvement
over blindly
having to rerun ci ALL THE TIME.

It still seems like the wrong way to test a thing through a pipeline
though. To properly
CI/Test software through a chain of tests over time the rpm content should
be LOCKED.
I'm going to maintain this *is* a requirement.

If we were to host a set of rpm that included the Base OS rpms, delorean
and delorean deps as
a snapshot in time via maybe pulp [1] or the equivilant then we would
really be testing properly.

I'm not saying this needs to be done right now, however I think this is the
long term goal.
I would like to discuss this goal further and see it tracked over time.


[1] http://pulpproject.org/




>
> > 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 at redhat.com
> > https://www.redhat.com/mailman/listinfo/rdo-list
> >
> > To unsubscribe: rdo-list-unsubscribe at redhat.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20170928/cd180ad0/attachment.html>