[Rdo-list] delorean.repo vs delorean-deps.repo

[Javier Pena]

----- Original Message -----
> So, following a lengthy discussion on IRC and on gerrit [1], we
> realized it wasn't as easy as it seemed at first glance.
> It did raise some interesting questions, though.
> 
> There are really three repositories for liberty right now:
> - delorean (from delorean.repo)
> - delorean-liberty-testing (from delorean-deps.repo)
> - delorean-common-testing (from delorean-deps.repo)
> 
> For the packages in [delorean] to work properly, it needs the
> dependencies found in [delorean-liberty-testing] and
> [delorean-common-testing].
> The naive idea I submitted was "Why not just bundled the two -testing
> repos inside delorean.repo ?" .
> 
> Yes, this could work momentarily - but let's pretend that we have CI
> pass over a set of packages and then promote a delorean repository to
> "current-passed-ci".
> Some time passes by and the packages in either
> delorean-liberty-testing or delorean-common-testing change and
> actually breaks the build that we tagged as passing CI.
> 
> Since all the packages are not in every given repository and each
> repository can change independently of the others, we are unable to
> guarantee that a specific repository that passes today will pass
> tomorrow.
> So, what do we do ?
> - Pull in every liberty-testing and common-testing packages to every
> delorean repository ? Sounds expensive but is possibly what Ubuntu
> does [2]
> - Also promote a set of -deps repo when we promote a delorean repo ? How ?
> 

Would we want to keep all passed-ci repos over time? It should not be too hard to make the promote script fetch all packages in delorean-liberty-testing and delorean-common-testing during promotion and rebuild the repo with them. However, it could increase storage usage (~330 MB at the moment).

Cheers,
Javier

> I see three objectives in trying to improve the current situation:
> - Streamline/improve system and user experience by having one
> repository to add, not two
> - Improve stability by making sure builds that passed will remain stable
> - Ensure builds and their results are reproducible every time
> 
> Any ideas ?
> 
> [1]: https://review.gerrithub.io/249207
> [2]:
> http://ubuntu-cloud.archive.canonical.com/ubuntu/dists/trusty-updates/liberty/main/binary-amd64/Packages
> 
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
> 
> dmsimard = [irc, github, twitter]
> 
> 
> On Wed, Oct 7, 2015 at 6:12 AM, Javier Pena <javier.pena at redhat.com> wrote:
> >
> >
> > ----- Original Message -----
> >> > I was wondering why these two files were split up if one can't be used
> >> > without the other ?
> >> > Can we bundle delorean-deps.repo inside delorean.repo ? There'd be
> >> > three repositories in the file.
> >>
> >> delorean-deps.repo is a single file which can be changed when we move
> >> repos e.g. cbs.centos.org/repos/ will be blocked soon and we'll need
> >> to switch to the mirror on buildlogs.c.o and eventually to the release
> >> repos on mirror.c.o.
> >> delorean.repo is a static file generated by Delorean when it runs so
> >> it can't be changed as easily.
> >>
> >> > It'd be simpler for both users and systems to consume this one
> >> > repository file with everything we need in it.
> >>
> >> Good point, maybe we could figure out something using server-side include:
> >> https://github.com/redhat-openstack/delorean-instance/issues/14
> >>
> >
> > It may be easier if we can just patch delorean to include the contents of
> > delorean-deps.repo into delorean.repo. I have proposed this in
> > https://review.gerrithub.io/249207
> >
> > Cheers,
> > Javier
> >
> >> Cheers,
> >> Alan
> >>
> >> _______________________________________________
> >> 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
> >>
> 
> _______________________________________________
> 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
>