| Age | Commit message (Collapse) | Author |
|---|
|
When creating a vlan zone and vnet, we get all the bridge interfaces
(slaves) and add them to the new vlan bridge. We get all the bridge
interfaces using `/sys/class/net` and then filter them using a regex.
This regex was missing the new `if` and `nic` prefixes which were
introduced with the pve-network-interface-pinning tool.
This is more of a stop-gap, we can probably remove the regex completely
as I don't see any reason to filter by "physical" interfaces here. If
there is a need, we can still run `ip link` and check the attributes
with `PVE::Network::ip_link_is_physical`.
Fixes: #6806
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
Link: https://lore.proxmox.com/20250915084801.48170-1-g.goller@proxmox.com
|
|
Ripgrepped over all my local repos and didn't find an invocation. The
last invocation was removed with:
938ebef7bd73 ("vlan/qinq: use bridge option instead uplink-id").
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
Link: https://lore.proxmox.com/20250915095154.78769-1-g.goller@proxmox.com
|
|
Instead of just printing a normal warning, use log_warn, which adds a
warning to the whole task. This means the whole task ends with a
"warning" status which is visible nicely in the task list. Previously we
just printed a warning, which made the task end with "OK" even if the
reload failed.
frr-reload.py only fails if it's not installed (where a warning status
is ok) or the configuration is not valid (where a warning status is also
ok). Having frr-reload.py uninstalled for some reason and always relying
on `systemctl restart frr` to reload the sdn config is kinda weird and
you probably deserve to get a warning on each sdn apply task.
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
Link: https://lore.proxmox.com/20250911153359.278834-1-g.goller@proxmox.com
|
|
The possible properties returned by the zone endpoints were only
partly documented. Add all missing properties and improve descriptions
for existing properties.
Extract all duplicate properties into a separate variable, so we
don't have to rewrite the whole API definition for every endpoint.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Reviewed-by: Dominik Csapak <d.csapak@proxmox.com>
Tested-by: Dominik Csapak <d.csapak@proxmox.com>
|
|
The possible properties returned by the vnet endpoints were only
partly documented. Add all missing properties and improve descriptions
for existing properties.
Extract all duplicate properties into a separate variable, so we
don't have to rewrite the whole API definition for every endpoint.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Reviewed-by: Dominik Csapak <d.csapak@proxmox.com>
Tested-by: Dominik Csapak <d.csapak@proxmox.com>
|
|
The possible properties returned by the controller endpoints were only
partly documented. Add all missing properties and update descriptions
for existing properties.
Update the descriptions of the schemas in the plugin to provide more
detailed information about the different configuration options.
Move all duplicate properties between the GET endpoints into its own
variable, so we can reuse them.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Reviewed-by: Dominik Csapak <d.csapak@proxmox.com>
Tested-by: Dominik Csapak <d.csapak@proxmox.com>
|
|
ASNs are 32-bit unsigned integers where the maximum value is
4294967295.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Reviewed-by: Dominik Csapak <d.csapak@proxmox.com>
Tested-by: Dominik Csapak <d.csapak@proxmox.com>
|
|
With the upgrade to PVE 9, those files should have been successfully
migrated on all nodes, so we do not need to fallback on the old files
anymore.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Link: https://lore.proxmox.com/20250801121029.201766-4-s.hanreich@proxmox.com
|
|
The parameter is optional, so all existing create/update/delete
invocations can work as before, only failing if the global lock is
currently set. This ensures backwards-compatibility with the existing
calls to the API in the frontend. If the lock is set, users will get
an error message when trying to modify the configuration from the web
UI.
Co-authored-by: Gabriel Goller <g.goller@proxmox.com>
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Link: https://lore.proxmox.com/20250729092933.90118-3-g.goller@proxmox.com
|
|
When frr isn't installed (happens e.g. on pve8 to 9 update) then the SDN
and Networking "Apply Configuration" task will throw an error because it
can't access the frr daemons file to check if the daemons are enabled.
In order to fix this, check if the frr config file exists before
continuing with the frr config generation.
Also make the "daemons file does not exist" error nicer.
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
Link: https://lore.proxmox.com/20250723154934.928349-1-g.goller@proxmox.com
[TL: switch to checking just for /etc/frr and perltidy]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
With the package bumped to 10.3.1 we need to generate the
configuration with the matching version, otherwise frr-reload.py fails
to create a delta of the configuration because of the version
mismatch. Reloading still works, but there is an ugly warning in the
reload log, that might throw off users.
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
Link: https://lore.proxmox.com/20250716130837.585796-56-g.goller@proxmox.com
|
|
Add a new property to the VXLAN zone, that can contain the name of a
fabric. This automatically generates the peer-list from the fabric,
instead of having to manually write a comma-separated IP list. This
changes the peer field to optional from required. Either the peers or
the fabric field needs to be set, and this is now validated in the
update hook of the VXLAN zone.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Link: https://lore.proxmox.com/20250716130837.585796-54-g.goller@proxmox.com
|
|
Provide a new option to the EVPN controller, fabric, that can be used
to define a fabric as the underlay network for the EVPN controller.
When applying the configuration, the EVPN controller then
automatically generates the peer list and from the fabric
configuration, rather than users having to specify all IP addresses
manually. This also means that the peer list automatically updates
when changing the fabric.
An EVPN controller can only either define a peer list or a fabric, but
not both. This requires the 'peers' property to now be optional, but
the existence of either fabric / peers is now validated in the
on_update_hook now instead.
MTU is set automatically to 1450 (because of VXLAN overhead) when
fabrics are used, unless otherwise specified in the EVPN zone
configuration, since there is currently now way of reliably accessing
the MTU of the interfaces of the fabric. This means users have to
manually specify the MTU for the EVPN controller when using fabrics.
This could be particularly relevant in the future, when Wireguard is
introduced as a fabric, which incurs an overhead of 80 bytes,
requiring users to manually set the MTU to 1370.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Link: https://lore.proxmox.com/20250716130837.585796-53-g.goller@proxmox.com
|
|
Provide a JSONSchema for the new two entity types, fabric and node.
While both are stored in the same configuration file, there are two
separate API submodules for fabrics and nodes, so we need to separate
the schema definitions as well.
The schemas are equivalent to the API types defined in Rust. In the
future it should be possible to generate the JSONSchema directly from
those types, but for now we have to duplicate the schema here.
Co-authored-by: Gabriel Goller <g.goller@proxmox.com>
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Link: https://lore.proxmox.com/20250716130837.585796-48-g.goller@proxmox.com
|
|
Currently, the ifupdown config generation is handled solely by the
zones plugin. Since the fabrics need to generate ifupdown
configuration as well, we create a new helper in the SDN module. It
then in turn calls into the zone and fabrics plugin, and merges the
generated raw configuration before writing it to the
/etc/network/interfaces.d/sdn file.
Co-authored-by: Gabriel Goller <g.goller@proxmox.com>
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Link: https://lore.proxmox.com/20250716130837.585796-47-g.goller@proxmox.com
|
|
Add functions that allow reading and manipulating values in the
/etc/frr/daemons file. We need this for en/disabling daemons depending
on which fabric types are configured. We enable daemons dynamically,
depending on the currently configured fabrics. If a daemon is enabled
but all fabrics using it get deleted, we disable them as well.
The helper works by iterating over the lines of the daemons file from
FRR, parsing the key and checking if the key is managed by the SDN
configuration, then sets it. As a safeguard, keys that can be changed
by SDN have to be explicitly configured in the respective hash of the
Frr module.
Co-authored-by: Gabriel Goller <g.goller@proxmox.com>
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Link: https://lore.proxmox.com/20250716130837.585796-45-g.goller@proxmox.com
|
|
Adds a new method to the SDN module that is responsible for generating
and writing the FRR configuration for all SDN plugins combined. It
utilizes the newly introduced FRR helper as well as the newly
introduced API for the controllers to generate an frr_config instead
of generating the configuration in the controller directly. It can
also reload the FRR daemon.
Change the tests to use this new API as well, so they use the new
methods for generating the frr configuration. They previously used a
different code-path for generating the FRR config compared to the
actual worker task, so this also ensures that tests validate the
configuration that *actually* gets generated.
Co-authored-by: Gabriel Goller <g.goller@proxmox.com>
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Link: https://lore.proxmox.com/20250716130837.585796-42-g.goller@proxmox.com
|
|
With the changes to how we handle the frr config generation,
controllers are now no longer responsible for serializing and writing
the FRR configuration. Instead, we pass the existing frr_config perl
hash to every controller, where controllers append their respective
configuration.
This requires a few changes in the controller API, so that they now
append to a perl hash, instead of directly writing their own
configuration to the file, which is now handled externally by the SDN
module.
We also remove the respective methods in the EvpnPlugin that were
previously responsible for serializing and writing the FRR
configuration, since they have been moved to the Frr helper module
instead.
Co-authored-by: Gabriel Goller <g.goller@proxmox.com>
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Link: https://lore.proxmox.com/20250716130837.585796-41-g.goller@proxmox.com
|
|
The reload and restart parts of the original reload_controller_config
have been split into two functions, in order to make error handling
in the new apply function easier.
The new apply function tries to reload via frr-reload.py and if that
fails, it falls back to restarting the frr service.
Since frr-reload.py does *not* start / stop daemons that have been
added / remove to /etc/frr/daemons, we add a new parameter that can be
used to restart the frr service instead of just using frr-reload.py.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Link: https://lore.proxmox.com/20250716130837.585796-40-g.goller@proxmox.com
|
|
Up until now the EVPN controller contained all the helper methods as
well as the configuration generation logic for FRR. Since we need to
write FRR configuration with the fabrics as well, move the FRR helper
files into its own FRR module, so they can be used by the EVPN plugin
as well as the future fabrics plugins.
The fact that the EVPN controller was solely responsible for
generating the FRR config also meant, that FRR configuration was only
generated if you had an EVPN controller defined.
In the process of generating an FRR configuration, we used mainly two
formats, which I'll refer to by the following names:
frr_config: This is a perl hash, that loosely resembles the structure
of the FRR configuration file and was later converted into the
raw_config format before writing it.
raw_config: This is an array, that contains strings, where each string
is a line in the FRR configuration. So the finished FRR configuration
consists of all the strings in the array joined by newlines.
Controllers used the frr_config format for generating FRR
configuration. The local configuration in /etc/frr/frr.conf.local also
gets parsed into this format. The fabrics perlmod module, returns the
raw_config format. This was behind the intention to make this split
more clear and handle the FRR config generation in two steps from now
on:
* generate a frr_config in all plugins that utilize that format
* convert it to the raw_config format
* append the configuration obtained via perlmod
* write the finished configuration to frr.conf
This process was already in place, but the distinction wasn't that
clear. During this process I renamed all methods to make clear which
format they accept / return.
Some functions have been split to make them more granular, so we can
use intermediate results. Most namely the
generate_controller_rawconfig function has been split into multiple
functions.
Added documentation to all public FRR functions, so it is clearer
which format they expect, as well as which operations they perform on
the respective passed configurations.
For the future it might make sense to further split the FRR config
generation for zones and vnets into the respective Zone / VNet
Plugins, instead of in the EVPN controller, but this was beyond the
scope of this already quite large patch series.
Co-authored-by: Gabriel Goller <g.goller@proxmox.com>
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Link: https://lore.proxmox.com/20250716130837.585796-39-g.goller@proxmox.com
|
|
Add a new basic Fabrics module that can be used for reading and
writing the fabrics configuration file.
Co-authored-by: Gabriel Goller <g.goller@proxmox.com>
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Link: https://lore.proxmox.com/20250716130837.585796-38-g.goller@proxmox.com
|
|
Since this only has an effect on applying the configuration, users
will still need to reapply the configuration when an interface changes
names / altnames. In order to add full altname support for IS-IS,
altname support would need to be implemented in FRR.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Link: https://lore.proxmox.com/20250716151815.348161-7-s.hanreich@proxmox.com
|
|
Signed-off-by: Hannes Duerr <h.duerr@proxmox.com>
Link: https://lore.proxmox.com/20250711095206.30852-2-h.duerr@proxmox.com
|
|
At the moment it is possible to query the Dhcp plugin types from the
`use PVE::Network::SDN::Dhcp::Plugin` without importing
`PVE::Network::SDN::Dhcp`. In consequence the section config is not
created although one would have been expected it to be created.
Importing `use pve::network::sdn::Dhcp` would solve the issue, but since
this is not a nice pattern and in order to avoid such problems in the
future, we are now making it possible to query the plugin type from
DHCP. If you then import DHCP, the section config will be built
correctly.
The problem was noticed/introduced after the ordering of the two imports
`use PVE::Network::SDN::Vnets` and `use PVE::Network::SDN::Vnets` were
swapped in pve-bridge [0], resulting in the error:
file /etc/pve/sdn/zones.cfg line 2 (section 'simple') - unable to parse value of 'dhcp': value 'dnsmasq' does not have a value in the enumeration ''
The Zones Section Config no longer returned correct values for dhcp
because the Section Config was not yet built correctly at that time.
Swapping the entries back also solves the issue, because Vnets.pm is
importing `PVE::Network::SDN::Dhcp`, but that is also not really a nice
solution
[0] https://lore.proxmox.com/pve-devel/20250625155751.268047-6-f.ebner@proxmox.com/
Signed-off-by: Hannes Duerr <h.duerr@proxmox.com>
Tested-by: Friedrich Weber <f.weber@proxmox.com>
Link: https://lore.proxmox.com/20250711095206.30852-1-h.duerr@proxmox.com
|
|
The is_ovs helper has been moved to pve-common. Update all call sites
to use the new helper in pve-common to determine whether something is
a linux or OVS bridge.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Reviewed-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
FG: add version bumps
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
|
|
might be better to die, but having a warning making it to the task or
system log is way better than the status quo, where one just gets a
complaint from perl due to using an undef value as hash key.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
Some where unused but some just plain bogus, like importing oneself or
importing methods that are not exported.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
As returning the result from sort directly is undefined if called in a
scalar context. Reported by perlcritic.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
CIDR is always a defined hash anyway.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
that's always a bug in perl as the variable will keep the value from
when the condition evaluated to true the last time.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
using the new top-level `make tidy` target, which calls perltidy via
our wrapper to enforce the desired style as closely as possible.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
Since we now ship frr with Proxmox VE, the frr service is available on
the nodes but disabled on install. Prior to that, users had to
manually install frr, which automatically enabled the service. When
first applying a SDN configuration with an EVPN controller, we always
fell back to restarting the frr service, because reloading fails when
the daemon isn't running. This fallback to restarting leads to the
service running but still being in the disabled state. This means that
the EVPN setup is working until the next reboot. To avoid the
situation where users configure an EVPN controller and everything
seems to be working, until a restart breaks the EVPN setup,
additionally enable and start the frr service before trying to reload
the configuration.
We enable the service after checking for the existence of
frr-pythontools in order to avoid the situation where users apply an
SDN configuration with an EVPN controller, but reloading fails due to
a missing frr-pythontools package. Since we do an early return there,
we never fell back to restarting the service in case frr-pythontools
was not available. If we enabled the service before the check, the
configuration would apply after a reboot since it already got written
to the frr configuration file.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
|
|
Prior to the upgrade to frr-pythontools 10.2.1, frr-reload.py did not
print any output to STDOUT, which masked the erroneous outfunc
provided in run_command. With 10.2.1 frr-reload.py now prints to
STDOUT, which triggers the codepath for invoking the outfunc, leading
to an error when invoking frr-reload.py. By removing the outfunc the
invocation works again.
In addition to fixing the regression introduced, we also now print the
frr-reload.py informational output to the tasklog, which can be
helpful in debugging any issues when reloading the frr configuration.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
|
|
The hostname provided to the methods in the IPAM plugins is empty for
VMs that do not have a name set. We always included the dns_name key
in the request, even if it was undefined, which leads Netbox to return
a 400 Bad Request error. With this patch we omit the dns_name
parameter if it isn't set, so the call succeeds.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Link: https://lore.proxmox.com/20250408132517.225240-1-s.hanreich@proxmox.com
|
|
Check for overlapping DHCP ranges and reject them if there are any
overlaps. If we can be certain that there are no overlapping DHCP
ranges this saves us from running into errors later in IPAM modules
where overlapping DHCP ranges are not allowed.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Hannes Duerr <h.duerr@proxmox.com>
Link: https://lore.proxmox.com/20250307125056.169575-4-s.hanreich@proxmox.com
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
Net::IP accepts a myriad of different IP objects from ranges to
prefixes to singular IPs. We check if the object consists only of a
singular IP and normalize the IP if it has size 1 (since then it
could still be a /32 prefix or a range consisting of one IP).
Otherwise we would theoretically accept any valid Net::IP object here.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Hannes Duerr <h.duerr@proxmox.com>
Link: https://lore.proxmox.com/20250307125056.169575-3-s.hanreich@proxmox.com
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Hannes Duerr <h.duerr@proxmox.com>
Link: https://lore.proxmox.com/20250307125056.169575-2-s.hanreich@proxmox.com
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
This simplifies the comparison of IPs by using the object-oriented
interface over the procedural one. Also instantiate the ips using the
new method rather than using new, which isn't a keyword in Perl. This
fixes the respective perlcritic warning.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Hannes Duerr <h.duerr@proxmox.com>
Link: https://lore.proxmox.com/20250307125056.169575-1-s.hanreich@proxmox.com
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
Signed-off-by: lou lecrivain <lou.lecrivain@wdz.de>
Tested-by: Stefan Hanreich <s.hanreich@proxmox.com>
Reviewed-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Hannes Duerr <h.duerr@proxmox.com>
Link: https://lore.proxmox.com/mailman.187.1734119229.332.pve-devel@lists.proxmox.com
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
(configure_range is now noop)
Signed-off-by: lou lecrivain <lou.lecrivain@wdz.de>
Tested-by: Stefan Hanreich <s.hanreich@proxmox.com>
Reviewed-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Hannes Duerr <h.duerr@proxmox.com>
Link: https://lore.proxmox.com/mailman.183.1734119197.332.pve-devel@lists.proxmox.com
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
instead
Signed-off-by: lou lecrivain <lou.lecrivain@wdz.de>
Tested-by: Stefan Hanreich <s.hanreich@proxmox.com>
Reviewed-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Hannes Duerr <h.duerr@proxmox.com>
Link: https://lore.proxmox.com/mailman.181.1734119196.332.pve-devel@lists.proxmox.com
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
Because of how the Netbox IPAM plugin works (utilizing IP ranges to
represent DHCP ranges), we need a hook in the IPAM plugin that runs on
updates to the subnet because DHCP ranges can be edited. The update
hook in Netbox checks which DHCP ranges got added and which got
deleted and then performs the respective changes in the Netbox IPAM.
This operates under the assumption that DHCP ranges do not overlap
(which is not supported by Netbox anyway).
Only Netbox needs to do work on update, so we can leave this as noop
in phpIPAM and the PVE IPAM, because they have no notion of IP ranges
or similar entities. phpIPAM doesn't support DHCP ranges at all and
PVE IPAM simply uses DHCP ranges as a constraint when allocating an
IP.
I decided on this approach over just creating IP ranges on demand when
assigning IPs, because this keeps Netbox clean and in sync with the
PVE state. It doesn't leave remnants of IP ranges in the Netbox
database, which can lead to errors when trying to create IP ranges
that overlap with IP ranges that already existed in an SDN subnet.
This method tries to check for any possible errors before editing the
entities. There is still a small window where external changes can
occur that lead to errors. We are touching multiple entities here, so
in case of errors users have to fix their Netbox instance manually.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Hannes Duerr <h.duerr@proxmox.com>
Link: https://lore.proxmox.com/20250310085103.30549-8-s.hanreich@proxmox.com
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
We use the IP ranges of netbox to represent the dhcp ranges. We were
already querying the IP ranges for a IP when starting a guest, but we
never created the IP ranges in the first place. Additionally implement
deleting the IP ranges when the subnet gets deleted.
These methods try to check for any possible errors before editing the
entities. There is still a small window where external changes can
occur that lead to errors. We are touching multiple entities here, so
in case of errors users have to fix their Netbox instance manually.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Hannes Duerr <h.duerr@proxmox.com>
Link: https://lore.proxmox.com/20250310085103.30549-7-s.hanreich@proxmox.com
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
The netbox integration did not properly return the IP when creating
the entries in netbox. This lead to errors on starting the guest,
stating that an IP could not be allocated.
Originally-by: lou lecrivain <lou.lecrivain@wdz.de>
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Hannes Duerr <h.duerr@proxmox.com>
Link: https://lore.proxmox.com/20250310085103.30549-6-s.hanreich@proxmox.com
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
This function did not catch any possible errors, nor respect the
$noerr parameter.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Hannes Duerr <h.duerr@proxmox.com>
Link: https://lore.proxmox.com/20250310085103.30549-5-s.hanreich@proxmox.com
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
While it should make practically no difference, it opens up potential
errors in the future, so just remove the conditional assignments and
explicitly define the variable as undef, so the intention is more
clear.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Hannes Duerr <h.duerr@proxmox.com>
Link: https://lore.proxmox.com/20250310085103.30549-4-s.hanreich@proxmox.com
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
The helpers had lots of unnecessary intermediate assignments, which we
can just simplify.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Hannes Duerr <h.duerr@proxmox.com>
Link: https://lore.proxmox.com/20250310085103.30549-3-s.hanreich@proxmox.com
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
Deleting a subnet did not delete any created entities in Netbox.
Implement deletion of a subnet by deleting all entities that are
created in Netbox upon creation of a subnet.
We are checking for any leftover IP assignments before deleting the
prefix, so we do not accidentally delete any manually created IP
assignments.
This method tries to check for any possible errors before editing the
entities. There is still a small window where external changes can
occur that lead to errors. We are touching multiple entities here, so
in case of errors users have to fix their Netbox instance manually.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Hannes Duerr <h.duerr@proxmox.com>
Link: https://lore.proxmox.com/20250310085103.30549-2-s.hanreich@proxmox.com
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
Create a helper method that abstracts the common code used in making
netbox requests. Move all api_request incovations over to using the
helper method. This saves us from writing lots of repeated code.
This also updates the helpers and introduces error checking there.
Helpers didn't catch any errors and the invoking methods didn't as
well. This meant that functions with $noerr set to 1 would still error
out. We now pass $noerr to the helper functions and they behave the
same as the parent methods. This requires some additional checks in
the call sites of the helpers.
Also canonicalize all URLs, since Netbox does that and it saves us a
redirect.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Hannes Duerr <h.duerr@proxmox.com>
Link: https://lore.proxmox.com/20250310085103.30549-1-s.hanreich@proxmox.com
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
This fixes an issue with dual stacking, when using a zone with both a
IPv4 and IPv6 subnet and the same DNS suffix, pve-network will try to
set both DNS records (type A and AAAA) in the same powerdns rrset,
causing an API error, and effectively causing no forward DNS records
being created.
This change edits the `get_zone_rrset` function so that it takes the
DNS record type into account.
Signed-off-by: Matthieu Pignolet <m@mpgn.dev>
Tested-by: Stefan Hanreich <s.hanreich@proxmox.com>
[TL: wrap commit message]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
