From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 9D632692B3 for ; Tue, 23 Feb 2021 10:29:46 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 896E81B218 for ; Tue, 23 Feb 2021 10:29:16 +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 074241B20B for ; Tue, 23 Feb 2021 10:29:16 +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 BF3D44629E; Tue, 23 Feb 2021 10:29:15 +0100 (CET) Message-ID: <75c9dea4-4e42-3882-2e83-348ea1c15fe4@proxmox.com> Date: Tue, 23 Feb 2021 10:29:14 +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: Wolfgang Bumiller , Proxmox VE development discussion , aderumier@odiso.com References: <177950241.3608.1614071210039@webmail.proxmox.com> From: Thomas Lamprecht In-Reply-To: <177950241.3608.1614071210039@webmail.proxmox.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2021 09:29:46 -0000 On 23.02.21 10:06, Wolfgang Bumiller wrote: > >> On 02/23/2021 9:27 AM Thomas Lamprecht wrote: >> >> >> 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? > > Or maybe just an oversight since the VM name used to have no influence > at all before cloud init. > I'm not sure if automatically regenerating the image is such a good idea > if you consider how programs in the guest might react if they're > currently reading from a vanishing drive... (Simply because, you know, > these things tend to not be too failure-resistent ;-) ) normally the CI service reads this only once at startup and then should wait on events? Anything basing on a CD ROM device should be able to handle ejects or inject at any time... @Alexandre, did you test how good the Cloudinit clients handle this? > This would be different if we used a network-based cloud-init solution, > but that would just "shift" the required effort from the whole state > keeping thomas mentioned below to actually getting this onto a network > interface *per vm* and in a sane way. > > But yes, I can honestly also say that if you're changing cloud-init data > while the VM is currently reading it and it just crashes and you have to > hit the reboot button... that's perfectly fine with me actually. > CI crashing means probably that that change is not applied, not that the VM is rendered unusable. So you can only win, as at max for applying changes you have to do the same as you had to do always without such a change anyway: reboot