 So the aim of the project was to explore the possibilities towards developing a distributed setup for IT Bombay X platform, so as to enable the educational institutions that may not possess the skill to install such a complex system. So as part of this project, we have tried to customize and package the platform such that other institutions can set up their own platform with the least amount of expertise. We came up with a native system, which at present has been distributed successfully into two servers. So just a gist of it like what is happening. So as we have understood the problem statement not there, what we have is different type of approaches that we can follow. So one basic or most obvious approach is the native approach. Other is Docker based. One is tutor based and one is Bitnami. So like we have focused mostly on the native approach, but like first of all, we have also tried with tutor and it was successfully installed on the single server and then we tried mostly with the native approach. So these are like all the approaches are live at this IP. Like every approach is live at different IPs. So we can go and check out there. It's running. So like there are various pros and cons of everything. So we will explain native only. Let's start with native. So first of all to understand the architecture, we did a native installation. These were the steps. So we're not going to depth after performing these steps. There were a list of errors that came up after each run of the installation. We rectify the error as we move forward. These are some of the errors that are listed after rectifying these errors. It was installed successfully on a single server. Next we tried on distributed to distribute the platform on two servers. So for that, we need to make some changes on these three files. So first of all, in inventory.ini, only the local host 127.0.1 is mentioned. So in this file, we'll mention the host name, where we want to install the server and their host IPs. Then in open edx native.yml, we need to mention group together the services according to the server in which we want to install them. And finally native.sh, we have to make a change. This file originally consists of by default minus the local and minus i local host since all the services were being installed in the local host. Now that distribution of services into servers have been specified according to the servers present in inventory.ini file. We do not use minus the local and minus i local host. Needs to be replaced with minus i inventory.ini. So these were again some of the errors. Here we have shown three errors and if we go to this link, we have listed down like all the errors. So currently the distributed installation on two servers is live on these two IPs. And these are the future scopes like we have distributed in two servers. It can be easily scaled up in the number of servers. We need to test it for more than two servers with different colleges. And there might be some problems with IDA services like discovery credentials, which need to be fixed in case they are installed on separate services. So that was all. So you said, so you tried three. One is Docker base, native and bitname. And so what is that you identified in a Docker base approach? Because I mean, this is an obvious question to us. You know, for the last so many years, Docker base solutions like Google Kubernetes or Google Cloud systems, they actually run dockers and they don't run VMs. So what is your take on this? So because you mentioned that it is not to be, I mean, should not be using in production. And that is the thing which is there in that edX, the same lines that you are copied, actually. Yeah, the approaches that we mentioned like native or Docker, it's already provided by edX for single servers. So the reason behind choosing native and not the Docker is like what is basically happening in Docker. We are pulling those images which are already hosted into the hubs. So like we can pull those images and then run it. But like we basically require to change the configurations. We need to change the configuration of the image and all that. So that part is somewhat difficult by using Docker. But when we use it with the help of native. No, no, no. So then you should have a whole setup of creating your own Docker images. So you'll have to do those configurations first or some of those things where like inventory.ini, that you'll have to supply, right? That you'll have to supply while actually you're going to install or deploy, deploy the system. But then coming up with, you know, like so, so they have those dockers, right? Already docker files are there. It is not the docker files are not there. But then I think what should have is that you should have your own image repositories, okay? Tailor to your use, you know, what, what things you need to change. Maybe I saw so many things like 127.0.0.0.0, right? So all of this should come from, from the user, right? I mean the system admin who is actually going to feed in that data and then go and sit in on different dockers, right? I mean, that's configuration, configuration changes, right? I mean, that is what is expected. It's like, but then there is another problem. There's another problem. So why that docker based solution is not good is because that is, that is a development type of a thing which they are using. So they have something called as run server. You know run server, Django run server. People use it for testing like that. So if you replace that, see this is one thing which I know. I wanted to know from you and my team other solutions. So one of one, one way to solve this is to replace. I mean to have a nginx there, right? And nginx and gunicorn. So nginx will be your reverse proxy. You have to know the configurations of nginx. What is that you want, right? And then you have gini ginicon, right? Which will act as your web application server. So if these things are put and you have a separate docker or something, okay, nginx docker, and then you supply those configurations as you want. Do you want asynchronous? Do you want synchronous? Do you want, I mean, there are so many options you will find, okay? Where you'll have to supply and you'll have to find how the servers are acting, right? I mean, do you want all the HTTP calls to go and call gunicorn and get all those static files? Or do you want Apache or nginx only to serve those HTTP files? I mean, so we'll make static files. So these things, you know, these are very important. So when you see, when you go for production, these things are quite important. And if you can give this to a user who doesn't know all these things, right? And then maybe a click of a button, you should be able to install it. I mean, that is what we expected in this kind of thing. The one that is available there in IIT Bombay is using native. Yeah, I know, I know it is using native. But I think the world is going towards docker-based solution and... So sort of, you can say, a decision was made before they arrived that we will go with the Ansible Native approach for doing the IIT Bombay's installation, the distributable one. So they did it as part of exploring all the options to make sure that whatever are the other options, we definitely want to reject them, okay? So with that view, they have done all of those. And now, again, the conclusion is that we want to go with the Ansible Native approach, which is why we have not explored the docker at Bitnabi options much more, okay? We are focusing on the Ansible. Yeah, yeah, no, the native, the first... ...the first option that they talked about. I don't see any much difference is there... Yeah, yeah, no, no, I'm saying that we have chosen one approach. It is possible to approach, to explore the other approaches also. So I asked this question because he has put a slide there, right? And he has put a slide on docker, and he has put a con on that. So I wanted to know what are the other cons, right? Okay, so one I can... So that is what... One that I can talk about, One that I can talk about is the... No, no, no, I don't want you to talk. I wanted them to talk. Because when you put something, when you put something, why is that they are put? I have some simple questions. So if one can play the slide and one can answer my question. So you install on two servers, correct? So now I want to install it on three servers. How easy or difficult it is now? Means now you have explored the process. Now you know how to install on two. Then... While installing it on two servers, what we have thought is, let's keep all the DBs on one server, and other services running on the other server. So now when we are installing it on the three servers, more than three servers, so these same kind of decisions we need to make. Like what all services we need to run on one server, what all services we need to make on other servers. So let us say we made that decision. Let us say we made those decisions. After that, how easy or difficult is it for you to install on the given configuration? First of all, we have specified the three files. First of all, we will make the changes in inventory.ini. There we will mention the three servers, and then open it as native.yml. Here we will mention how we want to distribute it. For example, we will group them together like these services we want to install in this host, these services we want to install in the other host, and so on. Okay. And then we will run the native.sdc. What you mentioned, like you received lots of errors while you were installing. So what are the chances now? Means the same errors will be there or some new errors will be there. So new errors might come, but with one or two services. Okay. Most of the errors that we found out, we are able to remove that, except for some of the errors like this one, instances of local host that is 1.2.7.0. are present at various locations. What this causes is, if some services are installed in some other server and they are not able to communicate between them, this will cause a problem. So to resolve this, we haven't, this error is still open. We haven't been completely able to resolve this. We have resolved this for two servers. For two servers, this works fine. We have mentioned the host like how to communicate between them. So for three servers, et cetera, if those who are communicating between them, the services that communicate, if we distribute them in different servers and they are not able to communicate, then those won't run. So that would be the problem. So for that, we need to understand the architecture, how they are communicating in greater depth in order to solve that problem. So now you know the architecture, correct? You know the architecture. As we have written, we don't know in great depth, so. Okay, but let us say I have given you a task to install it in five servers. Okay. I have given you the configuration also. So how much time do you need to do that? Okay, so this three can be done instantaneously. We'll change the, and as you say, we can. But after that, as we'll try, after we'll run the native.sh. Now for every error, we'll have to run the script. So it's a long process, basically. Okay. So for example, here on 17 errors we got. So that means like 17 times we ran the whole script. Thank you.