Dedicated namespace for TCP

[florent1s]

It would be useful for us (and maybe others ?) if there was an option to deploy the TCP instances in a different namespace than the one holding all the other CAPI cluster resources. Just like the deploymentNamespace option in the externalClusterReference section but without the external cluster part ;).

I tried to circumvent this limitation by using the externalClusterReference but pointing to the same cluster. This works fine except for one aspect: when enabling externalClusterReference, the TCP and other associated resources (service, secrets...) get a name based on the KCP uid. This means that this name is no longer predictable, which breaks other things in our envisionned setup. I would like to understand the reason for this, is it just to avoid conflicts based on the name in the remote cluster, or is there something else ?

Another acceptable fix would be to give the option to use externalClusterReference but sticking to the default behavior when it comes to resource names. But I think solving the issue at its core would be a better approach (or maybe both options could be useful to implement for certain usecases ?).

Looking forward to discuss this further and if one of these ideas gets approved, I would be willing to take a shot at implementing it.

[prometherion]

This works fine except for one aspect: when enabling externalClusterReference, the TCP and other associated resources (service, secrets...) get a name based on the KCP uid. (...) is it just to avoid conflicts based

This is exactly the goal we're aiming for since a cluster reference could host multiple Objects from different Tenants, and the potential collision rate with UUIDv4 for Kubernetes objects is insignificant.

Another acceptable fix would be to give the option to use externalClusterReference but sticking to the default behavior when it comes to resource names.

This approach has downsides, since it could lead to collision, and would require more granular control to avoid this.

But I think solving the issue at its core would be a better approach (or maybe both options could be useful to implement for certain usecases ?).

This is the first report for such a feature request, it's not in the pipeline given the internal roadmap we have for the CAPI Control Plane provider.

I would be willing to take a shot at implementing it.

Given the adoption of Kamaji we warmly welcome new contributions, even tho such features could introduce breaking changes: we need to evaluate with care.

[florent1s]

Thanks for your reply, I tried implementing the first solution, but execution fails at TCP creation because it holds an ownerReference from an object in another namespace (the KCP), which is not possible. I don't know if there is a way to circumvent that.

I also implemented the second solution, (see #215 ) which seems to work well. I think that with proper disclaimers in place to discourage people from using it when not needed, it should be fine.