| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
lock_sdn_config can return a boolean value, which will then in turn
get returned as data from the API calls. Since we hint type null here,
this leads to problems with the pve-api-client in rust. Fix the return
value for this API call by adding an explicit return statement.
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>
|
|
This makes it possible to check for the definedness of the parameter
and adapt the behavior of the reloading endpoint depending on that
information. See the commit in pve-manager for more information.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Hannes Duerr <h.duerr@proxmox.com>
Tested-by: Gabriel Goller <g.goller@proxmox.com>
Reviewed-by: Gabriel Goller <g.goller@proxmox.com>
Link: https://lore.proxmox.com/20250805083504.55378-3-s.hanreich@proxmox.com
|
|
Parameter has moved from skip_frr to regenerate-frr in pve-manager.
Also invert the check for generating the boolean, since the logic is
inverted now.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Link: https://lore.proxmox.com/20250804140152.423614-3-s.hanreich@proxmox.com
|
|
This is a breaking API change intended for PVE 9.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Link: https://lore.proxmox.com/20250801114455.85603-1-f.ebner@proxmox.com
|
|
This adds the functionality of rolling back the pending configuration
to the currently running configuration, resetting all changes made
since last applying the SDN configuration. This is mainly thought as
an escape hatch for failed PDM transactions.
You can invoke the endpoint via CLI:
pvesh create /cluster/sdn/rollback [--lock-token X [--release-lock]]
If a lock is currently held on the configuration and you want to
forcibly rollback, you need to release the lock first via the
lock_release API endpoint.
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-6-g.goller@proxmox.com
|
|
This endpoint exposes the newly introduced global lock functionality
via the API. It adds endpoints for acquiring and releasing the lock.
Acquiring the lock is as simple as:
pvesh create /cluster/sdn/lock
The flag 'allow-pending' governs whether the lock should be acquired
if there are pending configuration changes.
The release endpoint can also be used to forcibly release the lock via
CLI without requiring the knowledge of the lock-token:
pvesh delete /cluster/sdn/lock --force 1
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-5-g.goller@proxmox.com
|
|
Committing the configuration now requires a lock on the SDN
configuration, which was not required before. This is to prevent
concurrent callers from applying the SDN configuration, while the lock
is held. If there is no lock set, then this function behaves the same
as before.
Also add the functionality to automatically release the lock after
applying the configuration, for convenience reasons.
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-4-g.goller@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
|
|
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
|
|
Provides CRUD functionality for editing nodes inside a fabric, as well
as an endpoint for listing all the nodes. The URL structure is modeled
after the fact that a node can only be uniquely identified by its ID
as well as the ID of the fabric that contains the node.
Since fabrics can be used to edit the network configuration, we
require addtional Sys.Modify permissions on the node itself, since
that is the permission that is currently required by other endpoints
that allow modifiying the network configuration.
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-52-g.goller@proxmox.com
|
|
The GET endpoint lists all nodes from all fabrics - for listing the
nodes of a specific fabric or editing nodes another submodule will be
introduced below the node submodule in a future commit.
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-51-g.goller@proxmox.com
|
|
This API module provides CRUD functionality for fabrics. The list
endpoint works analogous to the existing SDN endpoints with their
pending / running parameters.
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-50-g.goller@proxmox.com
|
|
There is one endpoint (/all) at the top-level that fetches both types
of fabric entities (fabrics & nodes) and lists them separately. This
is used for the main view, in order to avoid having to do two API
calls. It works analogous to the existing root-level SDN API calls
with the running / pending parameters.
Also, since the interfaces key is used in the node sections, we need
to add it to the function encoding the values so they are compared and
returned from the API properly, when the pending parameter is set.
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-49-g.goller@proxmox.com
|
|
With the old FRR config generation logic, we never wrote an empty FRR
configuration if all controllers got deleted. This meant that deleting
all controllers still left the previous FRR configuration on the
nodes, never disabling BGP / IS-IS. The new logic now writes an empty
configuration if there is no controller / fabric configured, fixing
this behavior. This has a side effect for users with an existing FRR
configuration not managed by SDN, but utilizing other SDN features
(zones, vnets, ...). Their manual FRR configuration would get
overwritten when applying any SDN configuration. This is particularly
an issue with full-mesh Ceph setups, that were set up according to our
Wiki guide [1]. User with such a full-mesh setup could get their FRR
configuration overwritten when using unrelated SDN features.
Since we call the API endpoint in pve-manager for generating and
writing configuration files, we cannot directly prevent the FRR
configuration from being written in the SDN API call. Instead a new
parameter, skip_frr, has been added to the endpoint in pve-manager,
that skips writing the FRR configuration. We skip writing the FRR
configuration if neither the previous SDN configuration, nor the new
SDN configuration contains an entity that requires writing FRR
configuration. This should minimize the impact of the change to the
FRR config generation on existing FRR setups.
[1] https://pve.proxmox.com/mediawiki/index.php?title=Full_Mesh_Network_for_Ceph_Server&oldid=12146
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Link: https://lore.proxmox.com/20250716130837.585796-43-g.goller@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>
|
|
Previously, we iterated over the entire hash (keys and values), which
added unnecessary data to the configuration. This commit changes the
loop to iterate only over the hash keys.
Nothing should change as the garbled properties were removed down the
line anyway.
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
Link: https://lore.proxmox.com/20250520150101.283640-1-g.goller@proxmox.com
|
|
Signed-off-by: Hannes Duerr <h.duerr@proxmox.com>
[TL: drop all other unused Dumper use statements]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
Reviewed-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
|
|
Signed-off-by: Johannes Cornelis Draaijer <jcdra1@gmail.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
create_etc_interfaces_sdn_dir creates the /etc/pve/sdn directory.
This allows mocking in tests to prevent system fs access in tests
Signed-off-by: Stefan Lendl <s.lendl@proxmox.com>
Reviewed-by: Max Carrara <m.carrara@proxmox.com>
Tested-by: Max Carrara <m.carrara@proxmox.com>
Reviewed-by: Stefan Hanreich <s.hanreich@proxmox.com>
Tested-by: Stefan Hanreich <s.hanreich@proxmox.com>
|
|
If zone is not set, we also check the pending changes for a zone key,
since it is set as pending when the Vnet settings have not yet been
applied.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
|
|
Currently when updating or deleting a mapping in the IPAM we would
delete all existing entries in the IPAM with that mac address. Now we
only delete the specific entry we are updating / deleting.
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
|
|
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
|
|
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
|
|
this is for completeness, currently no plugin has optional
properties...
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
|
|
Handle 'delete' parameter and partial updates.
See 2 commits earlier for explanation.
Cc: Alexandre Derumier <aderumier@odiso.com>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
|
|
Handle 'delete' parameter and partial updates.
See previous commit for explanation.
Cc: Alexandre Derumier <aderumier@odiso.com>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
|
|
Zones previously expected a complete config, but the API schema
also contains a 'delete' parameter via the SectionConfig's
updateSchema() helper. This was not handled, and instead failed to
validate as part of the config.
The same is true for vnets and subnets, while ipams, dns and
controller entries followed our usual update procedures (but also
ignored the 'delete' parameter).
Since all of our SectionConfig based API endpoints are supposed to
take changes, rather than complete configs, this changes these
endpoints to not replace the full configuration anymore.
This is a major break for automation tools (the web UI already passed
the full config each time).
Cc: Alexandre Derumier <aderumier@odiso.com>
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
|
|
The initial URL structure was less than optimal due to Ipam as well as
Ipams being endpoints in the API, which are too similar and might be
confusing to users.
Move the listing of PVE IPAM to /ipams/pve/status
Move the create / update / delete endpoints to /vnets/{vnetid}/ips
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
|
|
only register/del ip in ipam here.
The dhcp mapping is done a vm start.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
|
|
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
|
|
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
|
|
Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
|
|
- use new /sdn/zones/zone/<vnet> path for vnet && subnets permissions
- fix some permissions on /sdn/zones && /sdn
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
|
|
When warning or error from ifreload are logged they are received in
1 line in result of pvesh.
So, the UPID might not always start at the beginning, which was
assumed by the old code, failing parsing it, throwing a warning like:
> Use of uninitialized value $upid in pattern match (m//) at /usr/share/perl5/PVE/Tools.pm line 1106.
> Use of uninitialized value $upid in concatenation (.) or string at /usr/share/perl5/PVE/Tools.pm line 1120.
Drop the start anchor of the regex.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
|
like almost all of our repos do nowadays, modern git can detect such
things on rebase so in development stuff should be hopefully not too
much affected by this.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
|
