From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id C70C31FF392 for ; Tue, 25 Jun 2024 16:55:59 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 74A941272B; Tue, 25 Jun 2024 16:56:08 +0200 (CEST) Message-ID: Date: Tue, 25 Jun 2024 16:55:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Thomas Lamprecht , Proxmox VE development discussion References: <20240612144549.165990-1-f.schauer@proxmox.com> <8464a86e-0006-4e07-90f0-e59008d7aac4@proxmox.com> Content-Language: en-US From: Filip Schauer In-Reply-To: <8464a86e-0006-4e07-90f0-e59008d7aac4@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL -0.113 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_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 Subject: Re: [pve-devel] [PATCH storage] add API method to move a volume between storages 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: , Reply-To: Proxmox VE development discussion Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" Superseded by: https://lists.proxmox.com/pipermail/pve-devel/2024-June/064283.html Ended up moving the API method to the POST endpoint at /nodes/{node}/storage/{storage}/content/{volume}, replacing the experimental copy method. On 14/06/2024 19:29, Thomas Lamprecht wrote: > some higher level review: > > subject could mention CLI too, e.g.: > > api, cli: implement moving a volume between storages > > Am 12/06/2024 um 16:45 schrieb Filip Schauer: >> Add the ability to move a backup, ISO, container template or snippet >> between storages of a node via an API method. Moving a VMA backup to a >> Proxmox Backup Server requires the proxmox-vma-to-pbs package to be >> installed. Currently only VMA backups can be moved to a Proxmox Backup >> Server and moving backups from a Proxmox Backup Server is not yet >> supported. > Interesting integration of the vma-to-pbs importer! I'd proably make this > copy by default and do the remove-source-volume-on-success only through an > opt-in parameter, similar to how the similar, but more specialized, "move > guest disk/volume" works. > >> The method can be called from the PVE shell with `pvesm move`: >> >> # pvesm move > For the command and the API endpoint path I'd prefer using 'move-volume' as > name. That would clarify what the subject is, and not imply that one could > move a whole storage, a feature which some users also might want as separate > feature. > > Speaking about API paths, in theory mounting this below the > `/nodes/{node}/storage/{storage}/content/{volume}/` path would be quite a > bit nicer. But, currently that's not trivially possible as we already use > the GET endpoint of that path for getting the volumes attributes. > > So here we have three choices: > > 1 decide that it's better to keep it as a separate path at the {storage} > top-level (or even if we don't agree on that being better, just close > our eyes and look away). > Can be OK, but as we face this pain every once in a while I'd at least > think about the alternatives below, even though they would extend scope > quite a bit. > > 2 try to use the existing structure, which might need some adaptions in > the router/schema stuff, as we essentially would need to learn to > pull the list of API subdirectories out of a nested variable inside > the object. As currently API directory indexes use a top-level array > so any API endpoint that returns an object at the top-level cannot > be really extended to also host API endpoints in subdirectories. > If we could specify in the schema that the href array is returned in > a sub-property we could add deeper links much more easily in the > future. > Here the most important thing would be to check potential negative > drawbacks of doing so, and also how much work it would be to add > that functionality (I did not check, gut feeling tells me that it > probably is not _that_ much, as it should be mostly adding a check > about getting the same info from another location). > > 3 using a new API path, e.g. doing s/content/volume/ where the GET > endpoint is a router index and the "metadata" one gets provided > inside that API path folder. Then we could slowly deprecate the old > one and be done. > > What, and if, those options make sense can be debatable. IMO checking > out 2 could be good as we run into this "problem" every once in a while, > and having the possibility of 2 would avoid shuffling API paths around > just to be able to do deeper nesting. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel