[pve-devel] (no subject)

[pve-devel] (no subject)

[Daniel Krambrock via pve-devel]

[-- Attachment #1: Type: message/rfc822, Size: 4492 bytes --]

From: Daniel Krambrock <krambrock@hrz.uni-marburg.de>
To: pve-devel@lists.proxmox.com
Subject: 
Date: Wed, 22 May 2024 14:05:49 +0200
Message-ID: <20240522120553.49114-1-krambrock@hrz.uni-marburg.de>

This series of patches let the user choose a VMID suggestion strategy 
to avoid the recycled VMID problem.

Default is 'next-free', the previous strategy where the suggested VMID
is the lowest not used ID in range. This reuses VMIDs.
Added options are:
- 'max-1': selects the highest existing VMID and adds 1
- 'list': returns the lowest free VMID within the specified
  range that is not on a list of previously used VMIDs
On guest deletion the VMID is added to '/etc/pve/used_vmids.list'





[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] (no subject)

[Shannon Sterz]

On Wed May 22, 2024 at 2:05 PM CEST, Daniel Krambrock wrote:
> This series of patches let the user choose a VMID suggestion strategy
> to avoid the recycled VMID problem.

Hi Daniel!

Thanks for your contribution! First of some top-level feedback:

- Please familiarize yourself with the Developer Documentation [1], Perl
  [2], and JavaScript [3] style guides before contributing.
- Most importantly, if you haven't already, please contact
  `office@proxmox.com` about signing the Harmony CLA [4].
- All your patches provide the same git short message. Please provide
  more specific context for each patch and not just the the overall goal
  of your series.

> Default is 'next-free', the previous strategy where the suggested VMID
> is the lowest not used ID in range. This reuses VMIDs.
> Added options are:
> - 'max-1': selects the highest existing VMID and adds 1

I'm guessing you typo-ed the `max-1` here, as the other patches seem to
correctly use `max+1`. Please note that such a strategy is still prone
to re-use of IDs if one where to remove the VM with the highest ID.

> - 'list': returns the lowest free VMID within the specified
>   range that is not on a list of previously used VMIDs
> On guest deletion the VMID is added to '/etc/pve/used_vmids.list'

Not sure if tracking the used VM/CT IDs in a separate file is the most
elegant solution here. Especially as this is a somewhat niche usecase.

Anyway, I'll provide some more detailed feedback in-line.

Kind regards, Shannon

PS: Please use "reply-all" when replying to me, so the full discussion
stays on the mailing list. Thanks!




_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] (no subject)

[Stefan Hanreich]

On 12/9/24 12:31, Lou Lecrivain wrote:
> (configure_range is now noop)
> 
> Signed-off-by: lou lecrivain <lou.lecrivain@wdz.de>
> ---
>  src/PVE/Network/SDN/Dhcp.pm         |  3 ++-
>  src/PVE/Network/SDN/Dhcp/Dnsmasq.pm | 23 ++++++++++-------------
>  2 files changed, 12 insertions(+), 14 deletions(-)
> 
> diff --git a/src/PVE/Network/SDN/Dhcp.pm b/src/PVE/Network/SDN/Dhcp.pm
> index d48de34..3ee18e0 100644
> --- a/src/PVE/Network/SDN/Dhcp.pm
> +++ b/src/PVE/Network/SDN/Dhcp.pm
> @@ -98,11 +98,12 @@ sub regenerate_config {
>  		my $subnet_config = $subnets->{$subnet_id};
>  		my $dhcp_ranges = PVE::Network::SDN::Subnets::get_dhcp_ranges($subnet_config);
>  
> +		next if !$dhcp_ranges;
>  		my ($zone, $subnet_network, $subnet_mask) = split(/-/, $subnet_id);
>  		next if $zone ne $zoneid;
> -		next if !$dhcp_ranges;

I think this check could actually be skipped altogether. Since
$dhcp_ranges is a reference it will always be truthy. We only use this
for iterating over @$dhcp_ranges anyway - so if it's empty it is a skip
anyway..

This is pre-existing though and could be massaged in on committing I
suppose, so not necessarily a reason for a v3.

@Thomas: if you want to I can just submit a separate patch for this as
well but this doesn't affect the functionality of this patch series in
any form.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel