> 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? > Since we have plans of moving over the existing IS-IS + BGP controllers, those already have their own ACL paths, which makes this a bit messy then.. or does that mean the old controller config and endpoints will be removed in favor of their counterparts in fabrics? > 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
