In this specific use case, I would think that this would be best as two separate deployments of an ODH Custom Resource. This is me assuming that both deployments are not tightly coupled and a ODH config change in one namespace doesn't trigger some update in the other namespace.

I can't think of any problems with adding a "namespace" field for each component if/when the ODH operator supports watching multiple namespaces. If ODH can be used to deploy across namespaces, I would suggest we strongly emphasize that a single ODH custom resource should be created for components that are considered coupled together so a version update to one component could trigger a change to other components in the deployment.

I could see a use case where a component needs to be unique within the cluster (Ceph) but we want other components to be deployed with references (public endpoints, auth info, certs, ...) to that unique component which would mean ODH would potentially need to work across namespaces.

On Fri, May 24, 2019 at 4:02 PM Václav Pavlín <vasek@redhat.com> wrote:

Hi all,

We started a discussion some time ago about what happens when we add more services and we need to deploy to multiple namespaces (from various reasons - security, resource management, dependencies...)

Let me describe an example to illustrate what I mean by "multi namespace deployment". Recently we got asked by internal Data Hub team if they could use ODH operator to deploy their persistent Spark analytics cluster.

This Spark cluster is independent from ephemeral clusters used by JupyterHub and has to be deployed in separate namespace. That means ODH operator has to be able to manage (at least) 2 namespaces - let's give them semantic names:

* odh-jupyterhub
* odh-analytics

Current implementation only assumes one namespace - the one where the operator is deployed.

The proposed change would require:
* add `namespace` field in CRD for each service or a group of services deployed together
* define default namespace names
* provide clear documentation explaining that a user has to create all the default namespaces (or provide existing namespace names) and give ODH operator edit (or admin?) access to those namespaces
* ODH operator needs to be able watch events from all the specified namespaces (Landon, is that possible with ansible-operator?)

Then the CR could look like something like:

jupyterhub:
namespace: odh-jupyterhub
odh_deploy: true
notebook_memory: 2Gi
deploy_all_notebooks: False
...
spark-analytics:
namespace: odh-analytics
use_crd: false
metrics: true
....

I have probably missed something:)

What do you think? What problems do you expect?

Cheers,
Vašek

--
Open Data Hub, AI CoE, Office of CTO, Red Hat
Brno, Czech Republic
Phone: +420 739 666 824

_______________________________________________
Contributors mailing list -- contributors@lists.opendatahub.io
To unsubscribe send an email to contributors-leave@lists.opendatahub.io