From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <m.limbeck@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 8D8D3606B1 for <pve-devel@lists.proxmox.com>; Wed, 9 Sep 2020 16:05:35 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 82B7F12969 for <pve-devel@lists.proxmox.com>; Wed, 9 Sep 2020 16:05:35 +0200 (CEST) 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 806AD1295B for <pve-devel@lists.proxmox.com>; Wed, 9 Sep 2020 16:05:34 +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 4753844AD1 for <pve-devel@lists.proxmox.com>; Wed, 9 Sep 2020 16:05:34 +0200 (CEST) To: pve-devel@lists.proxmox.com References: <kcRK.AAAAAAJZh+74Ak+ZgfTuugd5TBgBAAAABQAAAC9qJF5oxmZOmbnepn3tg6UAAAAA.ADLiDM+C1gE=@mx.giftfish.de> From: Mira Limbeck <m.limbeck@proxmox.com> Message-ID: <52868585-8944-188c-3548-97c91d138ab3@proxmox.com> Date: Wed, 9 Sep 2020 16:05:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <kcRK.AAAAAAJZh+74Ak+ZgfTuugd5TBgBAAAABQAAAC9qJF5oxmZOmbnepn3tg6UAAAAA.ADLiDM+C1gE=@mx.giftfish.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-SPAM-LEVEL: Spam detection results: 0 AWL 1.340 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 -1.626 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 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [hetzner.cloud, proxmox.com] Subject: Re: [pve-devel] [PATCH qemu-server] api: cloud-init support for mtu and userdata 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: Wed, 09 Sep 2020 14:05:35 -0000 Hi, On 9/4/20 5:21 PM, proxmox wrote: > Hello > > > > I didn't know this patch mail got approved, so sorry for the (very) late response. > > > > My intention for not going with snippets was the fact that they could not be created via the API and one would have to manually create a file on the target machine for cloud-init userdata. There is currently a bug report open for this: https://bugzilla.proxmox.com/show_bug.cgi?id=2208 This together with backup and migration of snippets could be useful. > > > > One possible use case was to spin up a kubernetes cluster on proxmox only via API. > > > > I wanted to have something similar to the hetzner cloud API where the full userdata can be submitted for VM provisioning: > https://docs.hetzner.cloud/#servers-create-a-server > > > > So going further here you want me to submit the MTU patches separately? The MTU patches separately would be great. > > > > Should I integrate userdata into the cicustom field? I thought this would make things more complex in favor of parsing out the base64 stuff. So I would still go with an extra field. After some discussions we think that putting the userdata in the config file is not the right approach. As the cluster filesystem is limited to 32M and a single VM config file is limited to 512K you can easily run into the limit with a small number of VMs. We would most likely have to limit the userdata per config to a very small amount (1K?). But with those limits it is difficult to get everything in. > > Thoughts? > _______________________________________________ > pve-devel mailing list > pve-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel > >