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 A7B191FF16E
for <inbox@lore.proxmox.com>; Mon, 28 Apr 2025 16:34:22 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id A98D034453;
Mon, 28 Apr 2025 16:34:31 +0200 (CEST)
Message-ID: <e95e915b-3153-428f-9d8c-64e60d0c9689@proxmox.com>
Date: Mon, 28 Apr 2025 16:33:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Fiona Ebner <f.ebner@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Daniel Kral <d.kral@proxmox.com>
References: <20250325151254.193177-1-d.kral@proxmox.com>
<20250325151254.193177-11-d.kral@proxmox.com>
<67d201c9-64ca-4392-b166-aa14cb2bae48@proxmox.com>
Content-Language: en-US
In-Reply-To: <67d201c9-64ca-4392-b166-aa14cb2bae48@proxmox.com>
X-SPAM-LEVEL: Spam detection results: 0
AWL -0.036 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 09/15] manager: apply colocation
rules when selecting service nodes
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: pve-devel-bounces@lists.proxmox.com
Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com>
Am 28.04.25 um 14:26 schrieb Fiona Ebner:
> Am 25.03.25 um 16:12 schrieb Daniel Kral:
>> +
>> + delete $allowed_nodes->{$node};
>> + }
>> + } elsif (scalar keys %$possible_nodes) {
>> + # limit to the possible nodes the service should be on, if there are any.
>> + for my $node (keys %$allowed_nodes) {
>> + next if exists($possible_nodes->{$node});
>> +
>> + delete $allowed_nodes->{$node};
>
> This seems wrong. Non-strict rules should not limit the allowed nodes.
> See below for more on this.
Ah, if there are no possible nodes at all, then the allowed nodes are
not modified at all. This is what makes the loose tests work. This
"secret" here really needs to be properly documented ;)
It still would be nice to think about which kind of interaction with
scoring we want exactly. Currently it's the number 1 I mentioned, i.e.
"prefer loose colocation over scoring no matter what". Can be fine to
start out too, just means we'd need to introduce an option/tunable if we
ever want to change it.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel