On 19/06/2019 18:47, Stephen John Smoogen wrote:
>
>
> On Wed, 19 Jun 2019 at 12:32, Karanbir Singh <kbsingh@centos.org
> <mailto:kbsingh@centos.org>> wrote:
>
> On 19/06/2019 17:18, Fabian Arrotin wrote:
> >>
> >> We plan to compose all of those repositories, and deliver updates
> in the same stream.
> >
> > Just so that people realize : no *updates* repo anymore, so all
> combined
> > : if you install from network $today, what you'll install
> $tomorrow will
> > have all rolled-in directly
> >
>
> that's not going to work - we need to retain the ability to deliver
> reproducible installs.
>
>
> I think there is some confusion as what Brian is describing is what RHEL
> has been doing since EL6.
>
> This isn't any different from what RHEL does now. You have a primary iso
> image you instal from but if you point a kickstart to a
> baseurl=https://cdn.<foo> you get whatever was in the compose of the day
> (with all the previous packages there also but most installs will just
> pull the latest). If you want a reproducible RHEL install you need to
> only use the ISO or some similar frozen toolkit (Satellite, specific
> local branches, etc) but otherwise you can get different installs each
> day. Whether this is a good design or not is a different question... but
> it is one which has been in place for nearly 10 years in the RHEL
> upstream. [Currently the Fedora up-upstream does keep /updates/ but that
> is done by other production tools.]
unsure how/what you are talking about here - are you saying that we are
going to adopt the RHEL delivery model ? if so, how are z stream going
to work ? are we doing mappings for those as well now ?
Very much not in favor of doing z-stream updates. But EUS is a separate RHEL entitlement, does the existence of EUS somehow change the discussion here?
additionally, the subs manager allows me to lock out and away specific
rhel content, on a rhel machine - are we adopting that as well ?
>
> This may just be a case of having a second set of metadata.
>
> also, what life term are we going to have for the single repo structure
> ? are we hoping to retain all content for the life of the release ?
>
>
> I believe what Brian was saying is that this would only be retained for
> the life of a point release, but I may be misunderstanding.
>
That works, can we get confirmation here ?
I deliberately left that unspecified to generate discussion here. The tradeoff is between keeping large amounts of history, and conserving space on the mirrors. If we want to prune at point-release time we can.