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 E164B9D482 for ; Sat, 3 Jun 2023 15:57:55 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id BEDB21A4DA for ; Sat, 3 Jun 2023 15:57:25 +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 for ; Sat, 3 Jun 2023 15:57:24 +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 ECC9A48650; Sat, 3 Jun 2023 15:57:23 +0200 (CEST) Message-ID: Date: Sat, 3 Jun 2023 15:57:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: de-AT, en-GB To: Proxmox VE development discussion , Alexandre Derumier References: <20230531222834.1915972-1-aderumier@odiso.com> From: Thomas Lamprecht Autocrypt: addr=t.lamprecht@proxmox.com; keydata= xsFNBFsLjcYBEACsaQP6uTtw/xHTUCKF4VD4/Wfg7gGn47+OfCKJQAD+Oyb3HSBkjclopC5J uXsB1vVOfqVYE6PO8FlD2L5nxgT3SWkc6Ka634G/yGDU3ZC3C/7NcDVKhSBI5E0ww4Qj8s9w OQRloemb5LOBkJNEUshkWRTHHOmk6QqFB/qBPW2COpAx6oyxVUvBCgm/1S0dAZ9gfkvpqFSD 90B5j3bL6i9FIv3YGUCgz6Ue3f7u+HsEAew6TMtlt90XV3vT4M2IOuECG/pXwTy7NtmHaBQ7 UJBcwSOpDEweNob50+9B4KbnVn1ydx+K6UnEcGDvUWBkREccvuExvupYYYQ5dIhRFf3fkS4+ wMlyAFh8PQUgauod+vqs45FJaSgTqIALSBsEHKEs6IoTXtnnpbhu3p6XBin4hunwoBFiyYt6 YHLAM1yLfCyX510DFzX/Ze2hLqatqzY5Wa7NIXqYYelz7tXiuCLHP84+sV6JtEkeSUCuOiUY virj6nT/nJK8m0BzdR6FgGtNxp7RVXFRz/+mwijJVLpFsyG1i0Hmv2zTn3h2nyGK/I6yhFNt dX69y5hbo6LAsRjLUvZeHXpTU4TrpN/WiCjJblbj5um5eEr4yhcwhVmG102puTtuCECsDucZ jpKpUqzXlpLbzG/dp9dXFH3MivvfuaHrg3MtjXY1i+/Oxyp5iwARAQABzTNUaG9tYXMgTGFt cHJlY2h0IChBdXRoLTQpIDx0LmxhbXByZWNodEBwcm94bW94LmNvbT7CwY4EEwEIADgWIQQO R4qbEl/pah9K6VrTZCM6gDZWBgUCWwuNxgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAK CRDTZCM6gDZWBm/jD/4+6JB2s67eaqoP6x9VGaXNGJPCscwzLuxDTCG90G9FYu29VcXtubH/ bPwsyBbNUQpqTm/s4XboU2qpS5ykCuTjqavrcP33tdkYfGcItj2xMipJ1i3TWvpikQVsX42R G64wovLs/dvpTYphRZkg5DwhgTmy3mRkmofFCTa+//MOcNOORltemp984tWjpR3bUJETNWpF sKGZHa3N4kCNxb7A+VMsJZ/1gN3jbQbQG7GkJtnHlWkw9rKCYqBtWrnrHa4UAvSa9M/XCIAB FThFGqZI1ojdVlv5gd6b/nWxfOPrLlSxbUo5FZ1i/ycj7/24nznW1V4ykG9iUld4uYUY86bB UGSjew1KYp9FmvKiwEoB+zxNnuEQfS7/Bj1X9nxizgweiHIyFsRqgogTvLh403QMSGNSoArk tqkorf1U+VhEncIn4H3KksJF0njZKfilrieOO7Vuot1xKr9QnYrZzJ7m7ZxJ/JfKGaRHXkE1 feMmrvZD1AtdUATZkoeQtTOpMu4r6IQRfSdwm/CkppZXfDe50DJxAMDWwfK2rr2bVkNg/yZI tKLBS0YgRTIynkvv0h8d9dIjiicw3RMeYXyqOnSWVva2r+tl+JBaenr8YTQw0zARrhC0mttu cIZGnVEvQuDwib57QLqMjQaC1gazKHvhA15H5MNxUhwm229UmdH3KM7BTQRbC43GARAAyTkR D6KRJ9Xa2fVMh+6f186q0M3ni+5tsaVhUiykxjsPgkuWXWW9MbLpYXkzX6h/RIEKlo2BGA95 QwG5+Ya2Bo3g7FGJHAkXY6loq7DgMp5/TVQ8phsSv3WxPTJLCBq6vNBamp5hda4cfXFUymsy HsJy4dtgkrPQ/bnsdFDCRUuhJHopnAzKHN8APXpKU6xV5e3GE4LwFsDhNHfH/m9+2yO/trcD txSFpyftbK2gaMERHgA8SKkzRhiwRTt9w5idOfpJVkYRsgvuSGZ0pcD4kLCOIFrer5xXudk6 NgJc36XkFRMnwqrL/bB4k6Pi2u5leyqcXSLyBgeHsZJxg6Lcr2LZ35+8RQGPOw9C0ItmRjtY ZpGKPlSxjxA1WHT2YlF9CEt3nx7c4C3thHHtqBra6BGPyW8rvtq4zRqZRLPmZ0kt/kiMPhTM 8wZAlObbATVrUMcZ/uNjRv2vU9O5aTAD9E5r1B0dlqKgxyoImUWB0JgpILADaT3VybDd3C8X s6Jt8MytUP+1cEWt9VKo4vY4Jh5vwrJUDLJvzpN+TsYCZPNVj18+jf9uGRaoK6W++DdMAr5l gQiwsNgf9372dbMI7pt2gnT5/YdG+ZHnIIlXC6OUonA1Ro/Itg90Q7iQySnKKkqqnWVc+qO9 GJbzcGykxD6EQtCSlurt3/5IXTA7t6sAEQEAAcLBdgQYAQgAIBYhBA5HipsSX+lqH0rpWtNk IzqANlYGBQJbC43GAhsMAAoJENNkIzqANlYGD1sP/ikKgHgcspEKqDED9gQrTBvipH85si0j /Jwu/tBtnYjLgKLh2cjv1JkgYYjb3DyZa1pLsIv6rGnPX9bH9IN03nqirC/Q1Y1lnbNTynPk IflgvsJjoTNZjgu1wUdQlBgL/JhUp1sIYID11jZphgzfDgp/E6ve/8xE2HMAnf4zAfJaKgD0 F+fL1DlcdYUditAiYEuN40Ns/abKs8I1MYx7Yglu3RzJfBzV4t86DAR+OvuF9v188WrFwXCS RSf4DmJ8tntyNej+DVGUnmKHupLQJO7uqCKB/1HLlMKc5G3GLoGqJliHjUHUAXNzinlpE2Vj C78pxpwxRNg2ilE3AhPoAXrY5qED5PLE9sLnmQ9AzRcMMJUXjTNEDxEYbF55SdGBHHOAcZtA kEQKub86e+GHA+Z8oXQSGeSGOkqHi7zfgW1UexddTvaRwE6AyZ6FxTApm8wq8NT2cryWPWTF BDSGB3ujWHMM8ERRYJPcBSjTvt0GcEqnd+OSGgxTkGOdufn51oz82zfpVo1t+J/FNz6MRMcg 8nEC+uKvgzH1nujxJ5pRCBOquFZaGn/p71Yr0oVitkttLKblFsqwa+10Lt6HBxm+2+VLp4Ja 0WZNncZciz3V3cuArpan/ZhhyiWYV5FD0pOXPCJIx7WS9PTtxiv0AOS4ScWEUmBxyhFeOpYa DrEx In-Reply-To: <20230531222834.1915972-1-aderumier@odiso.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL -0.236 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes 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 - URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com, qemu.pm] Subject: Re: [pve-devel] [PATCH-SERIES pve-manager/qemu-server] fix#4689 autofind node with proxyto_callback 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: Sat, 03 Jun 2023 13:57:55 -0000 Hi! Am 01/06/2023 um 00:28 schrieb Alexandre Derumier: > Currently, to manage qemu && lxc vms, we always need to specify nodenam= e in uri. >=20 > This is a problem with automation tools like terraform, where is node i= s registered > in the state of terraform. What do you need here, the whole API, just some operation on existing VMs= like start, stop, migrate, or just that + VM creation? > (That mean, than if we move the vm on another node, terraform don't kno= wn it, and try to create the vm > again or can't delete the vm,...) > https://github.com/Telmate/terraform-provider-proxmox/issues/168 >=20 > This can also be a potential problem with race, if we need to query /cl= uster/ressources to find the node, then another > query on the vm. >=20 > I have some discussion with fabian about it: > https://bugzilla.proxmox.com/show_bug.cgi?id=3D4689 >=20 >=20 > This patch series, find the nodename with proxyto_callback. >> a new api endpoint /guests/ is defined: >=20 > /guests/(qemu|lxc)/vmid >=20 exposing the same API through multiple points isn't really REST-y design,= could even break things and would def. need special handling to make this= actually visible in the API schema, and thus pvesh and the api viewer, am= ong other things. >=20 > This patch series currently implement callback for api2::qemu >=20 > I'm not sure how to create vm_create when vmid && nodename is not defin= ed. > Currently the callback return localhost, so the vm is created on the ca= lled > node. >=20 > todo (if this patch serie is ok for you): ATM I'd rather strongly object this, for one to avoid that more work is d= one that then might not get accepted, which would be avoidable waste for all of us= , and as temporary reason: this definitively won't get into Proxmox VE 8.0, but as= new functionality, which doesn't breaks existing stuff, it can be added just = fine to 8.1 or 8.2 =E2=80=93 and so I'd like to postpone in-depth review and acce= pting it into the source tree until a few weeks after 8.0 Release where I got a bit mor= e time to calmly think about this =E2=80=93 because the base idea of having such= a feature is definitively compelling and I think quite a few admins and devs that r= e-integrate our API would like to see this. Still, some thoughts that I couldn't suppress ;P: - the datacenter manager might avoid a lot of such issues already, there = we need to resolve Guest ID's to nodes anyway. But, it'd require having th= at setup always, which might not be wanted. - could putting an adapter between Terraform <-> Proxmox VE API work? Did not really use Terraform, so I'm just guesstimating here. - FWIW; the HA stack already is somewhat of a automagic node resolver, bu= t naturally only for operative things like start/stop/migrate, but if one= would just require those actions then it might be a feasible way that already= exists. - We got the Batch-process API calls Endpoint already and while I actuall= y planned to remove that for PVE 8 (for other, mostly security reasons), if we'd = keep (and fix) that, one could potentially also add proxying and relaying suppor= t there. That said, I have to admit that the solution you choose, while being a bi= t hacky is really not a invasive change code-wise; But, and here still assuming we g= o that direction in the first place, I still don't like doing that in such a su= btle way. Rather, I'd add something like a "inherit" property that register_method = understands and then we could re-register API endpoint paths under another path, whil= e letting the schema and routing actually know about it.=20 I'd would probably do that even in a lightweight way, i.e., resolved dyna= mically and then also calling the "actual" original code site, to avoid potential bug= s w.r.t. imports and global variables from more in-depth copies. I.e., usage would look something like: pve-manager:# cat PVE/API2/Guests/Qemu.pm # ... use PVE::API2::Qemu; # <- required to ensure the methods we want to inher= it from got registered use base qw(PVE::RESTHandler); __PACKAGE__->register_method({ name =3D> 'index', path =3D> '{vmid}', # ... code =3D> sub { return [ { name =3D> 'config' }, # ... ]; }); __PACKAGE__->register_method({ name =3D> 'set_config', path =3D> '{vmid}', method =3D> 'GET', inherit =3D> 'nodes/{nodes}/qemu/{vmid}/config', proxyto_callback =3D> \&PVE::API2Tools::resolve_vmid_node, }); # ... other api endpoint's we like to expose in a node-independent way. 1; For that to work we'd (probably, I did not check _that_ closely) need to = adapt the base RestHandler's register_method and map_path_to_methods, but for either the= changes should be in reasonable size. For starters I'd only allow-list a few properties that can be overridden = on such a inheritance, as e.g., exposing the same thing with different privileges m= ight be questionable at best and give us some security woes. I had something like above approach in my mind for a few other things alr= eady in the past, e.g., in the Proxmox Mail Gateway we have a few places where we register = the essentially same API endpoint a few times, and do that with some adhoc loop and a bit= of not _that_ nice code; but mostly that wasn't so bad to require change and thus I did= not felt that such inheritance was required just due to that. But, if we do something like you want to have here as end result, above w= ould be for me the way I'd find the most acceptable for this. Albeit, with the disclaimer th= at without thinking this fully through and having my brain somewhat melted by the absolutely = huge amount of packages, and churn it has been through for upcoming PVE 8 ;-P IMO it would be nice as it would be really explicit, ensure that we can g= et it easily into API schema dumps without having to adapt the code managing that (at least= not in a big way) and one could even easily create a CLI tool for cluster-local convenience= things like "start that VM but I don't care where it currently is" ps. sorry for dumping a lot of loosely organized info/questions/idea here= in this reply, but I tried to get as much into it to remember when returning to this, af= ter PVE 8.0 release and post-release work is done.