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. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
