On Tue, Jan 05, 2021 at 08:49:20AM -0500, Neal Gompa wrote:
On Tue, Jan 5, 2021 at 8:34 AM Colin Walters
<walters(a)verbum.org> wrote:
> Now speaking of deltas - really delta implementations are going to benefit from a
stronger "cadence" to releases, exactly much like what we do for CoreOS (but not
Silverblue/IoT) today. The relationship of such a system and Bodhi is...messy.
> ostree deltas are also *much* better than deltarpm in various ways (most notably the
CPU intensive part is bsdiff which we only use selectively instead of the whole thing).
>
Cadence only matters if the infrastructure around delta fetching
requires it to care. In the case of RPM-OSTree and Flatpak, this is
not a problem as long as you're using native OSTree remotes. If you're
using OCI image remotes instead, then you *do* have to care about
cadence because you have to maintain images and generate deltas based
on possible options. The latter option is how we deliver Flatpaks, and
so we have the same problem we have with DeltaRPMs.
> On the other hand, we really want deltas too for containers; that's
https://github.com/containers/image/pull/902
>
> A very tricky case is the intersection of all of these; for my "dev
container"/toolbox on my Silverblue workstation I use a custom container built on a
server with all of my tools, but I do often `yum update` inside it since that works
incrementally and online. (But I do periodically flush and re-pull) If we implemented
container deltas I'd be a lot more likely to use `podman` to update it instead.
Addressing the underlying issue here: container deltas and OSTree
deltas are considerably worse for constrained bandwidth than RPM
deltas. Outside of the USA (in the general case) and within the USA
(in several parts of the country), it is extremely common to have
extremely limited bandwidth availability and even more common to have
low throughput. As that will basically never change, we have to work
with that framework.
Regular Fedora variants offer users the ability to pick and choose
updates based on their situation. If DeltaRPMs were implemented in our
infrastructure correctly, those users would be very well-served by
being able to publish a sliding window of the last 30 days of delta
RPM content. What's particularly galling here is that we have all the
necessary inputs to do it, since Koji keeps everything and Bodhi knows
everything that's ever been pushed. It's pretty much a Pungi
restriction that we've never been able to do this properly.
Another thought: we could use popcon-like information to generate delta
rpms only for N% most popular packages (10%?). This would significantly
cut down on the cost of generation, without really affecting average
user savings.
Yet another reason why popcon would be useful.
To be blunt, I would have never done Zchunk metadata if it was going
to be used as a tool to kill DeltaRPMs. I firmly believe we need both
to have a comprehensive offering that accommodates the needs of Fedora
users across the world.
Zbyszek