8:46 p.m.
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(a)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(a)lists.opendatahub.io
To unsubscribe send an email to contributors-leave(a)lists.opendatahub.io
--
Landon LaSmith
Sr.Software Engineer
Red Hat, AI CoE - Data Hub