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) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id D9EC198705 for ; Mon, 24 Apr 2023 20:06:42 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id BD6BC34273 for ; Mon, 24 Apr 2023 20:06:12 +0200 (CEST) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Mon, 24 Apr 2023 20:06:11 +0200 (CEST) Received: by mail-ot1-x32e.google.com with SMTP id 46e09a7af769-6a5ef766282so3661069a34.0 for ; Mon, 24 Apr 2023 11:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wolfspyre-com.20221208.gappssmtp.com; s=20221208; t=1682359564; x=1684951564; h=date:to:in-reply-to:references:message-id:subject:mime-version:from :content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=0qDpF548HSds61+sl/ty7WNipnhBa7cI6fWHiEAnCWY=; b=qZpsz+31D+pmrjPrbyDZc6ffVV1l2g6pcMxd7zrkuC8inYApvPkJQpE26FCsoENY69 dOWkZittMoj89ulsVwrV9SlIDU2zdkEiHxTYggrKYsXZHQnJ+zi6G+ptyMaUGON5wuc1 0l+pLf16TiFdiz1OPISX+DLTIlWORm7dOWrBsIUAs41R7hhKg2/obDcaEV39pRt2ouPb MKa9C3zVcMLjjrb9eFCIWUza00vnwqsgkT0t08ndZpWAqnD9P6cYOrjNZsPP4z2BT6KZ +gd8lU/XhGcTpzEtcYOTGZRseB0wAhTTFch6Ep+vtQ3rc8GFzDWv3ptf9ChIWVBcAsvi I9xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682359564; x=1684951564; h=date:to:in-reply-to:references:message-id:subject:mime-version:from :content-transfer-encoding:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=0qDpF548HSds61+sl/ty7WNipnhBa7cI6fWHiEAnCWY=; b=imXg7tosTlu0XdJB1uWojWlv26hoyqjOQyJHMjKu79t5c+x5IQHgRKba3RnZH9/Usu uPfWI+SpcYM7VUBpi1LYXxMGeH2ahAImGSQTHkZ5IZgPFx7HmZeTMO3tXrTswl6oIY+K U8/+WNCGjqcig1Vg4aeFHqRt8zcs7+3fEzH4sEbGeQeQoBb4b6Wa5tvBxkUspCm6Z7pB baig59ODIBWm7qc2o/g1XKl7tT4thPK6Wo4gThTGUboIXBMBhwAlD2odBTu/+L8ctax5 pK6KsS9hXsX5/a/jC8jW1HsKN+P+doY4W1Dj6vPE5y72YorZZ0XM/eVUAt1taoXZGPOB ws0A== X-Gm-Message-State: AAQBX9dsFlGH3ZkdRQT5zj0zVwwoCwrIpkrBgIXQQWhyuzXz4x/Cy7sz kVwhvY4KM4G7KxfLN7C1kjuMiCwGWMCiIB2lyLvkgRI1 X-Google-Smtp-Source: AKy350YFO6pZZWoJetDhC/TXTtt5ehyvwBPwQWDHYae48RNK56IWCksRDuX1Rb/ME1iRKcarh2JsUw== X-Received: by 2002:a05:6830:22d5:b0:6a6:389f:ad88 with SMTP id q21-20020a05683022d500b006a6389fad88mr6278666otc.13.1682359563660; Mon, 24 Apr 2023 11:06:03 -0700 (PDT) Received: from smtpclient.apple (who.wolfspaw.com. [108.221.46.19]) by smtp.gmail.com with ESMTPSA id h5-20020a9d6405000000b006a65be836acsm1539084otl.16.2023.04.24.11.06.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 Apr 2023 11:06:03 -0700 (PDT) From: Wolf Noble Mime-Version: 1.0 (1.0) Message-Id: References: <1682326436.dqh5ge6k9n.astroid@yuna.none> In-Reply-To: <1682326436.dqh5ge6k9n.astroid@yuna.none> To: Proxmox VE development discussion Date: Mon, 24 Apr 2023 13:05:52 -0500 X-Mailer: iPhone Mail (20F5039e) X-SPAM-LEVEL: Spam detection results: 0 AWL -0.042 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DMARC_MISSING 0.1 Missing DMARC policy HTML_MESSAGE 0.001 HTML included in message MIME_QP_LONG_LINE 0.001 Quoted-printable line longer than 76 chars RCVD_IN_DNSWL_NONE -0.0001 Sender listed at https://www.dnswl.org/, no trust 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 - Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [pve-devel] Feature idea: import cloud images as disks, or at VM creation 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: Mon, 24 Apr 2023 18:06:42 -0000 I would think (always dangerous) that the ability to create new VMs from see= d images of differing levels of administratively-blessed sources would warra= nt a few privilege classes to be able to=20 (off the top of my head) - add new image collections - bless new images - flag images as =E2=80=98preferred=E2=80=99 =E2=80=98testing=E2=80=99 =E2=80= =98sunsetting=E2=80=99 =E2=80=98deprecated=E2=80=99 =E2=80=98undeployable=E2= =80=99 - create new flag-flavors - add/alter privilege bundles in relationship to flags - share image collections with another (cluster/customer) - check for updates to/fetch new existing blessed images - create new singleton vms from these blessed images - create an arbitrary set of images to be usable as a privilege construct ((= ie users with privilege X may create N vms from group Y )) - CRUD storage locations for caching of blessed images) for example: 1) download $cloud-image from $vmfactory 2) add local environment secret sauce 3) spin up a vm from new image and run some scripted automation tasks valida= ting (some stuff still works with new image) security requirements are imple= mented=20 4) flag image as blessed if sniff test doesn=E2=80=99t cause problems 5) remove/reclassify superseded images=20 this proto workflow could be automated via CI for acceptance=E2=80=A6 and r= un on a schedule permitting cluster users to be able to receive regular upda= ted vm seeds while maintaining compliance requirements =E2=80=A6 with minima= l administrative overhead=20 granted; this is a long way down a theoretical journey =E2=80=A6=20 i=E2=80=99m just trying to think through what constructs would make sense to= ensure they could be implemented tomorrow should it be deemed a good idea=E2= =80=A6 [=3D The contents of this message have been written, read, processed, erased= , sorted, sniffed, compressed, rewritten, misspelled, overcompensated, lost,= found, and most importantly delivered entirely with recycled electrons =3D]= > On Apr 24, 2023, at 04:01, Fabian Gr=C3=BCnbichler wrote: >=20 > =EF=BB=BFOn April 24, 2023 10:01 am, DERUMIER, Alexandre wrote: >> I think it could be done with some kind of new naming for this kind of >> disk, >>=20 >> like "template-....." in the storage >>=20 >> to match current lxc behaviour. >>=20 >>=20 >> I don't think we need to vm template itself inside this, only the disk. >>=20 >> then use could create a vm like >>=20 >> qm create --iscsi0:template-..... >=20 > we basically already have this, it's just not yet on the GUI ;) >=20 > $ qm create/set 123 --scsi0 TARGET_STORAGE:0,import-from=3DSOURCE_STORAGE:= VOLUME,other_option=3Dvalue >=20 > will import an existing volume (or, if highly privileged, arbitrary > image/block device) to a newly allocated volume on TARGET_STORAGE. >=20 > also mentioned in the docs for cloud-init: >=20 > https://pve.proxmox.com/pve-docs/chapter-qm.html#_preparing_cloud_init_tem= plates >=20 > we haven't fully hashed out yet how to integrate it into the GUI, but > it's already available on the API and CLI.=20 >=20 > one part that might still be worth of discussion is whether to add a new > dir or naming scheme on storages for VM template files like downloaded > cloud(-init) images, and then on the GUI only offer up those and volumes > of VM templates as sources (at least by default), instead of *all* > images accessible to the user. >=20 >=20 > _______________________________________________ > pve-devel mailing list > pve-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel >=20