From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6901194598360547328 X-Received: by 2002:a9d:6b98:: with SMTP id b24mr2453871otq.46.1606926579433; Wed, 02 Dec 2020 08:29:39 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:aca:a843:: with SMTP id r64ls626508oie.2.gmail; Wed, 02 Dec 2020 08:29:39 -0800 (PST) X-Received: by 2002:aca:5742:: with SMTP id l63mr2091030oib.166.1606926579130; Wed, 02 Dec 2020 08:29:39 -0800 (PST) Received: by 2002:a54:4191:0:b029:dd:8465:4abf with SMTP id 17-20020a5441910000b02900dd84654abfmsoiy; Wed, 2 Dec 2020 06:42:42 -0800 (PST) X-Google-Smtp-Source: ABdhPJxTA3VMSSs+MkZUF2xUAd4PFi/tW+zs90u0kLpyWt2kkYUhru7Y5xeqmiAhvSiyaTOS0RA2 X-Received: by 2002:a63:5315:: with SMTP id h21mr178245pgb.43.1606920162028; Wed, 02 Dec 2020 06:42:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606920162; cv=none; d=google.com; s=arc-20160816; b=lXbLpVZCofgrPhzhomyHq0uSFeH9aM9tXwMuxhwqZf+eM8/U4Z6lasZE9XTj/ouU5M JEMOOOZjcW5zFO/sUp3ichMIZoWoITLNOr7VujfxIB7bnDdQGm0mdUgv0HWxv1Gl/TCB XLNsA0T5E8LShmNnW/rx3tlSfY9u3pG8D+NxKc3g0pbaPpVr2osQ9NQb65bIfyqgxh00 yTADETEaBqLfCIfvOcDbbua+u+VtPwm87Ch9ZkMH6voVwlIzpxSOnkw8UStBDObBxPoD qNH9BiJliboHYIq8t4G9LEQM6/idttM8nOGc87B4qQpuTAo1ONrQ1Xc12XJdSg/TtN9U +kVQ== 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=beCfkLXCfLWsMfIOsjq6GDq1rfgE4vKhviGxLOBEl8w=; b=jSp5C5yvDwytp99OrdZ2lnI9xCN1dwq8igitioLBTg681/RPAxT0lDKsvFtOuf3zXr 68f7xA/tzEqMoKvevHdwHeR4RJ4/xWUmUmHVVZh39qnn0v8948p0LvyBOCMWd8KDCCfM V3z9q62sbk4PUR8+Avyk5zICQb2W8L56G2AqIglK7+zhV4yZmQoHNFm3yxuXp3qU79mt xz+8ioLV3v/F97AfafkG/vU0R9ccb+cNvl9qjZ9bDq21bzjeG45I6c/jX77LhU+ETPHf YDPU2DrtGB1ySf1EPyevKfHlcRHevgnPvHcVEgMASU/Qa5wYTw8sW0v4/qxCGRTHoipA RNJA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of joe_macdonald@mentor.com designates 68.232.141.98 as permitted sender) smtp.mailfrom=Joe_MacDonald@mentor.com Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com. [68.232.141.98]) by gmr-mx.google.com with ESMTPS id y13si11201pgr.2.2020.12.02.06.42.41 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Dec 2020 06:42:42 -0800 (PST) Received-SPF: pass (google.com: domain of joe_macdonald@mentor.com designates 68.232.141.98 as permitted sender) client-ip=68.232.141.98; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of joe_macdonald@mentor.com designates 68.232.141.98 as permitted sender) smtp.mailfrom=Joe_MacDonald@mentor.com IronPort-SDR: VxfVSvwTfIuXfWZa6rf2TQCDZ2mlBKBOcIjKLHCzEkZo6jUNlX8mAxyGxnTH1qnCs0xctHssL5 o8njGbHzQfsh0PSKLZZJqsxX8s7ZYw1E7kmpFkRdL55UjF/TVI5jiLQHhh2a4n4D4a9XfJkl6i 1jS1hEICl9N6imE/Q+DKtwFcrV9ywMhlLCE1pVVc6ZvPsJ7kECiUQ/nV8nTXTeDJSgtCFrMjDr wvgzOhTsAgneZWfK4CyVavefiM5Gg22YIZV5kv9H5ZOtbB9dz/jQhbNrq9DmirnZ4wydFe+ybM md0= X-IronPort-AV: E=Sophos;i="5.78,386,1599552000"; d="asc'?scan'208";a="55708183" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 02 Dec 2020 06:42:41 -0800 IronPort-SDR: XoDvKYzQ/RNvsbgnreT6w6RihJ94bC8h8WCGGyh8cg8ZvB4ECtfKJuk5lwIggRJS/QnWbZyT8w D+IpzRKys3c+4fwP6ezuZ/4F3jr8ABVQRgdrWadZYqcxRl60T4Z/sCeTPFJuMI62dwOrey6wnG EpLo9dvfdgn00CGdMHodYG8Txa5jbKL7SCjvsv0C0C1XUoQF/IF83vtQgSMbGDXSSvQ77SIgbE iTluNJamYng+aI7BtYPrNYI/zLnjbrnZAK2MuT09MhL77ukHR2GStjlX3Z8c6DGaFZq+Hp8qwC XTA= Date: Wed, 2 Dec 2020 09:42:37 -0500 From: Joe MacDonald To: Jan Kiszka CC: Cedric Hombourger , , Henning Schild , "Cirujano-Cuesta, Silvano" Subject: Re: [RFC] Image templates Message-ID: <20201202144236.GA7804@mentor.com> References: <6bf9a786-51b8-2430-90f5-2857746d003f@mentor.com> <6218fc7b-2515-5b81-91b6-6fd0d275ae02@siemens.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: <6218fc7b-2515-5b81-91b6-6fd0d275ae02@siemens.com> 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: wDrfHuu7JU/C --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Jan, [Re: [RFC] Image templates] On 20.12.01 (Tue 09:40) Jan Kiszka wrote: > On 01.12.20 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 > There is another use case, even for base image developers: accelerating > the turn-around time when working only on few, widely isolated packages, > may it be the kernel or a bootloader artifact. >=20 > For that scenario, it should be possible to define an image template > excluding those bits, only injecting them on top in a second step. That's a very good point. We will incorporate the additional use case idea in a revised verison of the proposal. Do you have thoughts on what the implementation may look like for this? An explicit list of packages in the image that should be removed or otherwise excluded from the generated template? > > 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 > > This document will describe both the construction and the use of > > _template images_. > >=20 > > Construction > > ------------ > >=20 > > Developers needing to produce image templates in addition to bootable > > system images will have their image recipes `inherit` the > > `produce-image-template` class either as part of their image development > > or by extending an existing image with an appropriate `.bbappend`. > >=20 > > The class would invoke a `do_rootfs_template` task after > > `do_rootfs_install` and before the post-processing tasks (which should > > be applied on the final image). This new task would simply create a > > template image in the deploy folder built from the common root > > file-system artifacts. Some systems may have additional, more extensive > > post-processing operations that must be performed on the final > > image, this class will still allow for such operations to function > > normally. > >=20 > > It is anticipated that configuration files in `/etc/apt/sources.list.d` > > and `/etc/resolv.conf` should be excluded (they should be recreated > > while the template image is imported). A subsequent update > > will define a criteria for determining which files should be excluded > > from the tarball. As yet the specific mechanism has not been determined, > > whether it would be a file list, pattern or some other > > external attributes. We anticipate other objects that may need to be > > excluded are `/etc/hosts` and proxy configuration, to name two simple > > examples. > >=20 > > The process of constructing the base image would then continue as usual > > (with post-processing and imager tasks). > >=20 > > It is suggested to expose the produced image template as an opaque > > binary blob and use a `.tmpl.img` file extension although the initial > > implementation is anticipated to be a compressed tarball. > > The template filesystem may need embedded meta-data to be consumed by > > import mechanism or image recipes that make use of templates but omitted > > from the final rootfs. It would be useful at the outset > > to either specify a minimal set of metadata (build date, image name and > > feature list is the initial list to be considered) and the structure of > > that metadata (currently considering either JSON-formatted > > suitable for extraction with `jq` or `deb` packaging, which has embedded > > metadata in the cpio archive). > >=20 > > Usage > > ----- > >=20 > > Application teams may create image recipes referencing image templates > > in their SRC_URI list. As noted above, image templates would use the > > `.tmpl.img` file extension. This would be used by ISAR's `rootfs` > > class to locate image templates in the list and make sure that only one > > template is specified (extracting a template over another would have > > unpredictable results). > >=20 > > If the bulk of the template intelligence is present in the `do_rootfs` > > stages, the `do_rootfs_prepare` task from the `rootfs` class would > > behave differently.=A0 In this case, an image template may be added to > > an image SRC_URI. Instead of copying ISAR's bootstrap rootfs, the > > template feature would instead unpack the specified template. It would > > also be necessary to copy `/etc/apt/sources.list.d` from the bootstrap > > and possibly other files (e.g. `/etc/resolv.conf`). As the environment > > may include different apt sources, a complete `apt-get update` would be > > in order. > >=20 > > ISAR would then "enter" the unpacked template carrying updated apt > > sources to install packages listed in `IMAGE_INSTALL` and > > `IMAGE_PREINSTALL` using `apt- get install` as it does today in > > `do_rootfs_install`. > >=20 > > This design should allow images constructed from an image template to > > produce a new image template (e.g. a base platform could provide a > > template having a BSP and a minimal Debian system, and middleware teams > > could then produce their own template with middleware stacks added and > > finally consumed by application teams to produce a final system image). > >=20 >=20 > There will likely be a number of traps we can stumble over, but the > general vision is shared. >=20 > One of the trap is that you may not only need a target image template > but also the corresponding buildchroots, if not isar-bootstraps. Also a good point. I wonder if we could avoid this by having a second manifest (maybe another SRC_URI-like variable) for the template which would include development versions of all installed packages or something and then during development the template will include them but the final image that derives from the template would have those removed unless specifically added by the final image SRC_URI. It would be nice, if possible, to avoid having to bundle the image and the chroot/bootstrap directories as well. > Would your model be that a developer works within the layer that creates > the template? A key issue would be that changes to the layer that > invalidate the template would be detected and make the template-based > build fail or fall back to the full build. >=20 > Or would your model be that templating enforce a split build via > separate repos? That might be problematic from the maintenance > perspective as application injection will come before imaging, and the > latter is not the task of an application developer. Cedric and I may have different views on this. Personally I had been thinking it would be more along the lines of the latter, where the templates are entirely an external entity that a developer brings in, so there would be no 'risk' of the template being invalidated and recreating a full build. The primary motiviation for this, from my perspective, is that it's better for such a change to cause a failure and be flagged appropriately than for it to silently build and give the developer the impression that they are building on top of the specified template but are really using something different. I'm not sure what you mean about this being a problem for application developers. Can you elaborate a bit? It seems to me that this isn't significantly different thatn any existing Isar workflow is today and it is still possible for the application developer to simply generate a binary deb and install that on a deployed system whether that system was assembled from templates or in the more traditional manner. > > Future Work > > ----------- > >=20 > > It may be desirable to offer a mechanism to remove packages coming from > > an image template (application teams may need to optimize the final > > system image to meet the footprint constraints of their design and/or > > to reduce the attack surface by removing services they do not need). > >=20 > > Status > > ------ > >=20 > > This high-level design was created to seek early feedback from the ISAR > > developer community by exposing the problem we are trying to solve and > > the mechanism we are proposing as a solution. The next step would be > > the development of a Proof-of-Concept in the event where positive > > comments are received. This document may also be updated as feedback is > > received and may result in different approaches being discussed. > >=20 > > We will be happy to answer questions you may have or provide more > > details in areas where this document would be too evasive. > >=20 >=20 > The whole thing also reminds me a lot of how docker images are created. > I wonder to which degree we can learn from that, reuse concepts or avoid > pitfalls. Adding Silvano with whom I was recently discussing base > container image generation via Isar. Oh, that's very interesting! I'd been thinking the same thing, and certainly it's no coincidence that the proposal does somewhat follow the same model as Docker container assembly. I think there are some very good ideas in the way Docker containers are created and there are some things that are very limiting and seem like unnecessary restrictions, so I would certainly welcome the opportunity to discuss those further. About a year ago I'd started putting infrastructure into our IndustrialOS builds to automatically generate Docker images alongside our current IPC wic images. In the end, coming up with a good way to create usable Docker-style workflows seemed like more effort than we could justify at the time for something for which we had no customer-driven use-case, and I just created a script to do much the same thing outside of the Isar build process. I still think it's an excellent idea to use Isar to generate base images, though, I'd be very interested in the discussion when you're ready to share details. >=20 > Jan >=20 > --=20 > Siemens AG, T RDA IOT > Corporate Competence Center Embedded Linux --=20 -Joe MacDonald. Linux Architect | Mentor=AE A Siemens Business :wq --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEkMd/b97HINT8/zEqSfx99yw59pYFAl/Hp9wACgkQSfx99yw5 9pb4Ywf9HxxRl2SQYO/mLq32VRHW2XZ1bXv8//9fn2mkIbmepoJVijRDSbkQKkxU yA1EfgyanAQa3F0qmZG8SMHkQ1bZRYID83wkQFA8/hV6R6js87ijZObndX2Q0SPd M6FTaskFZx+ahNeKWq7zZ28sqTFBPeC5mcW5X7h0pzxxAsEObUxg5dvxySpt148S 9bIMhAd+IBmTgnT+fUVCI7ECgUiFTCoJQvI6sOO4aCyaWGlO58sxyyLRfrqvEHbJ BQkoXC0ilWF6c6AZlfJqVad75Van+IwjgGb4mNsiAC2pMZy/ebs8D63cBddKlHc3 C/nHMjFRu+PWRdKrfq+6rlcTc1ifxA== =vdYp -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd--