From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6901194598360547328 X-Received: by 2002:a50:d884:: with SMTP id p4mr767329edj.120.1606927060982; Wed, 02 Dec 2020 08:37:40 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:906:c1d9:: with SMTP id bw25ls1149044ejb.4.gmail; Wed, 02 Dec 2020 08:37:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJzLVAMSfLVj1nlWtvD4xWEzXKt8f3MyxzwQTDnnQSfjCAhhdQ5+y3Nl/c4DAK8bbENjYZ89 X-Received: by 2002:a17:907:d8b:: with SMTP id go11mr569920ejc.247.1606927060050; Wed, 02 Dec 2020 08:37:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606927060; cv=none; d=google.com; s=arc-20160816; b=Dluj1GitbtE0fwyiKJGXJKQ9YG8EuKJVnStPDIk/fxweBr6OQ1xzhayhhdsK6GzXA6 bSMTkDwNQwXW9z+qDYlWnfOJ5wEhKQcuktizga+bHHYajdhgejx/blNGj86Qj2h67tQC 4JXP8sFAtSBhT8dBh2G5vmr5t/P41tY5N9+Vsq8vPbosBfPlXpRMzogB2Tk6vXcNImc2 CXQlCsxJXrRzfeFFGOx7wEkfqQgUniJ+e2krZJMd7xVpS0fR7vuDX3YaGXrvs9P9ycd5 UQKeiWJ8aoOrmOIT2ZD+3slPySZCVvjrP8bVzEtkVq2TRjXt5j9mvYkE4m4OBi4SgEBN TJ2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:ironport-sdr:ironport-sdr; bh=/xL/2QWu7mV18nQjc7J8wdyXKsv4B9MlneF02gnegGc=; b=af37NWnNWvV1J7bo2lKg6Va6tRLpplhJ4l/MrccCxJ8+Ju0vDJzV9sYeyGxmNON9yz 4Z+t0MfyGgLO+tKjP7ZL/cuO6n0u2WFeFi3jcaGlF2+21yRyODvfOSFymEjI+F0nGeO3 ua3tgNlyMt5nebe1EBdwr3aMg8VTP2CgbZhwgiNczzlyEm0iFqLu8vRaOjjjKoBzyVZt RavOGZYeNXzO4/MQqP15WbXvcB1nOZKsuecB9/GL6b1atiP8o8Btywh4zZ1Bd6m3bH0E 3zIx9dL767gUZAlY/h10he/Zh14dRqLfUfelOOTfQalScjM2w6liLI4KbJkRo/SLt4FG PZrg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of joe_macdonald@mentor.com designates 68.232.137.180 as permitted sender) smtp.mailfrom=Joe_MacDonald@mentor.com Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com. [68.232.137.180]) by gmr-mx.google.com with ESMTPS id i3si20771edy.3.2020.12.02.08.37.39 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Dec 2020 08:37:40 -0800 (PST) Received-SPF: pass (google.com: domain of joe_macdonald@mentor.com designates 68.232.137.180 as permitted sender) client-ip=68.232.137.180; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of joe_macdonald@mentor.com designates 68.232.137.180 as permitted sender) smtp.mailfrom=Joe_MacDonald@mentor.com IronPort-SDR: 2NA/UKV1HVps4/QHF//s8kYxm5OCsouWPwQNi+trg82cS7DB0wMyEFEs+L+2lu83baazNDeQ24 kSWkg1208hGy308O2YlR068iLQ0c2RxaU5sVgaBMVec21dDXnjh3jltpoH0CPbJ53mXsmaXcT3 A+lTOkEtYVd/ogg4lpcvi3e3X2458LOztjf5OXVRmCxLbYcSoNk4FbdvLdo44PhWP2KFmW4qsV 5Z91ZelBMZf+xXdIsd3ep3/mesKgK8iVMDXWwT/wF8rcd9ic8vAykClWxCtLlHiEx0ZtEz9HGm nQs= X-IronPort-AV: E=Sophos;i="5.78,387,1599552000"; d="asc'?scan'208";a="55700775" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa3.mentor.iphmx.com with ESMTP; 02 Dec 2020 08:37:38 -0800 IronPort-SDR: 07xljB0nrR89MEPOJHfPF0pvJjTHeF0yo7YlAEkih2z/kmIRGm9Lo2INaojJXa2BJXsvc3Uwxk 9lmqtmqV3Bb4iUUohGyNwylp6hmMtmDH2f5U52LF6fhORU3l0KdK9Z8enbNVIhEND/FP2AHWjd gfnGIv2jAasFtr6fEgqF+b2TCjXvtd27R/HnOHVIAi7yYx6JfTD17oJl2GRJuSatmazqHILLAW epYmHSzLVcuaol/Xd4koZk3cEyomdTWDwOFVgCMtOncmMJiMnxFok3tr+gUjSovB35kGVd6JuK 29w= Date: Wed, 2 Dec 2020 11:37:33 -0500 From: Joe MacDonald To: Claudius Heine CC: Cedric Hombourger , Subject: Re: [RFC] Image templates Message-ID: <20201202163731.GC7804@mentor.com> References: <6bf9a786-51b8-2430-90f5-2857746d003f@mentor.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9Ek0hoCL9XbhcSqy" Content-Disposition: inline In-Reply-To: X-URL: http://github.com/joeythesaint/joe-s-common-environment/tree/master X-Configuration: git://github.com/joeythesaint/joe-s-common-environment.git User-Agent: Mutt/1.10.1 (2018-07-13) Return-Path: Joe_MacDonald@mentor.com X-TUID: 09mE5w8ipFPn --9Ek0hoCL9XbhcSqy Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Claudius, [Re: [RFC] Image templates] On 20.12.02 (Wed 14:00) Claudius Heine wrote: > Hi Cedric, >=20 > On 2020-12-01 08:59, Cedric Hombourger wrote: > > Image Templates for ISAR > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > Introduction > > ------------ > >=20 > > Embedded System projects may have multiple teams working at different > > levels. It is not uncommon to have groups creating a "base platform" > > which is handed over to product teams to customize further. > > Thanks to ISAR leveraging bitbake, image recipes from a base layer may > > be easily extended by product layers but also with its ability to > > produce and use a `base-apt` instead of upstream package feeds. > > This workflow functions well in many cases, it may not be optimal for > > application teams. Such teams are typically receiving a base platform > > release that is likely to be left untouched for weeks. > > Creating a product image for those teams is sometimes as easy as adding > > a few packages. > >=20 > > In such cases, it may be desirable to have a mechanism for ISAR to > > construct product images starting from the base platform root > > file-system instead of ISAR's bootstrap root file-system. We will refer > > to these base platform root file-systems as _Template Images_. >=20 > In principle I understand your requirement, however I don't think Isar (a= nd > possible Debian) is the right base for this. >=20 > What you probably require is some sort of functional and non-destructive > root-fs build approach to root file system, that lets you arbitrarily cac= he > and distribute each stage of the root fs build. Generating and reusing the > 'base-apt' repository is much easier than it would be for root file syste= ms. >=20 > Also stuff like docker solves only a small part of that solution. >=20 > You will probably have to build a new system inspired by stuff like the > bazel build system[1], and nixox[2] or guixos[3] and maybe even stuff like > ostree [4]. Thank you for the suggestions. I had looked at bazel a while back for something unrelated but my impression of it is really that it's aimed squarely at application development teams, so never really investigated how they do their builds. We had a proof-of-concept working about a year ago with ostree on top of Isar but ultimately that didn't seem to be a good fit either since it placed significant restrictions on the filesystem. In the intervening time the project has also moved in a more container-focused direction, so it also doesn't seem to address this space any longer. NixOS and Guix both warrant further investigation, I think, though I've done a bit of preliminary work with NixOS and I think the differences between it and Debian in package format and maintenance tools are too great to make it practical. In short, I definitely agree this is potentially a significant adjustment and a large undertaking, but Isar does also seem almost uniquely positioned to make this work, and why whe're making this proposal and looking for feedback. > The rest of what you describe sounds like they would try to shoehorn this > into the existing isar build process and then trying to explicitly fix ju= st > some of the many future issues you will run into, instead of actually > designing something that is actually able to deal with all those issues i= n a > generic way. Are you thinking of something specific in the design that you see being long-term problematic, or is this more of a general concern like "this is plainly out of scope for Isar"? Our objective is to produce something that compliments and extends existing workflows, not to bolt on something that doesn't make sense, so we're open to all feedback and views of what could be danger areas or sources for future pain. > Personally, I would be interested in such a new system, but that will take > serious dedication to design and implement it properly. >=20 > Changing that now in Isar will probably break a lot of assumptions and > therefore limit its usefulness. That's definitley not our goal and the approach we are proposing, done as a new class, intends to ensure it doesn't spider out and touch things that will impact unrelated Isar workflows. If you can point to areas where we're potentially breaking assumptions in Isar, most likely around image assembly, but maybe other oareas, we'd be very happy to refine our view and goals. Thanks for the feedback, -Joe. > This suggestions reminds me a bit as the eSDK of OE, where I still couldn= 't > really find a use for and from my experience creates more issues than it > actually solves. >=20 > regards, > Claudius >=20 > [1] https://www.bazel.build/ > [2] https://nixos.org/ > [3] https://guix.gnu.org/ > [4] https://ostreedev.github.io/ostree/introduction/ --=20 -Joe MacDonald. Linux Architect | Mentor=AE A Siemens Business :wq --9Ek0hoCL9XbhcSqy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEkMd/b97HINT8/zEqSfx99yw59pYFAl/HwssACgkQSfx99yw5 9pbmXQgAlx3CKokQGIc036iakn0XbUhBHFylBz004hByGgVpgwBUX6HZ9834OlfM tnrXs3p4hD0hbKhEoXC9qVM6GfchNplWR6+R0AlZF9MQFwTYE0/+thvv1E9fJfD7 YjlQmVZsd6JxW/b770icoTO3jHpyjFWrXDaRjHh5w21Ms29GROSd8OL4Gh3nb7VV Wrh3UdHpXXPRptIZoF/ATl0iEMIetEv6Vby57ZtkJwKfK0q5dUYBIibUKig6RIa5 XPh/vsqr0EZHYoTdStYqPWhsW4x1PkRRB/k3VIT8DiEUOYU4bi3X2kEw0XnXUuRS epvkcsrw1GZfmalZipoND3G0qkAIQg== =t/y5 -----END PGP SIGNATURE----- --9Ek0hoCL9XbhcSqy--