Title
b
Bruno Oliveira dos Santos
03/07/2023, 2:48 PMHello guys! I'm Bruno from the Dadosfera platform team. We are carrying out some studies to change the Orchest architecture, which is currently multi-cluster, to a single-cluster one.
Do you have any material, studies or suggestions that could contribute to this subject?
j
Jacopo
03/07/2023, 2:55 PMHi Bruno, assuming we are talking about multi tenancy, we don't have any good to go material or studies to provide, I can provide a write-up with some suggestions in the following days, not exactly sure how extensive it will be, it's not something we outright toyed with
b
Bruno Oliveira dos Santos
03/07/2023, 3:02 PMOk, I got it. No problem, I believe the suggestions will help us right away. We are running some tests also on this issue, if there is any specific question, I will talk to you. I'll be waiting, thanks
👍 1
r
Rafael Rodrigues Santana
03/08/2023, 12:58 PM@Jacopo basically, today, we have many EKS clusters and we would like to have a single EKS cluster with multiple namespaces with each one containing a full orchest deployment. In this way, we would be able to reduce our current cost. Multitenancy is way ahead of us hehehe
j
Jacopo
03/08/2023, 12:59 PMI see, I've sent Bruno a pdf with some (quite limited) notes, not sure if he has forwarded that already, will DM it to you as well
r
Rafael Rodrigues Santana
03/08/2023, 1:00 PMThanks, @Jacopo.
j
Jacopo
03/08/2023, 1:00 PMDidn't realize you wanted to go for multiple deployments in different namespaces, I think that kinda lowers the value of the notes I've sent
I think a number of remarks will still be valid, but you will have to take a much deeper look at the
orchest-controllerr
Rafael Rodrigues Santana
03/08/2023, 1:01 PMActually no, because in some point in the future we will have to make it multi tenant as well
j
Jacopo
03/08/2023, 1:01 PMI see
r
Rafael Rodrigues Santana
03/08/2023, 1:01 PMBut for now, I think our problem is more simple
We're thinking about using the following approach. orchest-controller already make possible to customize the
namespaceorchestHostj
Jacopo
03/08/2023, 1:26 PMOne problem that we have faced in our internal tests are related to the custom resources that are "global", so we are planning have to remove the definition of those resources from the manifest.do you mean argo & co.?
One question that I have is, is possible using this approach to have a single load balancer instead of a multiple load balancers? or even with a single cluster deployment, we would have to create multiple load balancers as well?I find this question difficult to answer, I'm afraid the answer is something along the lines of "yes but it depends on the exact details of what you are interacting with". It's something I've never dabbled with so I can't really provide anything more than a vague guess.
😮rchest: 1
r
Rafael Rodrigues Santana
03/08/2023, 3:09 PMWe had some issues with this resource while doing the following simulation:
In a cluster that have a orchest already deployed, we have created a new cluster changing the
namespaceorchestHost👀 1
The deletion of the namespace failed as well.
@Jacopo I think we have misundertood the problem. I think the problem was: we were changing the namespace in the orchest-cluster to a different namespace, however, our orchest-controller.yaml was fixed with the
orchestBy changing the namespaces in the orchest-controller.yaml of the second cluster, we were able to launch two clusters in the same EKS and, later on, delete it without issues.
j
Jacopo
03/09/2023, 2:55 PMHey Rafael, I hadn't had the time to take a look at it yet but I'm glad you found the issue, definitively a time saver on my side 🙂
😮rchest: 1
@Rafael Rodrigues Santana , one thing that came to my mind, custom resource definitions are cluster wide, so if you'll allow multi tenancy with different Orchest versions you will have to pay attention to not have breaking chances to the CRD on updates