[Question] Why not merge SelectorSyncSet and SyncSet into one CRD?

[gyliu513]

SyncSet can use cluster name while SelectorSyncSet can use cluster labels, why not merge those two CRD into one?

[dgoodwin]

This was our original plan but I believe the determining factor was namespaced vs global. We use namespaces as a small layer of isolation for clusters as those namespaces contain account credentials and certificates. In the case of SyncSet we're tying to specific clusters and thus it made sense to have them be a namespaced CRD. At the time of writing they could contain secrets (we since have a way to break those out), but in general for per cluster content we felt it was best to isolate those into the namespace with the cluster(s) they relate to.

SelectorSyncSet on the other hand we wanted to be a global resource as they typically span many or all clusters in all namespaces. We could do that with some kind of implicit rule like they live in the Hive namespace, but at the time we discussed it felt best to separate them given the differences in their scope.

[dgoodwin]

cc @csrwng @twiest in case I'm misremembering any of that.

[csrwng]

No, that's correct. We wanted SyncSets to be a namespaced resource because it's associated with a cluster deployment in a specific namespace. SelectorSyncSets can apply to cluster deployments across many namespaces therefore they are a cluster-scoped CRD

[gyliu513]

Thanks @dgoodwin and @csrwng , but I think the SelectorSyncSet should be able to cover the case of SyncSet?

[dgoodwin]

It could but it would expose more information globally than we wanted to. SyncSets transfer per cluster certificates, identity providers, lists of dedicated admin usernames, etc. Pushing this up to a global SelectorSyncSet CRD complicates RBAC and potentially exposes us to reveal more information to someone than we wanted to. The distinction between the two offers better flexibility for RBAC in a multi-tenant use of Hive, and possibly better security as well.

[gyliu513]

@dgoodwin this make sense, thanks!