From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <pve-devel-bounces@lists.proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id DB4891FF16F for <inbox@lore.proxmox.com>; Tue, 24 Jun 2025 10:06:05 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 2521830825; Tue, 24 Jun 2025 10:06:35 +0200 (CEST) Message-ID: <e050a1a2-6ba8-4cbf-86d0-893e2270dfc1@proxmox.com> Date: Tue, 24 Jun 2025 10:06:00 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Thomas Lamprecht <t.lamprecht@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com> References: <20250620143148.218469-1-d.kral@proxmox.com> <20250620143148.218469-7-d.kral@proxmox.com> <94274dfd-3b10-476d-ad7c-d56bc461303c@proxmox.com> Content-Language: en-US From: Daniel Kral <d.kral@proxmox.com> In-Reply-To: <94274dfd-3b10-476d-ad7c-d56bc461303c@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.012 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 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. 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 ha-manager v2 02/26] manager: improve signature of select_service_node 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> Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com> On 6/23/25 18:21, Thomas Lamprecht wrote: > Am 20.06.25 um 16:31 schrieb Daniel Kral: >> +=head3 select_service_node(...) >> + >> +=head3 select_service_node($groups, $online_node_usage, $sid, $service_conf, $sd, $mode) >> + >> +Used to select the best fitting node for the service C<$sid>, with the >> +configuration C<$service_conf> and state C<$sd>, according to the groups defined >> +in C<$groups>, available node utilization in C<$online_node_usage>, and the >> +given C<$mode>. >> + >> +The C<$mode> can be set to: >> + >> +=over >> + >> +=item C<'none'> >> + >> +Try to stay on the current node as much as possible. > > Why use "none" then? "no mode" is not really helping understand > what happens. Maybe it can be resolved with better names/descriptions, > even for the parameter name (like maybe "node_preference"?), but another > option might be to combine the flags into a hash ref $opts parameter, as > that would also avoid the issues of rather opaque "1" or "0" params on > the call sites, not saying it's a must, but we use that pattern a few > times and conflating such flags into a single string param comes with > its own can of worms (bit more about that below). I thought about putting them in an $opts, but I felt like a enum-like type would fit here better to reduce the amount of states slightly as setting $try_next more or less already implied $best_scored (not the other way around). $mode = 'none' is really no good information here, I think $node_preference will be a better name for it here. > >> + >> +=item C<'best-score'> >> + >> +Try to select the best-scored node. >> + >> +=item C<'try-next'> > > Not sure if switching to a free form string that is nowhere checked for > unknown (invalid) values really is an improvement over the status quo. > Rejecting unknown modes upfront should be definitively added. > > Also can we please move the item description as short sentence after the > `=item ...`, i.e., on the same line, to reduce bloating up the code too > much with POD. > > =item C<'none'>: Try to stay on the current node as much as possible. > =item C<'best-score'>: Try to select the best-scored node. > =item C<'try-next'>: ...? Will definitely do that! Speaking of 'try-next' (more below), shouldn't $sd->{failed_nodes}->@* be cleaned as soon as the service was successfully started on a node? I feel like $try_next was introduced to separate it from the 'stay on current node as much ass possible' behavior and might not be needed anymore now with an explicit $node_preference = 'none'? Then we're only left with $node_preference = 'none' / 'best-score' (where the latter is the standard behavior of the helper. > > >> + >> +Try to select the best-scored node, which is not in C<< $sd->{failed_nodes} >>, >> +while trying to stay on the current node. > > might be a bit to long since I did more in the HA stack, but is "while trying > to stay on the current node" correct? Right, I misread the last part at select_service_node(...) my $found; for (my $i = scalar(@nodes) - 1; $i >= 0; $i--) { my $node = $nodes[$i]; if ($node eq $current_node) { $found = $i; } } if ($mode eq 'try-next') { if (defined($found) && ($found < (scalar(@nodes) - 1))) { return $nodes[$found + 1]; } else { return $nodes[0]; } } else { return $nodes[0]; } for preferring the $current_node there but it actually is the next-best node after $current_node after sorting the nodes by the Usage's scores. If 'try-next' is set, shouldn't $current_node already have been deleted from $pri_nodes/@nodes here by if ($mode eq 'try-next') { foreach my $node (@$tried_nodes) { delete $pri_nodes->{$node}; } } Either way, the last part of the description is wrong and I'll remove it. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel