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(a)fedoraproject.org>