On 4/11/25 1:12 PM, Stefan Hanreich wrote:
On 4/7/25 11:27, Fabian Grünbichler wrote:
Stefan Hanreich <s.hanre...@proxmox.com> hat am 07.04.2025 10:51 CEST
geschrieben:
On 4/7/25 10:12, Thomas Lamprecht wrote:
Am 07.04.25 um 09:24 schrieb Fabian Grünbichler:
On April 4, 2025 7:20 pm, Thomas Lamprecht wrote:
So, without looking at the implementation, fabrics have the IDs unique
per sub-type? Could maybe also share an ID space, less confusion
potential, but naturally also less flexibility – what do you think?
they share a section config (and thus ID-space), so I guess we could
There's one section config file per fabric, so its ID is unique per
protocol. We'd need to load *all* configuration files everytime we
change one configuration file (at least when adding a fabric) so we can
validate unique IDs across all fabric types.
mea culpa, must have mixed that up with something else (probably the
controllers :-/). would it make sense to merge them given the similarities?
Re-visiting this again, I took some time to write about the problem in
greater detail and present some options. I'd really like to get the
ball rolling on this discussion sooner than later, since otherwise
it's hard to proceed with this patch series. This is a short overview
for you to get a better idea, but it might make sense to discuss this
in greater detail in person.
Overview
========
We have multiple types of fabrics:
OpenFabric, OSPF and more in the future.
We have the following hierarchy of models:
Fabric -> Node -> Interface
Some constraints for the models:
* There can be more than one fabric of a given type
* A fabric contains n nodes, a node contains n interfaces.
* A node can be part of multiple fabrics, but one interface of a node
can only be a part of one fabric.
* Each of the three models has its own properties, that vary depending
on the type of fabric
Some fabric specific constraints can apply as well, for instance:
* the IP prefixes of fabrics should not overlap
* the IP of a node should be unique within a fabric
* an OSPF interface can either have an IP or be unnumbered
* OSPFv2 supports only v4, OpenFabric supports both
Ideally, we'd like to validate all those constraints when modifying the
configuration via the API or loading it.
The key issues we ran into:
* The type of a section can only be uniquely identified together with
the protocol (e.g. ospf_node)
* A node section can only be uniquely identified together with the id
of the fabric that it belongs to (a node can occur in multiple
fabrics)
* 3 layers is one too much to cram into one section imo, so we have to
at least split fabrics and nodes into two sections
* parsing the type/id of a section into multiple fields is a bit
clunky with the section-config implementation. Ideally we'd like to
not have to do this separately at every site (rust, perl, frontend),
but once when reading.
* ideally, validation of *all* the constraints laid out above
Solutions
=========
#1: Storing everything in one file
----------------------------------
# fabrics.cfg
<type>_(node|fabric): <fabricid>[_<nodeid>]
+ fixed amount of files
+ validation is simple
+ API/ACL paths are simple
+ related entities are in the same file
- composite section types
- composite section ids
- complex API definitions
- file can grow quite large
#2: One file per fabric type (current solution)
-----------------------------------------------
# <type>.cfg
fabric: <fabricid>
node: <fabricid>_<nodeid>
+ simple section types
+ simple API definitions
+ related entities are in the same file
- API/ACL paths are more complex
- composite section ids
- variable number of files
- validation requires reading all files
#3: One file per level in the hierarchy
---------------------------------------
# fabric.cfg
<type>: <fabricid>
# node.cfg
<type>: <fabricid>_<nodeid>
+ simple section types
+ fixed amount of files
+ API/ACL paths are simple
- related entities are in different files
- complex API definitions
- composite section ids
- validation requires reading both files
#4: One file per fabric
-----------------------
# <fabricid>.cfg
fabric: <fabricid>
node: <nodeid>
+ simple types
+ simple ids
+ API/ACL paths are simple
+ related entities are in the same file
- complex API definitions
- variable number of files
- information about type has to be encoded somewhere (directory?)
- validation requires reading all files
Imo, #2 and #3 seem like the contenders. #3 is what we use for zones /
vnets / subnets, and it is . #2 makes API definitions a lot nicer,
since we have exactly one schema per API endpoint, which also makes
the generated API types in Rust a lot nicer. With #3 we currently
generate two structs where basically every field is an Option<T>. The
solution for this could be using oneOf across the whole API, but afaik
that is not implemented in Schema2Rust currently. Alternatively, we
could pop our own abstraction models on top of the generated types and
convert from / to them when using the API in PDM, but the real
solution is implementing oneOf support in Schema2Rust.
Reusing the models directly on the PDM side would of course render the
whole point wrt Schema2Rust moot.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
