ostree/fedora atomic and impact on the mirror network

[Matthew Miller]

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 at fedoraproject.org>