<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Wed, Jun 19, 2019, at 13:10, Karanbir Singh wrote:<br></div><blockquote type="cite" id="qt"><div>On 19/06/2019 18:47, Stephen John Smoogen wrote:<br></div><div>> <br></div><div>> <br></div><div>> On Wed, 19 Jun 2019 at 12:32, Karanbir Singh <kbsingh@centos.org<br></div><div>> <mailto:kbsingh@centos.org>> wrote:<br></div><div>> <br></div><div>> On 19/06/2019 17:18, Fabian Arrotin wrote:<br></div><div>> >><br></div><div>> >> We plan to compose all of those repositories, and deliver updates<br></div><div>> in the same stream.<br></div><div>> ><br></div><div>> > Just so that people realize : no *updates* repo anymore, so all<br></div><div>> combined<br></div><div>> > : if you install from network $today, what you'll install<br></div><div>> $tomorrow will<br></div><div>> > have all rolled-in directly<br></div><div>> ><br></div><div>> <br></div><div>> that's not going to work - we need to retain the ability to deliver<br></div><div>> reproducible installs.<br></div><div>> <br></div><div>> <br></div><div>> I think there is some confusion as what Brian is describing is what RHEL<br></div><div>> has been doing since EL6.<br></div><div>> <br></div><div>> This isn't any different from what RHEL does now. You have a primary iso<br></div><div>> image you instal from but if you point a kickstart to a<br></div><div>> baseurl=https://cdn.<foo> you get whatever was in the compose of the day<br></div><div>> (with all the previous packages there also but most installs will just<br></div><div>> pull the latest). If you want a reproducible RHEL install you need to<br></div><div>> only use the ISO or some similar frozen toolkit (Satellite, specific<br></div><div>> local branches, etc) but otherwise you can get different installs each<br></div><div>> day. Whether this is a good design or not is a different question... but<br></div><div>> it is one which has been in place for nearly 10 years in the RHEL<br></div><div>> upstream. [Currently the Fedora up-upstream does keep /updates/ but that<br></div><div>> is done by other production tools.]<br></div><div><br></div><div>unsure how/what you are talking about here - are you saying that we are<br></div><div>going to adopt the RHEL delivery model ? if so, how are z stream going<br></div><div>to work ? are we doing mappings for those as well now ?<br></div></blockquote><div><br></div><div>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? <br></div><div><br></div><blockquote type="cite" id="qt"><div><br></div><div>additionally, the subs manager allows me to lock out and away specific<br></div><div>rhel content, on a rhel machine - are we adopting that as well ?<br></div><div><br></div><div><br></div><div>><br></div><div>> This may just be a case of having a second set of metadata.<br></div><div>> <br></div><div>> also, what life term are we going to have for the single repo structure<br></div><div>> ? are we hoping to retain all content for the life of the release ?<br></div><div>> <br></div><div>> <br></div><div>> I believe what Brian was saying is that this would only be retained for<br></div><div>> the life of a point release, but I may be misunderstanding. <br></div><div>> <br></div><div><br></div><div>That works, can we get confirmation here ?<br></div></blockquote><div><br></div><div>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. <br></div></body></html>