[Rpm-ecosystem] Fwd: Proposing a new way to deliver Atomic systems: rpm-ostree jigdo ♲📦
lkocman at redhat.com
Tue Jan 2 08:14:14 UTC 2018
I'd like to share my experience with using jigdo on RHEL-7 product builds.
Most of that time is building images. JIGDO itself is big slowdown in the
process and perhaps time-wise the most expensive item on the image build
Did someone do some performance measuring? Is it satisfying for your needs?
>From my point of view jigdo is worth some performance improvements.
On Wed, Dec 6, 2017 at 8:51 PM, Colin Walters <walters at verbum.org> wrote:
> Forwarding this here since it's quite relevant; I also think it's quite
> *interesting* for people interested in package/image systems.
> One consequence is I'll probably start doing some more patches
> for librepo. Related to that, a bigger issue looms:
> Anyways just sending this along since I think it'll be interesting
> for this audience; I'll bring up the repodata issue when I have
> time to circle back to that.
> ----- Original message -----
> From: Colin Walters <walters at verbum.org>
> To: "atomic-devel" <atomic-devel at projectatomic.io>
> Subject: Proposing a new way to deliver Atomic systems: rpm-ostree jigdo
> Date: Wed, 06 Dec 2017 13:11:11 -0500
> I've been working on Project Atomic for several years now; first post:
> (And the rpm-ostree/ostree projects predate that; rpm-ostree's
> "gitbirthday" is
> coming up at Sat Dec 21 19:41:30 2013 -0500)
> This entire time we've dealt with 3 binary formats: RPM, Docker (now OCI)
> and OSTree.
> The tension is...powerful. It leaks through into how people manage
> systems; issues
> like "how do I mirror this content" are serious blockers for lots of
> that don't want their systems Intenet connected. Obviously I've thought
> about this a lot,
> and I now have a concrete proposal now to try to get that closer to two
> Basically, we're reviving an old idea for the modern age of images; I'm
> it "rpm-ostree jigdo ♲📦" (emoji are for "recycle package"):
> I won't repaste it all here - just the header, which follows. Feel free
> to follow up here - email works well for this sort of thing. The high
> status is: things are moving quickly, and the next step is to start
> fleshing out
> the client side. So it's at the point where I want concrete feedback.
> Upstream issue follows below:
> Fetching content via both ostree and libdnf ends up mixing the tradeoffs
> of both, requires release engineering to manage both, and makes it harder
> to mirror content. Not to mention the fact that there's the whole
> OCI/Docker thing which also works in a completely different way, and admins
> need to manage/mirror that too.
> Now while the "obvious" thing would be to try to align with OCI in some
> way, the complete lack of wire deltas there is very problematic for uses
> outside of server clusters, and given that we already have lots of
> extensive linkage to RPM via libdnf, it makes the most sense to move that
> Hence, let's experiment with doing ostree-in-RPM ... [ read more at
> https://github.com/projectatomic/rpm-ostree/issues/1081 ]
> Rpm-ecosystem mailing list
> Rpm-ecosystem at lists.rpm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rpm-ecosystem