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
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) > skip the sub-type component here if we intend to keep it like that > (forever ;)). > > unless there is a (current or future) use case for handing out blanket > permissions for one specific fabric type, but not the other(s)? FWIW, we could then split it with a new root prefix and transform the ACLs on migration in a two-step process, first copy all to new respective sub paths and then drop the old ones once all nodes have been upgraded. Might have some hairy details to figure out but nothing really impossible I think, at least not that much worse than splitting the configs themselves. So think we can ignore potential migrations woes of an ID split here, that's gonna be a bit painful no matter what, and rather focus on the actual relevant use cases now. If the config shares ID it's a strong indication that the ACLs should be shared too. Otherwise, it might make sense to have the configurations use different ID spaces. Gabriel, Stefan: your input please ;-) _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
