From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6927266035414335488 X-Received: by 2002:a5d:6d0c:: with SMTP id e12mr17348359wrq.136.1613382413980; Mon, 15 Feb 2021 01:46:53 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:2e44:: with SMTP id u65ls164883wmu.2.canary-gmail; Mon, 15 Feb 2021 01:46:53 -0800 (PST) X-Google-Smtp-Source: ABdhPJz7xRfnFgtANht5sckmam+KM4QA4bxADbYf8/HrIteSJEhwQS6QRK8F+YhBINiJcSdVYTxb X-Received: by 2002:a1c:2b05:: with SMTP id r5mr13433312wmr.179.1613382413119; Mon, 15 Feb 2021 01:46:53 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1613382413; cv=pass; d=google.com; s=arc-20160816; b=Vzdb8muepaVH8WE8cfNj3XDfGdto1jZKEr3hMSfKZXOcgMKh5bK+R7xtTjmPdsc4hC PlHKUSp3+WNPbI6/J3h3FfIXPUDfiGstzLvAUQPvGlUJ2OqYVTvRmI65CEOqXLk+9L94 7g8+jZI1FwqLOPBzeIKo7l37PdbebHKBvzn2tsBn1gLSixl8mZY/mQQcsd5MVgE4ns+n ag9APU+NRuPUcKtUVjrirAAMiLzGMjxPTxNfBqhDES4X66EmSIVSU9iez4F9DPQQ06HG pcUvcEU4IC8tEDDKPEdeYUez4b1fy9y9CnhY4P+tWm2QSiGAN+TQWVMrAExJCg4xlvMS TfrA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:content-language:content-transfer-encoding:in-reply-to :user-agent:date:message-id:from:references:to:subject :dkim-signature; bh=jchK2QJm3lGDmdl8f5T3KOG4PQ25R0NNRsB1D+lmNS8=; b=JfeHVa1DBGPeE7jU4rLgEe4/yTvzAsZCIXpL4acNLdSeygCy57wZDe6lpBgBtjgq9N 6owmQF3S932qVy81Xn3jhLbiRw23cHKXD4D+Xw/JHBeu8+X97aKc62wdyukEN4SAaAaF TB/NQEN4iM7w25+smboot8jvqPQhCtLoScraflThZmGDzDVFOJI86xBNJbcMivRYja7h 1TG7H5ZUDaytoikMsWzExyg4SYGpYec0kJw9IGljd9ooSSzUraZt0yZYsNcUNOq1pOVG qeBwfGvYShjA0mGAis214QxgmQ16PDjVj76tL7iY/ggv5rA7u6ARl6z83INejHY8Pb2i EPdw== ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@siemens.onmicrosoft.com header.s=selector1-siemens-onmicrosoft-com header.b=gwVsW4sI; arc=pass (i=1 spf=pass spfdomain=siemens.com dkim=pass dkdomain=siemens.com dmarc=pass fromdomain=siemens.com); spf=pass (google.com: domain of silvano.cirujano-cuesta@siemens.com designates 40.107.5.47 as permitted sender) smtp.mailfrom=silvano.cirujano-cuesta@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50047.outbound.protection.outlook.com. [40.107.5.47]) by gmr-mx.google.com with ESMTPS id v6si150206wri.3.2021.02.15.01.46.52 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Feb 2021 01:46:53 -0800 (PST) Received-SPF: pass (google.com: domain of silvano.cirujano-cuesta@siemens.com designates 40.107.5.47 as permitted sender) client-ip=40.107.5.47; Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@siemens.onmicrosoft.com header.s=selector1-siemens-onmicrosoft-com header.b=gwVsW4sI; arc=pass (i=1 spf=pass spfdomain=siemens.com dkim=pass dkdomain=siemens.com dmarc=pass fromdomain=siemens.com); spf=pass (google.com: domain of silvano.cirujano-cuesta@siemens.com designates 40.107.5.47 as permitted sender) smtp.mailfrom=silvano.cirujano-cuesta@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TSz7Fv+nHxUD3ANFLk8iOjswneN6ZDMBYz5CTVXYUdeyeaCtybPjVNijvrnHRK2ollCWVK6bCP2lri88ZkEp1u/4MdyhCa0EntPz8lfe+KWvmgtcQS6V61eRL71etKOS0QKsOc8Hhcfe9YrTldliO57av6DpRhvWPYdNVTTYDcNfQ+Ho2BnZ9G+MVTg47qMLU1rIvCwulwMO/5+NJeHFr/xIF3v6bWj9RGuHZZnJHdskxYJf2InPsJ9GPI3qVJA2/AXTH17G4kH84rlLmWptbFxLSTZ3FLOwVqI36t0EZ+QSK95SClSKJnDoiKawLAWqgq8XTZkzsw2Zzps6V//WRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jchK2QJm3lGDmdl8f5T3KOG4PQ25R0NNRsB1D+lmNS8=; b=bE8D5OdZIUjqC3FSPRAwJgeSmydB7260k6l1TbcVfr8m/lZZ1LcEo8wajBdUDXDfBPmUmmGi2gZOsA15zswB2SykKNE6BVPbspYTw0MibEqcnzKIiAlW2mYMnf/amOSl9eh7QplLEUiF6nST+UIRTG5KjaqXty6zrA+MezdjUDItiehWJ0uALXHE+2/W6SeC37a6eDvTMxyaw9DYxcrKhh44xGLbxijq80nSsrYlJClHLrHWXtuLb3k57n7OL9gLUbbgpCa5M8E0mUGY13/O4PvRvhchb9xZwqNRA2wML3Mfv3QwP/shqAkrHBUoQEZbSAA9OGbr2uI8F3HwuM5t3Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jchK2QJm3lGDmdl8f5T3KOG4PQ25R0NNRsB1D+lmNS8=; b=gwVsW4sIAnJVz2CP4Tg3DU/QEP0kYNnWDDqNLWeIQE/eBbwKvK9Kiiy3ULsxyhA8nk49hfhA2BKfApSadbCnxEWJ81SnA1JTMONA5LYCmZv9Ht0AxJFJgG0/jmsg8CDRv1qNx2HgCYzUeNWwSCTo5q/AfAUH5AUdEF9tl7VQZuE= Authentication-Results: googlegroups.com; dkim=none (message not signed) header.d=none;googlegroups.com; dmarc=none action=none header.from=siemens.com; Received: from AM0PR10MB2708.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:12a::30) by AM0PR10MB2033.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:50::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.9; Mon, 15 Feb 2021 09:46:51 +0000 Received: from AM0PR10MB2708.EURPRD10.PROD.OUTLOOK.COM ([fe80::14f7:2b4:e15c:c584]) by AM0PR10MB2708.EURPRD10.PROD.OUTLOOK.COM ([fe80::14f7:2b4:e15c:c584%7]) with mapi id 15.20.3846.039; Mon, 15 Feb 2021 09:46:51 +0000 Subject: Re: [PATCH v3 1/2] images: add support for container images To: isar-users@googlegroups.com References: <20210212085113.11013-1-silvano.cirujano-cuesta@siemens.com> <20210212085113.11013-2-silvano.cirujano-cuesta@siemens.com> <4f5debdf-b83f-9032-be42-00d85d83a22e@siemens.com> From: Silvano Cirujano Cuesta Message-ID: <246640e2-1c02-77e9-888e-3194630cea1c@siemens.com> Date: Mon, 15 Feb 2021 10:46:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 In-Reply-To: <4f5debdf-b83f-9032-be42-00d85d83a22e@siemens.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [2001:a61:b9b:ac02:de3a:1146:19ca:44b6] X-ClientProxiedBy: AM0PR03CA0061.eurprd03.prod.outlook.com (2603:10a6:208::38) To AM0PR10MB2708.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:12a::30) Return-Path: silvano.cirujano-cuesta@siemens.com MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [IPv6:2001:a61:b9b:ac02:de3a:1146:19ca:44b6] (2001:a61:b9b:ac02:de3a:1146:19ca:44b6) by AM0PR03CA0061.eurprd03.prod.outlook.com (2603:10a6:208::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.27 via Frontend Transport; Mon, 15 Feb 2021 09:46:51 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 0116a736-e024-4af9-bf19-08d8d1969f01 X-MS-TrafficTypeDiagnostic: AM0PR10MB2033: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:2276; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Oq1D+q9J9bglFUff6k8GxZe1EvgV6LfcDMgWcYqONj7Pj/ZordwIfDgcKJxLnRw47Yv7uYDZTt7IeRNa8vaJCeGl9o4MEButl09Y4N7e54OHEmLYT5phM0LLWxjKKEuEe1+d3WeJaM7u4WqT0oCS3NiOeGoif8bEjhT87LySynVKJclffN2OxvS1ysCjxwpKABo79OWcev95GBGSDHWHUF9KmFM8GbeOq74ar99VfZmTL/W8SFoQgZkGJcFRYpTIAkoiED3G89614n2FAztzgTijSmaThlBXJTy04jWMxIpYedlzGdIF54UZEzoV65GKFzaPG9XU2oDftanKg/klpQMvBetWni5GH0HvkgP9n3v2uUNKA4GdkDEurrAILqELzlyYpf2O4FilvrTJKJ2QpeYt4CEqKS/ShgXQUtUKdpqxuHiyyJjNkLcI/UEZklp3Y4L2mLw9zgS6aNBQOb0CdHyh8LVxPp19YV7mekWl++sNqfdhTNfIqTCk0IkN05YEvg//1angd0s60di1itkEPC0Mnq1lKJdARSS6L2bO2uZaQNna+wHDjDKM3gM0S/5LhD0UVRkQH7r0K8vvDJtvLzz5JtKY0ZcGr6/Xc8zoMAI= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM0PR10MB2708.EURPRD10.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(4636009)(346002)(366004)(39860400002)(376002)(396003)(136003)(6486002)(8676002)(86362001)(2906002)(2616005)(478600001)(66476007)(186003)(16526019)(66556008)(5660300002)(30864003)(31696002)(316002)(83380400001)(66946007)(53546011)(36756003)(6916009)(31686004)(8936002)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?Zjg1djRNSklPL3I1aXNhSG11WStnb1F5ckhEaVFtUFlDNHU4bzNsWWk3NjR4?= =?utf-8?B?UmZaa1YweDk0V1Q0ZmcvMXd0NlVzaURDSkhoRHlkNHY3Z2xCZ2c0YzBuS1l2?= =?utf-8?B?bkRzQ2pJd1ROazRJc0pmcEg0ZnNDMzZQV1JhSjhjZDR5MUMya1R5NFBYL1pW?= =?utf-8?B?R0xURjJXOHE1NG5qMk83cEw1WnpQNkF0dnJEL1UrZy9iZ29MbXhtdDIxVFdY?= =?utf-8?B?QnBlOHNuZ0RGRjlnYlRya1pxdEVobE5PRTBrdkFlRHBTZTJxMlJqODVFNUI1?= =?utf-8?B?RUxhK1g2bWhGQ242RVpWUThsMWVXZ21vM0xIOVd0Wk1yUXZ1QmVjdzFia0F3?= =?utf-8?B?VzhENW0yekZSdnArbjBzYlk2aXk4NkRZOVZraXBmdlB3M3FqRmc5STBNLzN3?= =?utf-8?B?UmVNT0xnWEY4TWIxczlrVG9rQm5Ma3E2NUlxcGZGbGJCQzhwVXhDV2lWR1g3?= =?utf-8?B?QjJDU1dldFAySjhIRnN4a1FPNWVKOE9DMFA3UERkdEUweUFyelR3NmRnYmRw?= =?utf-8?B?eTN0RmlCM3ExTnZtWlVzQk9MM0Q5K1BCaDZzTnpoUFc3NTQ2Y2xrMys2Q0pp?= =?utf-8?B?NXc0NmpkenVWbWZHSmNVakx0YWpZTGlFOGtUc2VBY1FiQTJFck5YVWR6Vmo3?= =?utf-8?B?L1F3YnV1SllDem9TSVJPc2J6VEZ6NFBsaHlLWHhBemtYRkVQTy9NK3FwS0lh?= =?utf-8?B?ck5WdHJwMEk5R1NvVDJhbnFVclVFL3RmdGFuSUJ6cFp5NWQ2T1oxdVpUeERO?= =?utf-8?B?R2F0eHliRk94bFNRRkxINmFEWFNGZG9xR1FBaGFrS0ppd3J6TE5BUXdlS0t0?= =?utf-8?B?d3h2WVJRck9KbFl2VnZRYlgwR1VtV0VydER1aEtLdmIzTXZOL1grR09MSG9D?= =?utf-8?B?VWxJVGswMzhUTnk5NmZ6WDZZbkY1OVY0RDk0RitiaERpZmJjNnhrY3Q2RTUv?= =?utf-8?B?Y0VrUUoweFJiVTQyK0xPcFg0Qk9WRkxjaVU0bllLa3ZHYXJFWmVWUFdtZ0dx?= =?utf-8?B?WFNZSVVRb3pHOUFrZlEzZlJuUXN0NWJoZGZUbFRvN3hsLzU5MzkxTWliVk14?= =?utf-8?B?L2tCRUdUZW84dVZ0YW9NUHpNWFF3ZHlGZVFOSnY5dlliTWZ0c043RExJRVVQ?= =?utf-8?B?NkV0NGJpblVPQ3NRQ2plNEY1a2FCOHp2aFovYllaK25FVkFlQlhUazNpZnJM?= =?utf-8?B?a3BaSjdnZXBMRURLaUxhQVkzTkV6YmltNE5uTEVFeFIzRWtNODZyRlhMOEEz?= =?utf-8?B?NXp1ZUxYOWcvdnlYNkM5eXIrU25VRHd3VXN0Sm9XOVg1WCt4RnBIMytoZENL?= =?utf-8?B?dkZZV1RCczFoVy9mNk9DV3pKa2tQN1dqODg4YTlHZTB2dWRFVE93WnZuUTBh?= =?utf-8?B?Q2xkMXh0L3ZSRE9IUjEwbDZxQnliTXNObThJVnl0V2NmYzdQbTY2NFVaZi9Y?= =?utf-8?B?cDI0SFh0cEY2UWcyY2lUdVNFSDBpMVJnMnU3Zzd5L1NrV1RmRDlNaFJIOWIx?= =?utf-8?B?NHhBSkhJMEROVTBQWm5mQURKZ1ZGQnliZFFqMk5qUmhRZkx1SlVJcmRWbXZ4?= =?utf-8?B?a09PbmdIMG80SmR6TUlKK0RTY3A3TTRFTWYrcmJFRy82YmNvWktCbGxlMUpJ?= =?utf-8?B?Z2dGaXRITW83Q3JPRkU2VXBKL3lzYmhTblNvNEdmempqdlJkTWxRZVcvREVn?= =?utf-8?B?SE1Udm5jZXdmd2xQd1FTZ0x3VW1jVTZkcU96UW9MQTBaeE1ibDZ3OW5tK1Vq?= =?utf-8?B?cU9wK2M3WWVXTThYQ2dEUmYzUGorMCs5OFh2bm5KQ2tvSkpWSDYrOGFrSVQr?= =?utf-8?B?NFA1S0QxQjNBU3J0d2g4N3N6SENtNE5sVzFWb3ZDK1B1VmRsVlpSOFR3cGRM?= =?utf-8?Q?C1V+YpnFXsM8A?= X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0116a736-e024-4af9-bf19-08d8d1969f01 X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2708.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Feb 2021 09:46:51.7195 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: AWBK5aEU4dkA1qVVSK8hrxHpUyRra9/D1OK3JA9/pt1Lpz+R2GV89EZ9ACseV4TUeIav2Qh2ev79dJamzbLON8y+J0P1A0at/OOQ9DmDDHkQyJeYgcbyCyIyn4gFlnOm X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2033 X-TUID: iNAdgrKha/gp Wouldn't it make sense to put the "containerize_rootfs" function in a separate class and let "image.bbclass" inherit from it? The current structure that I have come up to seems weird to me, it isn't obvious that "containerize_rootfs" is meant to be reused. (-) an additional class for a single function (+) better structured code Possibilities that seem to fit somehow: - specific class "container.bbclass", - specific class "image-container-extension.bbclass" - existing class already being inherited by "image.bbclass" ("rootfs.bbclass" -is it a rootfs feature?-, "image-postproc-extension.bbclass", "image-tools-extension.bbclass") and I cannot tell which one fits best. Silvano On 12/02/2021 19:23, [ext] Silvano Cirujano Cuesta wrote: > On 12/02/2021 19:06, Jan Kiszka wrote: >> On 12.02.21 18:46, Silvano Cirujano Cuesta wrote: >>> On 12/02/2021 18:10, Jan Kiszka wrote: >>>> On 12.02.21 09:51, [ext] Silvano Cirujano Cuesta wrote: >>>>> Add support for creation of container images with the build root >>>>> filesystems. >>>>> >>>>> Extend also task "populate_sdk" to support the creation of a container image >>>>> containing the SDK. >>>> Should be done in to steps: container-img.bbclass frirst, and then a >>>> patch to use it for the SDK as well. >>> Ok. There are some many different tastes WRT to big vs small commits :-) >> Rather /wrt logically separatable steps. >> >>>>> Signed-off-by: Silvano Cirujano Cuesta >>>>> --- >>>>> meta/classes/container-img.bbclass | 88 ++++++++++++++++++++++++ >>>>> meta/classes/image-sdk-extension.bbclass | 51 ++++++++++++-- >>>>> meta/classes/image.bbclass | 1 + >>>>> 3 files changed, 133 insertions(+), 7 deletions(-) >>>>> create mode 100644 meta/classes/container-img.bbclass >>>>> >>>>> diff --git a/meta/classes/container-img.bbclass b/meta/classes/container-img.bbclass >>>>> new file mode 100644 >>>>> index 0000000..35c7bbc >>>>> --- /dev/null >>>>> +++ b/meta/classes/container-img.bbclass >>>>> @@ -0,0 +1,88 @@ >>>>> +# This software is a part of ISAR. >>>>> +# Copyright (C) Siemens AG, 2021 >>>>> +# >>>>> +# SPDX-License-Identifier: MIT >>>>> +# >>>>> +# This class provides the tasks 'containerize_rootfs' and 'containerize_sdk' >>>> Nope, it now only provides the former. >>> Yes, you're right, will fix it. >>>>> +# to create container images containing the target rootfs and the SDK >>>>> +# respectively. >>>>> + >>>>> +CONTAINER_FORMATS ?= "docker-archive" >>>>> + >>>>> +containerize_rootfs() { >>>>> + local cmd="/bin/dash" >>>>> + local empty_tag="empty" >>>>> + local full_tag="latest" >>>>> + local oci_img_dir="${WORKDIR}/oci-image" >>>>> + local rootfs="$1" >>>>> + local rootfs_id="$2" >>>>> + local container_formats="$3" >>>>> + >>>>> + # prepare OCI container image skeleton >>>>> + bbdebug 1 "prepare OCI container image skeleton" >>>>> + rm -rf "${oci_img_dir}" >>>>> + sudo umoci init --layout "${oci_img_dir}" >>>>> + sudo umoci new --image "${oci_img_dir}:${empty_tag}" >>>>> + sudo umoci config --image "${oci_img_dir}:${empty_tag}" \ >>>>> + --config.cmd="${cmd}" >>>>> + sudo umoci unpack --image "${oci_img_dir}:${empty_tag}" \ >>>>> + "${oci_img_dir}_unpacked" >>>>> + >>>>> + # add root filesystem as the flesh of the skeleton >>>>> + sudo cp -a "${rootfs}"/* "${oci_img_dir}_unpacked/rootfs/" >>>>> + >>>>> + # pack container image >>>>> + bbdebug 1 "pack container image" >>>>> + sudo umoci repack --image "${oci_img_dir}:${full_tag}" \ >>>>> + "${oci_img_dir}_unpacked" >>>>> + sudo umoci remove --image "${oci_img_dir}:${empty_tag}" >>>>> + sudo rm -rf "${oci_img_dir}_unpacked" >>>>> + >>>>> + # no root needed anymore >>>>> + sudo chown --recursive $(id -u):$(id -g) "${oci_img_dir}" >>>>> + >>>>> + # convert the OCI container image to the desired format >>>>> + image_name="isar-${rootfs_id}" >>>>> + for image_type in ${CONTAINER_FORMATS} ; do >>>>> + image_archive="${DEPLOY_DIR_IMAGE}/${rootfs_id}-${image_type}.tar" >>>>> + bbdebug 1 "Creating container image type: ${image_type}" >>>>> + case "${image_type}" in >>>>> + "docker-archive" | "oci-archive") >>>>> + if [ "${image_type}" = "oci-archive" ] ; then >>>>> + target="${image_type}:${image_archive}:latest" >>>>> + else >>>>> + target="${image_type}:${image_archive}:${image_name}:latest" >>>>> + fi >>>>> + rm -f "${image_archive}" "${image_archive}.xz" >>>>> + bbdebug 2 "Converting OCI image to ${image_type}" >>>>> + skopeo --insecure-policy copy \ >>>>> + "oci:${oci_img_dir}:${full_tag}" "${target}" >>>>> + bbdebug 2 "Compressing image" >>>>> + xz -T0 "${image_archive}" >>>>> + ;; >>>>> + "oci") >>>>> + tar --create --xz --directory "${oci_img_dir}" \ >>>>> + --file "${image_archive}.xz" . >>>>> + ;; >>>>> + "docker-daemon" | "containers-storage") >>>>> + skopeo --insecure-policy copy \ >>>>> + "oci:${oci_img_dir}:${full_tag}" \ >>>>> + "${image_type}:${image_name}:latest" >>>>> + ;; >>>> Missing check for "Am I in a container?", like in the SDK. Maybe move >>>> that test here and share. >>> Not needed, since the usage of IMAGE_TYPE is fixing already to container type. >>> >>> In the case of the SDK the same task is provides the non-containerized format tar-xz. >>> >> I cannot follow: What is the difference between >> CONTAINER_FORMATS="docker-daemon" and SDK_FORMATS="docker-daemon" when >> running inside a kas build container? Both do not work, do they? > I misunderstood what you meant. > > But I got it now, and that's what I meant with the messed up case section. > > In the next version the "Am I a container?" is in the function, no need to do it twice. > >>>>> + *) >>>>> + die "Unsupported format for containerize_rootfs: ${image_type}" >>>>> + ;; >>>>> + esac >>>>> + done >>>>> +} >>>>> + >>>>> +do_container_image[stamp-extra-info] = "${DISTRO}-${MACHINE}" >>>>> +do_container_image[vardeps] += "CONTAINER_FORMATS" >>>>> +do_container_image(){ >>>>> + rootfs_id="${DISTRO}-${DISTRO_ARCH}" >>>>> + >>>>> + bbnote "Generate container image in these formats: ${CONTAINER_FORMATS}" >>>> Probabably more "bbdebug"? Unsure. But we aren't using bbnote in the >>>> core so far. Nor bbdebug, though. >>> At least bbdebug is IMO needed for debbuging if goes wrong. >>> >>> BTW I'm using bbdebug a lot in the containerize_rootfs section because I've missed those kind of traces much too often when trying to debug some issues on ISAR recipes. >>> >>> Perhaps we should have more debug verbosity in the logs to ease debugging... >>> >>>>> + containerize_rootfs "${IMAGE_ROOTFS}" "${rootfs_id}" "${CONTAINER_FORMATS}" >>>>> +} >>>>> + >>>>> +addtask container_image before do_image after do_image_tools >>>>> diff --git a/meta/classes/image-sdk-extension.bbclass b/meta/classes/image-sdk-extension.bbclass >>>>> index a8c708a..63138da 100644 >>>>> --- a/meta/classes/image-sdk-extension.bbclass >>>>> +++ b/meta/classes/image-sdk-extension.bbclass >>>>> @@ -6,11 +6,25 @@ >>>>> # This class extends the image.bbclass to supply the creation of a sdk >>>>> >>>>> SDK_INCLUDE_ISAR_APT ?= "0" >>>>> +SDK_FORMATS ?= "tar-xz" >>>>> + >>>>> +sdk_tar_xz() { >>>>> + # Copy mount_chroot.sh for convenience >>>>> + sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR} >>>>> + >>>>> + # Create SDK archive >>>>> + cd -P ${SDKCHROOT_DIR}/.. >>>>> + sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \ >>>>> + -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz >>>>> + bbnote "SDK rootfs available in ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz" >>>>> +} >>>>> >>>>> do_populate_sdk[stamp-extra-info] = "${DISTRO}-${MACHINE}" >>>>> do_populate_sdk[depends] = "sdkchroot:do_build" >>>>> -do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT" >>>>> +do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT SDK_FORMATS" >>>>> do_populate_sdk() { >>>>> + local sdk_container_formats="" >>>>> + >>>>> if [ "${SDK_INCLUDE_ISAR_APT}" = "1" ]; then >>>>> # Copy isar-apt with deployed Isar packages >>>>> sudo cp -Trpfx ${REPO_ISAR_DIR}/${DISTRO} ${SDKCHROOT_DIR}/isar-apt >>>>> @@ -48,12 +62,35 @@ do_populate_sdk() { >>>>> done >>>>> done >>>>> >>>>> - # Copy mount_chroot.sh for convenience >>>>> - sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR} >>>>> + # separate SDK formats: TAR and container formats >>>>> + for sdk_format in ${SDK_FORMATS} ; do >>>>> + case ${sdk_format} in >>>>> + "tar-xz") >>>>> + sdk_tar_xz >>>>> + ;; >>>>> + "docker-archive" | "oci" | "oci-archive") >>>>> + if [ -z "${sdk_container_formats}" ] ; then >>>> Unneeded, just use the else part unconditionally. >>> The else part alone adds a heading whitespace. It's being ignored in containerize_rootfs, but it's still messing up some outputs. >>> >>> Not really useless, but not important (in fact that was my 1st version). I can change it in the next patch series version that I need anyway. >>> >> Looks like cosmetics, not functional issues. >> >> But if you dislike the leading whitespaces in the debug logs, make it >> trailing (prepend rather than append). >> >>>>> + sdk_container_formats="${sdk_format}" >>>>> + else >>>>> + sdk_container_formats="${sdk_container_formats} ${sdk_format}" >>>>> + fi >>>>> + ;; >>>>> + "docker-daemon" | "containers-storage") >>>>> + if [ -f /.dockerenv ] || [ -f /run/.containerenv ] ; then >>>>> + die "Adding the SDK container image to a container runtime (${sdk_format}) not supported if running from a container (e.g. 'kas-container')" >>>>> + fi >>>> See above, should likely go into containerize_rootfs(). >>> Right, will fix it. >>> >>> In fact this case section is really messed up, I have to clean it up completely. >>> >> OK, seems we are again on the same page. >> >>>>> + ;; >>>>> + *) >>>>> + die "unsupported SDK format specified: ${sdk_format}" >>>>> + ;; >>>>> + esac >>>>> + done >>>>> >>>>> - # Create SDK archive >>>>> - cd -P ${SDKCHROOT_DIR}/.. >>>>> - sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \ >>>>> - -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz >>>>> + # generate the SDK in all the desired container formats >>>>> + if [ -n "${sdk_container_formats}" ] ; then >>>>> + bbnote "Generating SDK container in ${sdk_container_formats} format" >>>>> + containerize_rootfs "${SDKCHROOT_DIR}" "sdk-${DISTRO}-${DISTRO_ARCH}" "${sdk_container_formats}" >>>>> + fi >>>>> } >>>>> + >>>>> addtask populate_sdk after do_rootfs >>>>> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass >>>>> index eddc444..7fb7b7e 100644 >>>>> --- a/meta/classes/image.bbclass >>>>> +++ b/meta/classes/image.bbclass >>>>> @@ -76,6 +76,7 @@ inherit image-tools-extension >>>>> inherit image-postproc-extension >>>>> inherit image-locales-extension >>>>> inherit image-account-extension >>>>> +inherit container-img >>>>> >>>>> # Extra space for rootfs in MB >>>>> ROOTFS_EXTRA ?= "64" >>>>> >>>> Jan >>> Silvano >>> >> Jan > Silvano >