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. Since we have plans of moving over the existing IS-IS + BGP controllers, as well as a new WireGuard fabric, we'd have to load and parse 5 different configuration files for cross-validation then. > Hmm, ok no real value for allowing a user use-access on such a fabric > (for now), and not sure if it is useful to allow certain admins to create > an openfabric fabric but not an ospf one (if the implementation even > uses such fine-grained checks) I think that in practice, admins would create the fabrics and then only hand out permissions to edit that specific fabric, without handing out the permissions to create fabrics at all. It might make sense for Wireguard (where the possible implications aren't nearly as bad as with e.g. BGP), but even then I think my previous point applies that you probably don't want to hand out blanket permissions for a whole subtype, in case you want to make heavy use of ACLs. The current schema is more of a direct result of how the section config is structured, since IDs can be duplicated across different protocols, so you need the additional distinguisher in the ACL path. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
