From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6901194598360547328 X-Received: by 2002:a05:651c:1047:: with SMTP id x7mr9434321ljm.114.1607872842407; Sun, 13 Dec 2020 07:20:42 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:980e:: with SMTP id a14ls160158ljj.7.gmail; Sun, 13 Dec 2020 07:20:41 -0800 (PST) X-Google-Smtp-Source: ABdhPJyYALevoyuBOMJ6edfR1W0NTgGToe/+DdKw9eE9Usl2n7gOcjb9niNIIgN5Y/RFukrV00Ok X-Received: by 2002:a2e:894c:: with SMTP id b12mr6498060ljk.401.1607872841208; Sun, 13 Dec 2020 07:20:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607872841; cv=none; d=google.com; s=arc-20160816; b=r02pIHXAq7dRVE0/f/6GWadWG40zTdet7KbNaWkQ8lNfz+HM42qECJ/kHUYlqWo+Zn xwD9ecH8B8EOBqaw7OraJPZ73moeOBsJTQI7CFS54SQf8Yh0ZiKWcj1F70UupxsBdqac P7zBYUeVfpcg9ttKfjfp4lBk3daFicEutWFLa+FJowqKiWKR1Wlsf77SyG8FOx9WMHD4 eavWfm7s0oF7kyARoknlwbGTW0F404Ee9E4ZM/Oyd/2z4yT1w+wyyfEjwaJ0FkqRWYI+ y6/pcF72IyjCReZYTRs0tJhoSs0I9TutP2PI1ldMo6Ag+bDuMjtjzrCRlxWAPyIt44Ox Ouwg== 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 :mail-followup-to:message-id:subject:cc:to:from:date; bh=zaQj7l424L3J1lFMuCX3Eu/OCPF+sMlpS7AuC3pOgO8=; b=jOGLzG3cMLbiAmJ7GkR+ZwI1Fe6gYz+pil9B+5Mu5t6M+72Yqq/5yp8lkVmfhJ3Do7 nqvZK5pMUGXSbXAJ5u6iN6LOLTS5hPNV8/sfOyYFGMguGPfQ0jUOk1a89yQkpGcNg7D8 XF3hHPvFhRjWwg4KXbaerAffcb5ZaHMI5jL2i4DWmdY/ojil0xiWDCUtrV0hYSl70u/t bNb3ZZ0b4EJa80OBYz0omdn0rkXoP0GfsUT3aHiWx1c6XpAghtLjhJNI3I6Hxf/sdOHI B3hRLODCvnH3QuGVxAj6IOaDJ9S6y/zTNnfW0dZNMSE+8XM/Ra+Y/A6FCw8rOq/D4e0e 0qpQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id e8si323813ljo.5.2020.12.13.07.20.40 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Sun, 13 Dec 2020 07:20:41 -0800 (PST) Received-SPF: neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.m.ilbers.de (dslb-178-011-103-109.178.011.pools.vodafone-ip.de [178.11.103.109]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id 0BDFKb65008353 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 13 Dec 2020 16:20:40 +0100 Date: Sun, 13 Dec 2020 16:20:32 +0100 From: Baurzhan Ismagulov To: isar-users@googlegroups.com Cc: joe_macdonald@mentor.com, Cedric Hombourger Subject: Re: [RFC] Image templates Message-ID: <20201213152029.GK21864@yssyq.m.ilbers.de> Mail-Followup-To: isar-users@googlegroups.com, joe_macdonald@mentor.com, Cedric Hombourger References: <6bf9a786-51b8-2430-90f5-2857746d003f@mentor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6bf9a786-51b8-2430-90f5-2857746d003f@mentor.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: NXcIByxgVsdF Hello Cedric, thanks for the early RFC and the constructive discussion. On Tue, Dec 01, 2020 at 08:59:20AM +0100, Cedric Hombourger wrote: > 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_. Do I understand correctly, one way might look like this: * Use case: Speed up component developer workflow. * Approach: * Reuse build artifacts (rootfs, buildchroot, etc.). * Split builds (artifact preparation and consumption). Artifact reuse and developer efficiency are among Isar's goals. We've been (lazily) looking at this from the developer and CI PoVs. One step was isar-apt, although it has to be finished in this regard (with pristine sources, the packages are built even if present in isar-apt). I think especially for application developers, template images (for some reason, I always write "image templates" first :) ) would be a major time saver. We wanted to have some benchmarking first (e.g., download, bootstrap, package building, imaging) -- if you have any (even rough) figures, please share. >>From the practical perspective, I'm for any small, quick, least-invasive and conceptually complete approach that we could gather experience with and discuss the next steps. One way could be e.g.: * Deploy a template image and implement consuming it. * Package recipes depend on the template image. The image can be provided by building, or as a binary. The former is the default. One can switch to the latter in the configuration. * There is a way to check whether the image is up-to-date regardless of the current mode (e.g., a task). * Document the whole cycle -- where the image is stored, how it is copied to the working copy, etc. With this experience, we could add the template e.g. to isar-bootstrap, as originally implemented by Claudius. Regarding source package quality and license compliance, I think it's in the best interest of the product owners to provide that and isn't related to the proposal. Regarding alternative tooling, I see it rather in somewhat other areas which are also not related to the topic: * Standalone base-apt tooling would be very handy for certain use cases. As the current base-apt works, there is currently not much pressure behind this. * Returning to multistrapping would allow efficient essential package replacement. We had a discussion with debian-embedded people regarding a Python implementation. * apt introspection -- IIRC, ELBE colleagues use python-apt. * Moving to pseudo instead of sudo -- Yocto is an example that this works. In general, we could clean up e.g. lazy umounts, replace bind mounts with cp -al, etc. * From the very beginning, we were aware that bitbake provides only 80% of the functionality necessary for Debian (e.g., Build-Depends, building the pipeline after fetching). Meanwhile, we see ways how it could be improved, so we still haven't reached the bitbake vs. new tool discussion. With kind regards, Baurzhan.