[Rpm-ecosystem] Fwd: Proposing a new way to deliver Atomic systems: rpm-ostree jigdo ♲📦

Lubos Kocman 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:
> https://github.com/projectatomic/rpm-ostree/issues/1127
> 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:
> https://lists.projectatomic.io/projectatomic-archives/
> atomic-devel/2014-April/msg00000.html
> (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
> organizations
> 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
> formats.
> Basically, we're reviving an old idea for the modern age of images; I'm
> calling
> it "rpm-ostree jigdo ♲📦" (emoji are for "recycle package"):
> https://github.com/projectatomic/rpm-ostree/issues/1081
> I won't repaste it all here - just the header, which follows.  Feel free
> though
> to follow up here - email works well for this sort of thing.  The high
> level
> 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
> direction.
> 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
> http://lists.rpm.org/mailman/listinfo/rpm-ecosystem


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-ecosystem/attachments/20180102/592450a9/attachment.html>

More information about the Rpm-ecosystem mailing list