From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <t.lamprecht@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 24BB06921E for <pve-devel@lists.proxmox.com>; Tue, 23 Feb 2021 09:27:58 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 1B0A11A40E for <pve-devel@lists.proxmox.com>; Tue, 23 Feb 2021 09:27:28 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (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 firstgate.proxmox.com (Proxmox) with ESMTPS id 923461A401 for <pve-devel@lists.proxmox.com>; Tue, 23 Feb 2021 09:27:27 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 541F8462B1; Tue, 23 Feb 2021 09:27:27 +0100 (CET) Message-ID: <c0308a4c-be13-7d93-6d1c-73e42aedf5e4@proxmox.com> Date: Tue, 23 Feb 2021 09:27:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:86.0) Gecko/20100101 Thunderbird/86.0 Content-Language: en-US To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>, aderumier@odiso.com References: <a7955a58255106b5ad78047547236014f3d37226.camel@odiso.com> Cc: Wolfgang Bumiller <w.bumiller@proxmox.com> From: Thomas Lamprecht <t.lamprecht@proxmox.com> In-Reply-To: <a7955a58255106b5ad78047547236014f3d37226.camel@odiso.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.056 Adjusted score from AWL reputation of From: address 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) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] cloudinit: question about cloudinit pending values && hostname/mac address changes 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: Tue, 23 Feb 2021 08:27:58 -0000 On 21.02.21 18:47, aderumier@odiso.com wrote: > I have some question about cloudinit hotplug pending values. > > Currently, when vm is running, we keep cloudinit specific values > (ipconfigX, dns, ssh,...) in pending until we regenerate image > manually. > > But some other change, like vm name (use for hostname), or nic mac > address . (use to match interface in config nodrive format), are not > keeped as pending. > > Why don't we simply auto regenerate the cloudinit config drive after > changes? (and don't use pending values like "pending cdrom > generation"). IMO OK, wasn't the other stuff done because of some changes cannot be applied live? > > Anyway, when vm is offline, we don't have pending state at all, and > config drive is generated only after at vmstart. > > Also, currently, to regenerated the iso, we need 2 api call, > 1 to remove cdrom , 1 to replug cdrom with new config. > > I really would like to be able to change cloud-init config like lxc, > simply update values, and get them auto apply. > > What do you think about it ? Sounds OK to me, without much thinking into regression possibilities. In general, I'd like to simplify cloud init anyway, IMO the whole special disk handling just brought us bug after bug with clone, migrate, ... I'd like to generate the image just in memory (e.g., /run/qemu-server ?) and just attach it from there (e.g., just using the first free IDE bus slot, adding new IDE CD ROM devices need reboot anyway, so if it has to move to another free slot its not a problem). For backups we already save the config with the state applied, so there no change is required. For live migration we'd need to transfer the current state, not much extra work but needs a few changes. For live-snapshots we'd need to save the state too (so that processes which currently have that open do not die if it changed), also a bit of changes required. But I think that would simplify this whole thing a lot, and also would not require the user to add a cloudinit cdrom to the VM, just configure it and be done.