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 6D9F7ABBC for ; Fri, 8 Sep 2023 12:52:40 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 49BD91089D for ; Fri, 8 Sep 2023 12:52:10 +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)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Fri, 8 Sep 2023 12:52:09 +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 7DA6E43550 for ; Fri, 8 Sep 2023 12:52:09 +0200 (CEST) Message-ID: <5e13b205-a572-4604-ad9c-0ab71f129c12@proxmox.com> Date: Fri, 8 Sep 2023 12:52:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Proxmox VE development discussion References: <20230905135122.2145462-1-p.hufnagl@proxmox.com> <8144f930-078c-4ea4-911e-5932d7f44083@proxmox.com> From: Philipp Hufnagl In-Reply-To: <8144f930-078c-4ea4-911e-5932d7f44083@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.004 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 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 manager] ui: improve vm/container migration user experience 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: Fri, 08 Sep 2023 10:52:40 -0000 On 9/6/23 11:18, Thomas Lamprecht wrote: > subject is quite confusing, this isn't for what's commonly understood > w.r.t. the "VM/CT migration", i.e., live migration to another host. > > You at least need to use the word "pool" somewhere.. > > Am 05/09/2023 um 15:51 schrieb Philipp Hufnagl: >> After the implementation of fix #474, it has been suggested that >> instead of requiring the user to click a checkbox allowing migration, >> it should be allowed automatically and and a warning should be displayed >> >> Further it has been discussed to rename the feature from "transfer" to >> "migrate". However and API change would break already implemented usage > Not sure if I'd call that a discussion, I stated: > >> We normally use "move" or "migrate", not "transfer", or "reassign" (like for >> moving a guest disk to another guest) and it has some merits to not expand the >> commonly used (parameter) naming scheme to much, but oh well it's already released >> and a naming nit that doesn't matters _that_ much. > And overlooked the "renaming to "migrate" or "migrate from other pool" part > in your reply (while at it, still missing the adding the API default). > > This was not intended to be a final instruction to definitively use "migrate" > here, but rather open the discussion for a possible better name, or even keep > that if there's consensus that "transfer" or "reassign" is fine. > >> and so it has been decided to call it (for now) transfer everywhere to >> avoid confusion > That again conflicts with your subject message and your statement that > you will rename it. Besides that, by whom has it been decided where? > This again sounds like there was some actual discussion, but I don't > see any. > > If you want to keep transfer for now, ok, but do so consistently (e.g., also > in the commit message's subject here then – but still with "pool" mentioned, > otherwise one cannot possible know what this is actually about..) I spoke with Dominik Csapak of list about this. "transfer" can not simply be removed from the API since it would break programs who would use it. Therefor we agreed, that renaming would just lead lead to a confusing mix of terms. I thought it would be better to call it "migration" in the patch but I will call it "transfer" there as well and also mention "pool"