From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6691606441411739648 X-Received: by 2002:a1c:9951:: with SMTP id b78mr570377wme.96.1558381638253; Mon, 20 May 2019 12:47:18 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:adf:8184:: with SMTP id 4ls4408780wra.5.gmail; Mon, 20 May 2019 12:47:17 -0700 (PDT) X-Google-Smtp-Source: APXvYqwU7UvPerv7jG/lqWtJ0krorpjPYtC2TLR2u6mMOf54YldRdMGqtEYde+RqE59QX4546LJa X-Received: by 2002:adf:ab45:: with SMTP id r5mr20964884wrc.100.1558381637864; Mon, 20 May 2019 12:47:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558381637; cv=none; d=google.com; s=arc-20160816; b=lNRJNZJxwoPqdh7iDLOqweERnubbe7WIUqCnwNIdIpNdVq3l5ROMTiae9LOBBvBYpX DZg3qlG1ZqZXmJlKzrgALUlhVShim4LZNnCCF8zC+U2Bb3vePeC7c2Uc6nKkdAdClqvS jFCA3Ckrn86fscOs6dsmC+rS36J/uVJKQqnz+U7et/fseeO84QS1EsvG5QMXG6jHzm0r FoBzOsHsB1vS/0FtC1nvfqPXVL+eIqt25g0ggH6/m2SCyBDs36foYZeAaXM4zgOVK0m2 81y04FGlu+0xV/FvqzPfsqo9q9V2M24ASYIq0f5WTitTrJtDvC4St9P9YLTbhcSQ+m+7 oD0Q== 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:to:from:date; bh=LPbOIhfno/ZK/DPHiCL5zu6ssJNdby3qBSD8OuG1kgY=; b=US0lPDejJR2+10sU6qA7HZTFMBCRESvDUswENdWEcr/KJ9hbHJn47kv0s2DPC5lvtN LFmj+ya2hR0RbPv/qjjcrNsQRVCCqWMYOV4nza2113RyN9/TkaDvRXaWaB8ZxkZS994y wdyAkhAqUN68+WjYmsJic7zYAzuVABffIQ3jfnn9t1r6bI+CcYV0xfsBRnXMJHl2gBjD r7dHjMNmogOAcWPT4gq8ZUcQAdUPcvvikmTC7q3ixMVhqqgBTUApW4bxjT69C4ZH1bFh i823W2Y/gnpvOokhd/IYa6W9A/R80hgfjnYQWye9Wkax+Oa1gwaW2VRyOTdb7QgTIg2d qeWQ== 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 v1si1492396wrd.4.2019.05.20.12.47.17 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 20 May 2019 12:47:17 -0700 (PDT) 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-002-207-018-003.002.207.pools.vodafone-ip.de [2.207.18.3]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id x4KJlF73029635 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 20 May 2019 21:47:17 +0200 Date: Mon, 20 May 2019 21:47:10 +0200 From: Baurzhan Ismagulov To: isar-users@googlegroups.com Subject: Re: [PATCH 2/2] Revert "meta/classes/image: Call transform_template after rootfs_install" Message-ID: <20190520194710.GI21981@yssyq.m.ilbers.de> Mail-Followup-To: isar-users@googlegroups.com References: <20190516125030.13190-1-claudius.heine.ext@siemens.com> <20190516125030.13190-3-claudius.heine.ext@siemens.com> <7de18f5d-e5ca-49ba-2497-ab70a0508c66@ilbers.de> <729803d9-2ce2-4de4-c121-a7d1d90842a7@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <729803d9-2ce2-4de4-c121-a7d1d90842a7@siemens.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: 8W3tyJDGRStL On Mon, May 20, 2019 at 09:19:41AM +0200, Claudius Heine wrote: > Because this change just painted over the underlying issue with the > non-deterministic and volatile value of the KERNEL_IMAGE and INITRD_IMAGE > variables. So I would not consider that a permanent fix but a quick > band-aid. The function returns different values depending on whether the respective task has finished. So, the implicit precondition is that the caller must depend on the kernel deployment task. Given the precondition, the behavior is deterministic and there could be other ways to fix them without sacrificing user experience. For my understanding, what was your user-level use case when you experienced the get_image_name() issue? To be clear, Maxim's patch only addresses CI and not this issue. With kind regards, Baurzhan.