From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <f.ebner@proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 50B749457 for <pve-devel@lists.proxmox.com>; Thu, 31 Mar 2022 15:01:16 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 3074E1BB45 for <pve-devel@lists.proxmox.com>; Thu, 31 Mar 2022 15:01:16 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id E759B1BB37 for <pve-devel@lists.proxmox.com>; Thu, 31 Mar 2022 15:01:14 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id B7D4243078; Thu, 31 Mar 2022 15:01:14 +0200 (CEST) Message-ID: <53db0ad2-e34d-7e84-0d27-b42e03c49651@proxmox.com> Date: Thu, 31 Mar 2022 15:01:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: pve-devel@lists.proxmox.com, aderumier@odiso.com, Thomas Lamprecht <t.lamprecht@proxmox.com> References: <20210609115417.3326775-1-aderumier@odiso.com> From: Fabian Ebner <f.ebner@proxmox.com> In-Reply-To: <20210609115417.3326775-1-aderumier@odiso.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.114 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH v3 qemu-server 0/7] cloudinit pending behaviour change X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Thu, 31 Mar 2022 13:01:16 -0000 Am 09.06.21 um 13:54 schrieb Alexandre Derumier: > Hi, > > This is an attempt to cleanup current behaviour of cloudinit online changes. > > Currently, we setup cloudinit options as pending, until we generate the config drive. > > This is not 100% true, because some option like vm name, nic mac address can be changed, > without going to pending, so user can't known if it need to regenerated it. > > Also custom config can be done with snippets file, without any pending state. > > Also, some can are very difficult to handle, if you hotplug a nic but it's failing,so pending, > then you defined an ipconfig, and then you revert hotplug. > > (This will be really usefull with ipam implementation, where ipconfig pending state is really > needed, as we need to follow the pending state of the netX interface) > > So, instead of setting cloudinit values in pending, > this patch serie extract the current config from the cloudinit drive and compare it to vm config (pending config). > > (Currently the vm config is simply copied inside the iso at generation, but we could implemented > configdrive format parsers) > > A new specific cloudinit config api is added too, merging ipaddrX && netX mac > in same field, and displaying the diff between current and generated config. > (we could implemented read config from custom snippet too later) > > First off all, sorry for the very late review. The biggest question still is which approach should be used. Two downsides of this approach: * The VM config is made available inside the guest via the ISO, but the guest doesn't really have any business knowing it. * The extraction is a bit involved/costly. And technically, we'd need to lock the config during the extraction (so the drive can't be removed under our noses, and to prohibit two extractions at the same time). And it's difficult to tell if extraction failed because it's an old image that doesn't include the config yet, or if it failed for real. So IMHO the other approach is a bit better. Much of the review should also apply to v2 of the series. A small problem with both approaches is how to handle already existing configs, because everything will show up as changed. Not really sure what could be done about that though. Ignoring it and having it auto-fixed the next time the cloud-init is generated doesn't seem too bad.