From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6901194598360547328 X-Received: by 2002:a62:d11b:0:b029:18b:b3e:95aa with SMTP id z27-20020a62d11b0000b029018b0b3e95aamr1828003pfg.3.1606817441747; Tue, 01 Dec 2020 02:10:41 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:902:ec06:: with SMTP id l6ls739641pld.8.gmail; Tue, 01 Dec 2020 02:10:41 -0800 (PST) X-Google-Smtp-Source: ABdhPJxg4UiOIUwSfNhFiQsgsKHUKkrDDY6jeexCJ9BaPElaeUBp6pO/ZYfld+kgTlIBnFMtb5Op X-Received: by 2002:a17:90a:8589:: with SMTP id m9mr2035859pjn.190.1606817441036; Tue, 01 Dec 2020 02:10:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606817441; cv=none; d=google.com; s=arc-20160816; b=L8CXq4Zo1BaXYIVcfIgNQx6I6cMEUWwF4drIfqt2L3Sm7eXTPE12oI0cinP1+efB4g FtAdQWiWCP12od91oCsiKBfBgO0RB0/RLv1owgRjjIXptTu7GP/TbcQwsblo9fun7h6l YBhxrVOgp0+D/nQseJiUw8sG2V0qZoER6dYJGQcWjNXaZja7VHUokApNqIBe35NKJHcK YJqIPiwktdHbX00kl2mtDP/MC0AHm1LnKMYevdDccLW5kCVh03d0HqTc7Zqv9ZcnRXyH HJZXKy6HE36Fa7aKnYZ/OBMxVtVcUi7XGUG9Nju+I00I29OSlfCC7Ei+MmiYvX28uAo+ yDOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-language:content-transfer-encoding:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :ironport-sdr:ironport-sdr; bh=XAO26+oTG92hh3M0lbmiNGK/lKQOIbb6FqHy0UdVJfI=; b=vpG2wUEerw1rO0t6HkrwEnBtff6jcwG/MroQ9xuTu21m4rgAoKpagXNN3rgxVWjzfv 5a0loCkf21zAsDNZhQBjQQZe7TkxGYDb02ToBP4D3n3iZPU8TcheT/eIDkLj20zs8fvl k2dnvizFoletVH+/wzy0flrjlMtN0KII/Zt1Qbo7Fs3dIlck5ZFfriJ2HiG1iaAobh2Z KXqeQ9Idb2YOujVvSKbagST4Vrt06WV+APiTInjpNLGWlr/aYHm+qUhXkTOxdu/dzK6m YzHhqzn73JnJ5XUieTsFUwL942wCaaEgNvEHO/lGh0Oe2/tno8xaHS4VOUvOpe/R8olF dAMw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of cedric_hombourger@mentor.com designates 68.232.129.153 as permitted sender) smtp.mailfrom=Cedric_Hombourger@mentor.com Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com. [68.232.129.153]) by gmr-mx.google.com with ESMTPS id nu3si57358pjb.0.2020.12.01.02.10.40 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Dec 2020 02:10:41 -0800 (PST) Received-SPF: pass (google.com: domain of cedric_hombourger@mentor.com designates 68.232.129.153 as permitted sender) client-ip=68.232.129.153; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of cedric_hombourger@mentor.com designates 68.232.129.153 as permitted sender) smtp.mailfrom=Cedric_Hombourger@mentor.com IronPort-SDR: ehfly5aiB+cq003Asx/NjxjMmk412UKT3bjPtbUyAYRDoOd5dQHL8FrSFKpnioEwO3BARJ/zSa vqBnRLxgjFAayiEG5/ZZfGLaCPYfCed/WYsrIddDfvYQSd4gW6QaplcCOVVsdFZvsxWxuV4t3W o5XSc+JfrucLCUac5eEPkzzgqptvCTfXS54FQmaKc7ErxBcuLQo5QOprxGbBeF9DYl2D1M+mGB ik4Wf9laVxwq8hC4OD5O0Mzrvl712acTdtIp2xOdAwVkR6jQT67MrgCrVUXrw40QUOtIAAGV8g W0M= X-IronPort-AV: E=Sophos;i="5.78,384,1599552000"; d="scan'208";a="57941753" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 01 Dec 2020 02:10:40 -0800 IronPort-SDR: Fl/JJrJwh/NNZxTDsWviLQoZldb3e04x5WxAPqHRih3OXYCPAFghkcuAi6Bl04IJZ6tmNBLpcw M4O0gDDvZNpJnqowJKfi6wkhz2r/q6Zoj/QoQTMhbPIK+D8GqNxhAISGI8J9ohscqn0fH/lFOO kwI8+0/dNk+4T3rzSeyKiIH5QiBTbl6yXE6f5IXL0wSyV2YZbx8ows/PMrsPPAs1lP5vyWFYhS O/6GVslt9VQY6bq57c24XmcehBcI89Ek1D8McSYmgsvkHuNwpcip9XesbI0ARLaUZTqDjKxTYS Iww= Subject: Re: [RFC] Image templates To: Henning Schild CC: , References: <6bf9a786-51b8-2430-90f5-2857746d003f@mentor.com> <20201201101307.296d4029@md1za8fc.ad001.siemens.net> From: Cedric Hombourger Message-ID: <2a531834-21b5-5809-a008-9180fae44dcb@mentor.com> Date: Tue, 1 Dec 2020 11:10:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20201201101307.296d4029@md1za8fc.ad001.siemens.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Return-Path: Cedric_Hombourger@mentor.com X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-08.mgc.mentorg.com (139.181.222.8) To svr-ies-mbx-02.mgc.mentorg.com (139.181.222.2) X-TUID: RUDTAFHrme70 Hi Henning On 12/1/20 10:13 AM, Henning Schild wrote: > Did not even read it ... strong reject! Well you should :) We are not saying that our vision is 100% right or even complete but when some of users came to us to request something like this, we felt that it definitely made sense. We viewed this as a docker-type development workflow. Maybe we can make the problem statement more clear to make sure we all understand the what before we get into the how. > This smells like a mechanism to keep funny layers non OSS. While > allowing others to extend them ... without having their sources. Not at all. People shipping a base platform would evidently be aware of obligations they have to fulfill because of GPL and the like. Having a mechanism where we could tell the build to either get the prebuilt image template (sstate?) or build it from sources so that everything follows the workflow we have today is definitely something we would want (I think). > Leading to workaround hacks ... and issues in those "secret" layers not > being solved at their core. Let's not jump into conclusions too quickly please. This is just a very high-level *vision* document submitted as a RFC (which maybe should stand for Read Fully and Comment :)). We can certainly discuss the use-case (which did not come from either Joe or I by the way), get some level of agreement that it is something we'd like to support and for sure we can discuss the how. I am sure there are different ways of caching mechanism for "base" images could be provided (to speed-up builds) and the outline we provided may not be the route this project may want to take. It is certainly fine if people here conclude that ISAR would not support this use-case. I would like the discussion to remain constructive and please do not suggest that we are trying to abuse the mechanism that we are suggesting here because that's definitely not the intent, never has and never will be. > I would first remove all "mel-*" packages before adding my own ;) ... > but i would be stuck with what postinst did break ... because they > likely dont prerm ... some of users are happy with the "base" they are getting and do not see a value in rebuilding it because it consumes significant time and as Jan suggested, some people just want to build a new image with their package version N+1 and don't really need to reassemble everything underneath each time. But yes, there should a mechanism to remove packages from the base if you wish, we certainly agree here. docker also provides a similar mechanism. I am sure we will find packages that are not friendly. The example of a missing prerm is a good one. Let's be clear, packages that I have seen created with Isar by several people/companies mostly focus on the do_rootfs_install / do_rootfs_postprocess flow. Many of those packages wouldn't play well in a pristine Debian environment. I would view this as an opportunity to get those packages to be more Debian compliant than they are today. In fact, I am very routinely recommending people I am working with to avoid using Isar for the purpose of creating a Debian. In my very humble opinion, packages should be designed/implemented/tested first in a pristine Debian environment and integrated into your Isar workflow (via an "inherit dpkg" recipe) when they are ready (while the variable injection mechanism provided by ISAR/bitbake is very powerful, it is also a recipe for creating non-reproducible packages or packages that aren't buildable without ISAR). Anyhow, this would be an entire new topic (I think); I would recommend for the sake of this discussion that we assume that packages are all "compliant" / "well-written" > Maybe i do not get it, you are jumping from a pretty "lame" motivation > right into implementation. Not a singe line of code was written. we wanted to socialize the idea first. If we eventually get into an agreement of the use-case and hopefully vision of how this would look like at 30,000 feet, the next step would be the creation of a detailed design (possibly with some PoC code to validate the plan). > > Let us look at the problems we currently have, who has them, why they > have them ... and later see what we could do. I agree wholeheartedly. Problem statement as received/understood from our user-base: "our system image is quite large because it includes a full desktop, an office suite, a browser and many other things" (user/customer did ask for all of them to be included). "Builds are taking a lot of time, we would like to have the build system just chroot into the existing image and install our new packages right away instead of recreating the rootfs from scratch because we are not touching the base anyway" So maybe image templates isn't the way to go and some mechanism that would (1) update the existing package database in the rootfs, (2) use apt to upgrade packages that are already in there and (3) install any additional packages could be the way to go. We are happy to throw away our initial proposal and create a new one if you prefer to stay away from the docker-model and instead focus on e.g. an incremental rootfs build or any other way being proposed here to speed up the build when just a few packages are either modified or added (and maybe removed as well?) > > I seriously doubt the idea that a "product" can be built by adding a > few packages to a base image. A prototype or dev image is more likely well the docker model has been quite successful ? :) but again, if we agree that an incremental rootfs build is the way to go (or any other) then you will definitely get our support and we are hoping that we could contribute. Our primary objective to find a solution to the problem that was reported to us and that in a way where both ISAR users and maintainers are happy. We do welcome any feedback > ... > And imagine yourself bumping a layer onto a new base-binary ... say > after a buster-bullseye, NetworkManager->systemd-networkd, > cron->systemd-timers jump ... good luck writing/reading that Changelog I am sure there are corner cases that needs to be taken into consideration and that would definitely be part of the design exercise (remember this is just a "vision" document to seek alignment before anyone of us spends too much time). If the mechanism turns out to be more of a caching mechanism, you will then end-up with the same flow as today (i.e. all customized packages built from sources, upstream packages pull from their upstream repositories and the entire image built with the exact same mechanism as we have today) > > Henning I hope this clarifies, the intent, the use-case and more importantly our desire to discuss before we go one direction or another or just halt. > > Am Tue, 1 Dec 2020 08:59:20 +0100 > schrieb Cedric Hombourger : > >> Image Templates for ISAR >> ======================== >> >> Introduction >> ------------ >> >> 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. >> >> 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_. >> >> This document will describe both the construction and the use of >> _template images_. >> >> Construction >> ------------ >> >> 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`. >> >> 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. >> >> 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. >> >> The process of constructing the base image would then continue as >> usual (with post-processing and imager tasks). >> >> 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). >> >> Usage >> ----- >> >> 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). >> >> 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. 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. >> >> 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`. >> >> 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). >> >> Future Work >> ----------- >> >> 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). >> >> Status >> ------ >> >> 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. >> >> We will be happy to answer questions you may have or provide more >> details in areas where this document would be too evasive. >>