-
Notifications
You must be signed in to change notification settings - Fork 5
Dynamo namespace based isolation #28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
@@ -0,0 +1,199 @@ | |||
# Multi-tenancy support for DynamoGraphDeployment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
# Multi-tenancy support for DynamoGraphDeployment | |
# Frontend Isolation in DynamoGraphDeployment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
open to other thoughts here - but want to pull back from the notion of mult-tenancy and consider this more of isolation and reuse of nats / etcd for dynamo clusters.
we should break it into nats / etcd as part of the dynamo cloud instance?
So each k8s namespace has an operator and nats / etcd
every deployment within that share that nats and etcd
in order to deploy multiple isolated graphs within that deployment - we need hierarchical namspaces
I think we should motivate that last via customer requirement - is that needed? Likely yes -
No description provided.