From: Daniel Herzig <d.herzig@proxmox.com>
To: Stefan Hanreich <s.hanreich@proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH network 2/4] fix #5900: add helper functions
Date: Mon, 16 Dec 2024 09:35:38 +0100 [thread overview]
Message-ID: <87zfkwf2jp.fsf@proxmox.com> (raw)
In-Reply-To: <c345661d-a4ac-4ce9-a03a-d5b14992c29c@proxmox.com> (Stefan Hanreich's message of "Thu, 12 Dec 2024 18:06:56 +0100")
Hey Stefan,
thanks for the feedback!
Stefan Hanreich <s.hanreich@proxmox.com> writes:
>
> If we do it this way (see top-level discussion), I think we should
> abstract this into the IpamPlugins itself, since this implementation is
> specific to the PVE Plugin, but that's just one type of IPAM plugin.
> Something like:
>
> Add a abstract method in the base Ipam plugin
> (Network/SDN/Ipams/Plugin.pm), i.e.
>
> PVE::Network::SDN::Ipams::Plugin::vnet_has_free_ip($range, $ipversions)
>
> Then implement it for every IPAM Plugin separately.
>
> Add a helper method to the VNet that selects the correct plugin based on
> the zone setting and then iterates over all its subnets to check for
> free IPs - something like:
>
> PVE::Network::SDN::Vnets::has_free_ip($range, $ipversions)
>
I like this thought a lot, sounds like a much cleaner and modular
solution.
>
>
> The current implementation only works for the PVE plugin and would
> actually break on zones using Netbox / Phpipam (if my brain compiler is
> correct).
>
>
Thanks for the hint -- I need to do some research on that! The code
assumes the ~key: value~ of ~dhcp: dnsmasq~ to be exclusive for IPAM
PVE.
```
for my $zone (@$zone_ids) {
push(@$dhcp_dnsmasq_zones, $zone)
if (defined(${zones_cfg}->{'ids'}->{$zone}->{'dhcp'}) &&
(${zones_cfg}->{'ids'}->{$zone}->{'dhcp'} eq 'dnsmasq'))
}
```
If this is not the case, it will affect (and not ignore as intended)
zones with Netbox/Phpipam indeed. That would be bad.
A check for ~ipam: pve~ could however be easily implemented in the same section.
>>
>> +sub defined_dhcp_ip_count_in_zone {
>> + my $zone_id = shift;
>
> even with 1 argument I think we prefer `my ($arg) = @_;`, but I haven't
> actually found a definitive answer in our style guide.
Thanks, not having any feelings here.
>
>> + my $vnets_in_zone = PVE::Network::SDN::Zones::get_vnets($zone_id);
>> + my $range_count_array;
>> + my $res;
>> + for my $vnet_id (keys %$vnets_in_zone) {
>> + my $subnets_in_vnet = PVE::Network::SDN::Vnets::get_subnets($vnet_id);
>> + for my $subnet (keys %$subnets_in_vnet) {
>> + my $dhcp_ranges = PVE::Network::SDN::Subnets::get_dhcp_ranges(${subnets_in_vnet}->{$subnet});
>> + if (scalar @$dhcp_ranges) {
>> + for my $dhcp_range (@$dhcp_ranges) {
>
> You can just iterate over @$dhcp_ranges, get_dhcp_ranges() always
> returns an array reference. If it is empty, then there are just 0
> iterations of the loop, no need to check for existence.
>
Right, this is too timid indeed :)
>> +
>> +sub available_dhcp_ips_in_zone {
>> + my $zone_id = shift;
>> + my $available_ip_count = defined_dhcp_ip_count_in_zone($zone_id);
>> + my $used_ip_count = used_dhcp_ips_in_zone($zone_id);
>> + if (!defined($available_ip_count)) {
>> + $available_ip_count = 0;
>> + }
>> + if (!defined($used_ip_count)) {
>> + $used_ip_count = 0;
>> + }
>
> If you define $res to be 0 as suggested above, then those checks become
> unnecessary, since 0 becomes the default value.
>
Very cool, thank you, I did not see that.
>> + my $vnet_ids = [ PVE::Network::SDN::Vnets::sdn_vnets_ids($vnets_cfg) ];
>
> no need for selecting the ids, you can directly iterate over the VNets:
>
Thank you for your insights and the hints very much. I cannot claim that I'm exactly happy about
the current implementation of this patch from an aesthetical point of
view by now! I will act on it further, if we consider the
'ask-for-permission' approach in general.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2024-12-16 8:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-05 16:33 [pve-devel] [PATCH guest-common, network, container, qemu-server 0/4] fix #5900: enhance SDN auto-dhcp behaviour Daniel Herzig
2024-12-05 16:33 ` [pve-devel] [PATCH guest-common 1/4] fix #5900: add helper function Daniel Herzig
2024-12-12 17:12 ` Stefan Hanreich
2024-12-16 8:38 ` Daniel Herzig
2024-12-05 16:33 ` [pve-devel] [PATCH network 2/4] fix #5900: add helper functions Daniel Herzig
2024-12-12 17:06 ` Stefan Hanreich
2024-12-16 8:35 ` Daniel Herzig [this message]
2024-12-05 16:33 ` [pve-devel] [PATCH container 3/4] fix #5900: do not create container if dhcp range is exhausted Daniel Herzig
2024-12-05 16:33 ` [pve-devel] [PATCH qemu-server 4/4] fix #5900: do not create vm " Daniel Herzig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zfkwf2jp.fsf@proxmox.com \
--to=d.herzig@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=s.hanreich@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.