On Mon, Mar 10, 2014 at 02:11:34PM +0000, Colin Walters wrote: > Now, a few things. First, the current goal of Fedora Atomic > Initiative is just to track Rawhide - I was talking with Dennis > Gilmore at devconf.cz and we felt this made the most sense rather > than trying to jump all the way to releases. So the idea here is > that it's for users who are already updating weekly or faster. So, do you think it *could* be ready for non-rawhide for a small subset (like the docker host cloud image, not even generally for Fedora cloud images) by F21? Or should we be targetting that for later? > Now, let's talk about space usage on the mirror network. A *very* > interesting question is how much tree history we keep. A lot of > this is a function of how many trees we generate (at the moment, I > just made up some "baseline" products) as well as how often the > packages in those trees change. For the cloud case, we're looking at initially just one tree per Fedora release, and with the 13-month lifecycle. Unless we can get to batched updates soon, updates will be fairly frequent -- I need to put together some data on how it's gone so far with F19 and F20 for reference. > One model I'd like to aim for here is we say "the repository will > take up at most N GB" (where e.g. N=100) and we keep an > intelligently-scheduled series of snapshots, like backup systems do. Makes sense for rawhide. > And the "release" repository would be synced out to more mirrors. > This repo might contain just each "gold" release, plus the > intermediate alpha/beta snapshots. Plus say monthly update > snapshots. We also will need to provide for off-schedule critical security updates. > So an offhand TODO list for production releases: > - Anaconda support (working on it) > - Move rpm-ostree into Koji > - Requires RHEL7 or newer build host > - Write Koji plugin > - GPG signing (or TLS for metadata) > - Static deltas (initial code exists, needs HTTP/GPG plus optimization) *nod* > - Determine mirror impact > - Space availability > - Determine whether some mirrors would want to opt out of higher > HTTP load Speaking as a mirror admin until just very recently, the latter is a much bigger concern than the former. For the small docker host case, I don't think space is even going to be an issue. -- Matthew Miller -- Fedora Project -- <mattdm@xxxxxxxxxxxxxxxxx> -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
