capsule

capsule copied to clipboard

With the implementation of {Global}TenantResource we started having a sort of overlap with the Tenant API: spec.limitRanges.items and spec.networkPolicies.items allow specifying a set of resources that must be replicated across the Tenant namespaces, and this can be easily achieved starting from v0.2.0 with the new APIs that replicate objects.

If we're going to accept this proposal the change must be considered a breaking change, and I'd vote to rename the current expected milestone (v0.4.0) to be considered a major one (v1.0.0), since end users would need to manually migrate the replicated resources to the new API kind.

@bsctl @MaxFedotov @oliverbaehler let's start the discussion!

@prometherion I love the idea, but I have the following concern - for networkPolicies defined in the tenant spec we have a webhook (https://github.com/clastix/capsule/blob/master/pkg/webhook/networkpolicy/validating.go#L67), which denies their deletion. But for the GlobalTenantResource user can delete the replicated resource, and it will be reconciled in spec.resyncPeriod. And while it is OK for non-critical resources, in the case of the networkPolicies it can be a potential security issue.

@MaxFedotov if well understanding #736 is blocking write operations on GlobalTenantResource by Tenant Owners

Exactly, replicated resources write operations are blocked to tenant owners, but obviously if the cluster administrator deletes those ones there's the resyncPeriod.

I think we should postpone this refactoring to v0.6.0 since the upcoming one is already busy with a new feature and we should proceed one by one since the documentation must be aligned properly.