[FEATURE] Allow CRDs to target an `OpenSearchCluster` in another namespace
tmsdce opened this issue · 2 comments
Is your feature request related to a problem?
I'm just starting off with the operator so maybe I'm wrong but it seems that all CRs can only target an opensearch cluster in the same namespace in which they are declared. It does not seem possible to declare say an OpensearchUser
in namespace A
targeting an OpenSearchCluster
deployed in namespace B
. The CRDs spec seems to confirm this as there is no namespace
field available for targeting a cluster :
# kubectl explain opensearchusers.spec.opensearchCluster
GROUP: opensearch.opster.io
KIND: OpensearchUser
VERSION: v1
FIELD: opensearchCluster <Object>
DESCRIPTION:
LocalObjectReference contains enough information to let you locate the
referenced object inside the same namespace.
FIELDS:
name <string>
Name of the referent.
More info:
https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
TODO: Add other useful fields. apiVersion, kind, uid?
What solution would you like?
Being able to target an OpenSearchCluster
regardless of the namespace it is deployed to.
- This is particularly useful when you want a single Opensearch cluster managing multiple tenants instead of having to deploy a complete opensearch cluster per tenant which can be expensive resource-wise even for small clusters and adds maintenance burden
- This would also allow application owners to handle their own configuration (users, index templates...) while letting "cluster administrators" handle the lifecycle of the Opensearch cluster itself
What alternatives have you considered?
Deploying an opensearch cluster per tenant and/or application instance which seems overkill in some cases
Do you have any additional context?
For reference, the RabbitMQ operator does this. For example, the Vhosts
CRD gives the ability to specify the target namespace of the RabbitmqCluster
(cf. https://github.com/bitnami/charts/blob/main/bitnami/rabbitmq-cluster-operator/crds/messaging-topology-operator/rabbitmq.com_vhosts.yaml#L59)
Hi @swoehrl-mw
Thanks for your prompt reply. Indeed, I didn't catch #596, sorry for the noise. We can consider the present issue as a duplicate so I'm closing it