Hello everybody. Thanks for joining. We're going to get started in a minute while we're waiting Don from Hewlett Packard Enterprise has shared a bunch of links in the chat bar So feel free to check them out and make sure that they're still there. Are they still there because I had a little blip here with zoom And I still see them so I believe they're still up in the chat window Excellent, and you can see my screen. I hope Hey everybody. Thanks for joining. We're going to give a minute or two to start the presentation in the interim. There are a bunch of links in the chat for you to check out. Oh, it looks like maybe they're not in there to the new attendees. So I'll go ahead and post those right now. Thank you. Okay, the links are up in the chat. So let me know if you still don't see them. Looks like it works. Great. And we'll get started in a minute. Okay, let's go ahead and get started. I want to thank everybody for joining us today to the webinar building dynamic machine learning pipelines with cube director Presented by Hewlett Packard Enterprise our presenters today are Tom Thieland fellow at software organization and Karthik Mathur master technologist and Don Wake technical marketing engineer. A few housekeeping items before we get started as an attendee, you're not able to talk during the presentation, but you are able to ask questions down at the bottom of your screen and the Q&A tab will be asked answering those questions at the end of the presentation. Also, this webinar is subject to the CMCF code of conduct, so please be mindful of what you say in the chat or the questions and please be respectful of your fellow attendees as well as the presenters the webinar and recording will be up later today on the CMCF webinar page. And with that, I will pass it over to Don Karthik and Tom. Great. Thanks a lot, Julius. I'm Don Wake and I guess I'll have each guy wave so you know who they are. Tom, go ahead and say hi. Hello everyone. And there's Karthik right there. Hey everyone. I love your shirt, Karthik. Got you. I thought at first it said got milk. I'm like, dude, why are you wearing a got milk shirt? No, it's got ML. You got to pay attention to details here. Okay, so let's move along. So we're going to talk about building dynamic machine learning pipeline. So machine learning, you know, what, what is, what is it all about when you're deploying an enterprise artificial intelligence application? And how do you do that at scale? And, you know, what kind of tools do you have available to do all these things? Number one, it's a very complex thing to set up, execute and operationalize as is quoted here on the right by Gartner where 60% of the models may be developed with the intention of, you know, getting answers from them, but they quickly grow to a level of complexity that's hard to manage. The data sets change frequently so it becomes hard to keep your machine learning pipeline, you know, dynamic and up to up to speed. And then Kubernetes obviously is the tool of choice that everybody's using to orchestrate manage their containers, but it also is fairly complex. So what can we do to help, you know, improve the usability of your machine learning pipelines. So that's what we're going to talk about today. We've got our overview. Stateless and staple applications will be discussed briefly. What CUBE director is really the subject of this webinar and how it is used to help you build these dynamic machine learning pipelines. What, what you do when you're creating these clusters of CUBE director apps called KD clusters. And then once you have your clusters how you use them to train your ML model register the model create an inference deployment and serve queries to get answers. So let's jump right in. Go ahead, Tom. Thanks, Don. So, as Don pointed out, we're talking today about ML pipelines and the use of Kubernetes to deploy and control those pipelines. But before we can begin, we have to actually look at the application types that are involved in that pipeline of applications. Now as we all know, Kubernetes is best used or is most designed for stateless applications. And when we say stateless applications, what do we mean? We mean application that is designed for the from the ground up as a micro services architected application. That means the storage, the state of the application is separate from the compute instance that is running. So when we use containers, we can horizontally scale the compute. So we bring on more and more containers running in parallel in order to run our application more quickly. So we get to an answer more quickly in the ML parlance. These are typically referred to as cattle, because any of these containers can be killed, can be exited, can move around, and they don't lose the state of the overall application. This is key when we think about the applications that we're using to build our pipeline. So, Don, let's go to the next now. We'll contrast stateless applications with stateful applications. Stateful applications typically are legacy applications. They may come from the 80s, the 90s, the early 2000s before the industry embraced cloud native architecture, micro services solutions, and that sort of thing. So what these applications have is they tend to co-mingle state with compute. Now, with Kubernetes, we spoke about with stateless applications, there's a separation of compute and storage. But with stateful applications, there's some metadata. There might be a little bit of configuration information that's unique for each container that's running a portion of the compute for that application. If that container exits, there can be a loss of state, so a loss of continuity that has to be kind of rebuilt when we spin up a new instance to replace that missing instance of the container. These are referred to as pets. So even there they're horizontally scalable, there's kind of a separation of compute and storage, but if you lose a running instance of a container, you have to be careful on how you bring it back to life. That's because each pet is unique. So even though there's a hundred or a thousand cats that look much like your own pet, your pet's unique because there's a different personality. So when we talk about these applications and Cartiq will get into more detail about the specific applications that are used here, these applications tend to be a little bit stateful, but not entirely stateless. So we have to be careful as we assemble our pipeline. Fadhan, can you move forward please? And Kubernetes is the open source community. Like I said earlier, Kubernetes was originally designed for stateless applications, but there's been a lot of progress over the years. Various items and resources like objects and pools, stateful sets. I already mentioned persistent volumes, persistent volume claims. The concept of an operator or a custom resource definition is a specific piece of go code that helps manage stateful applications a little more easily, but they can be cumbersome. Fadhan, let's go forward. That's why we're introducing Cube Director. And let me just back up a moment in full disclosure to the audience. Myself and Cartiq, we come originally from a startup company known as Blue Data. Blue Data was acquired by HP Enterprise a few years ago. When we were at Blue Data, we specialized in running artificial intelligence, machine learning, deep learning applications in containers on Kubernetes. What we found is that the existing tool set for setting up pipelines of stateful applications didn't really meet our needs. And so we instituted this or kicked off this Cube Director open source project under the auspices of the CNCF. And so that's what we're going to be talking about today. There's a link here on the slides.  So Don, let's just one more one more time forward please. We'll do and just real quick this link. I pasted it into the chat window so you can go to that it's called it's labeled Cube Director code if you'd like to see the source. Thank you very much. So Cartiq I'll turn it over to you to talk about how we support legacy applications with Cube Director. Thanks a lot Tom. So Tom talked about stateful and stateless application and he talked about, you know, if you want to configure legacy application, how the state is very important. And we don't even have to go that far, even if you take an example of something like Hadoop. It's a classical example, you know, of a stateful application. A lot of services are dependent on, you know, on one service like in the Hadoop world, a lot of services depend on ZooKeeper. So they need to know the state of ZooKeeper until the ZooKeeper, how many nodes are there, where are they running, what are the addresses until the ZooKeeper is not up, they cannot start configuration. So that's a very good use case for something like Cube Director, you know, so how do we achieve it? We maintain in cluster data structure, which gives you a cluster level view, which tells you what services are running, how many pods are there for every role. So that, you know, a service A, which needs to talk to service B, can look at this data structure and do the orchestration accordingly. So that data structure we call as config metadata and that is managed by Cube Director and is constantly updated as the state of the cluster changes. We also have some lifecycle events, what we call the guest config hooks, you know, basically they tell any service what's happening in the cluster. Is the cluster being expanded? Is it being shrunk, right? Nodes are being added or deleted and then the config metadata data structure is updated and then the service can react accordingly. And all that orchestration layer is what we call as app config, which relies heavily on config metadata and guest config hooks. And for any service to query this data structure, there is a nice little tool which Cube Director injects whenever a pod comes up and that tool is config CLI. Let's keep going. I think Tommy we're going to talk to us about this sort of how you deploy it. Good. So, I mean, we may have been remiss just to be clear, Cube Director is a Kubernetes custom resource definition itself. It's an operator.  And then what you can do with it is you submit a JSON file or a YAML file to that operator, and then it will manage the instantiation and the life cycle of that stateful application on Kubernetes. So with here we have with our cube call standard command, we are deploying a deployment of Cube Director in our Kubernetes cluster. What we're showing here with the little graphic is that you have the Cube Director operator. It has a when you're specifying a application to be deployed and managed by Cube Director. You provide a definition of that has some it will go through examples in the following slides. It will define an image it will locate an image from the image repository. It will specify connection information it will specify configuration information. A scalable roles information about that application. You apply it to the Cube Director. Cube Director will deploy it. If you wish to update it you use Cube call again you probably pass in a new configuration file and Cube Director will do the reconciliation. So it will bring the running instance of the cluster of the application into alignment with the new configuration specification from the YAML file. The standard operator behavior or Kubernetes cluster but what we're providing is we're providing a solution to allow you to run any stateless application without having to write your own operator. All you have to do is specify some JSON or YAML provided to the Cube Director and Cube Director will do that for you. So I'll pass the fact of Carti to go through some more detail in this regard. Yeah and just to give you an overview before Carti talks about the applications KD apps. You know just a level set. I think everybody on this call knows what we're talking about with a basic machine learning pipeline. This is what we're going to be working towards building out with Cube Director we have the training we have input data sets. This is an illustration of your model once it's created all of that circling around some central persistent storage repository where you have your data prepped and stored and accessible by the clusters and then where the models themselves are made available for inferencing. So Carti take it away. Sure. Thanks Don. Thank you Tom. Let's talk about Cube Director application. So we already know now by now that Cube Director is a Kubernetes operator in Kubernetes operator world you have custom resource definition CRD and then instantiation of those are custom resource. The application is a generic you know CRD it's it's where all the expressiveness for any giving an application comes where without writing any go code of an application developer can define what is the application going to look like we will be going deeper into that like we will be and define things like roles what services are in a roles cardinality and a lot of other things. So that the custom resource is the Cube Director application and we will be looking at some examples for those For this presentation specifically we will be focusing on three Cube Director application. One is your training application your Jupiter application and then finally a deployment application and then how we stitch them together using some Cube Director features like connections. Awesome. And again we also pasted a link that you see on this slide in the chat. So look for the label get hub example applications you'll see exactly the code that we are going to be walking through which is right here. So back to you. Yes. Okay, so this is a concrete example of a Cube Director application. We will be focusing on the green blocks. That's the areas of more interest. So now, Cube Director knows about this custom resource called Cube Director application what it is entirely depends on the application developer. They can define what roles, you know for every role behind the scene Cube Director creates stateful sets for every role to you know convert into the Cube and it is native resource for every role, you can define a bunch of services and for every service you can attach metadata. All that definition happens in the Cube Director application Jason. This can be a YAML as well in case they are used interchangeably. So if we focus on the first green block, we are defining our role, what is the cardinality means you know just one part for that particular role. And the heart of that is package URL where you give your orchestration code. So Cube Director invokes these scripts once the pod is launched for that role. And all the business logic, how to configure whatever service you need to configure in that particular part is happening here. And this is actively using the config metadata using config CLI utility to happening what's to know what's happening in the rest of the cluster. And then it also takes an image. That's a Docker image. So second green block is pretty similar just talking about another role, which is a different image. In this particular example, we have three roles using three different images. Every role has its own kind of an orchestration layer, which you supply using package URL. And finally, you have these bunch of endpoints under services defined and you can, you know, tell Cube Director something more about those services that I want the service to be secured using a property called has ought to open. Once you do that, Cube Director generates a unique token or authentication token or identifier so that anybody who's trying to hit that endpoint will have to supply that authentication token in the HTTP header. And then inside the pod you can write the logic to verify if the token is correct. So, so a lot of those features are Cube Director out of the box supplies, which, which people don't have to write again and again from different operators, which would, which is kind of how it happens outside of Cube Director, like if you're writing Kafka, if you're writing Cassandra, Mongo, also machine learning application, you have to keep rewriting lot of data code, right? All that is taken care behind the scene by Cube Director. Awesome. Thanks, Karthik. So it really shows how you're starting to wrangle the difficulties that you run into building these complex machine learning pipelines. So here's an example of a pipeline that we're going to use. And again, even the data sets for this is available online at our GitHub, I believe is we linked that as well. So the problem description and artificial intelligence application has to predict the travel time for proposed taxi ride. So we're going to take this huge data set from years and years of compiled data in New York. And then we're going to allow the user to query specific points A to B to see and figure out what the average travel time would be. So back to you, Karthik. Quickly, I'll just go ahead through this, Sidon. Thanks for setting up the demonstration we're going to show today. So Karthik has already talked a little bit about three components. We saw those in the YAML file. So let me just kind of piece this together. So Sidon points out what we're going to do is going to build a model. We're going to build a neural net model. That will allow us to predict travel time by taxi from point A to point B. So what we need to do is need to train a model. So we will deploy a training cluster. That training cluster typically will be deployed using on resources using GPUs because GPUs are more efficient when training a model. Now we also need to deploy an inference model. Inference typically runs better on regular CPUs, doesn't need the special power of the GPU. So we'll have two different specifications. We'll have a specification for our training engine, we'll have a specification for our deployment model, our deployment engine. And then we'll also have a Jupyter notebook as Karthik points out. And why do we have a Jupyter notebook? Because it's easy for the data scientist. They're familiar with the Jupyter notebook in order to interact with the training cluster and train it appropriately given the data sets that we will be using. So what we're showing here in this little box is the three cube Cuddle commands that deploy the specification for each of these components that we'll be using in our pipeline. Our app training engine, our Jupyter notebook, and our deployment engine. So what's going to be shown in the next few slides here is how we assemble these, how we share data between the training engine and the deployment engine. And that's the real power of cube director. So I'll send it back to Karthik. Thanks Tom. So now we are looking at the second, you know, important custom resource that cube director manages, which is a cube director cluster. So cube director application is kind of a template is a very static thing where you define bunch of, you know, mappings about between roles and services and service to endpoints. This is, this is the more interesting part with cube director manages is the instantiation of that particular cube director application. You can create one or many cube director cluster and cube director is constantly watching this custom resource called cube director cluster. And anything that's happening in the cluster is reacting to the change. So cube director cluster relative to cube director application looks relatively simple in terms of, you know, just if you look at the YAML. Here you just already predefined your application, which in this case inside spec is training engine inside that you already defined your roles while defining the app. So now all you're doing is for every role you're asking for how many members and what's the resource for every role. So for this, this presentation, we're, we don't have GPU YAML, but it can you can provide GPU while requesting for resource. So, yes. Okay, on the connections I guess what we're how you use that between the clusters. Yes, exactly. So now, it goes back to our the title for this presentation is building dynamic pipeline right like there are two two keywords there pipeline and dynamic. And that's that's the connection is at the heart of that pipeline means you are stitching together a bunch of things.  Those are unrelated cluster and how do they cluster knows about each other is through this cube director feature called connection. We talked about the data structure called config meta. If you want to extend config meta to have information of other running cluster. That's what connection lets you do. If you focus on this YAML here in the spec there is connection and then you say to config maps. So that cube director reads those config map, get the data and sticks it inside your running clusters config meta data. So now this cluster also knows about those config map and as those config maps are changing this meta data is changing and services can react accordingly. Using connection. We have currently implemented three resources like a secret can be a connection config map or or another Katie cluster, but the idea is more broad or generic. You can have more resources in future in cube director, you can extend cube director to have another custom resource, which is, which is an operator in itself, or another CR to be a connection. Once you do that, then this cluster will know a lot more about what's happening there. And as those things are changing, this cluster is constantly evolving and reacting to the change. And that's that's how we get the dynamic part of it. So in this, this is a very simplistic pipeline. So you have observed like in actual machine learning you have, you can drill down on every step like training itself will do a lot of data munging data pre processing. All of them can be separate running cluster in themselves and using connections you can tie them all together into a nice pipeline. So alright. So this is what we're going to build. I think we've laid out the foundation for, you know what the problem statement is at the end of the day as Carter just mentioned we're going to have three clusters individual clusters doing individual jobs they're all part of the pipeline. So we'll build this out step by step. And as you can see at the top there is a persistent storage layer. That's where our taxi ride data set will be that the training cluster will read. That will train from eventually get our model stored in that same place which can be accessed by the Jupiter notebook and by the inferencing deployment engine, using also storage scoring scripts and in the persistent storage. So let's jump right in and get this sucker built. So we're looking at the QQ training app, and we've been talking about different QQ director app and cluster. So it's a simple cube cut to create for people familiar with KS or Kubernetes. You just do a cube cut to create or apply offer given YAML and the Kubernetes will take care of creating and managing that resource. So this will create your first block in the pipeline which is, which is the actual training engine where the training computation will happen. Okay, let's keep going down. So we built the ML training as promised we're going to kind of slowly build this picture out so there's our tax and write data set there's our Coop director cluster. Right. And now comes the most interesting part for data scientists which is a Jupiter notebook. Which is a QQ director application itself. So Jupiter notebook is the most popular kind of an interface for people doing machine learning or any data science problem solving. In the same spirit like you did, like Jupiter notebook, they can come up with any, any notebook, it could be Zeppelin or something else, which they are more familiar with. For this example, we have taken Jupiter notebook. Now you have this lightweight notebook and you have this beefy training cluster using connections multiple people or data scientists can just spawn this lightweight notebooks and connected to the training cluster. And we have extended the notebook as part of the QQ director examples to utilize this connection so that you can remotely submit your code. Whatever you're doing in Jupiter notebook will not be executed locally and can be then posted on a training cluster so that you get access to the beefier resources, more GPUs. So we've got that kind of beefy cluster over here that's got physical resources potentially GPUs we can do a lot of that hardcore, you know, machine learning. And then as you mentioned you got to just with a couple coob co create commands and definition files. You've got a connection between the lighter weight Jupiter notebook the data scientist is using and accessing kicking off, you know, managing this this cluster. So this I guess talks about talk about how the Jupiter notebook itself, you know, utilizes that connection. Right. So here now, as I mentioned in last slide. We have done some, some, we have added some intelligence to Jupiter notebook about the feature that we have been talking about called connections. There is a functionality in Jupiter notebook where it gives you some hooks to extend the interface. Those hooks are called magics. We have defined our own magic in so like you see percentage attachments that's that's a line magic that run some code behind the scenes to get all the metadata for a given connection. In this case it tells you what what is your training cluster. Again, you can continue to add more training cluster using connection snippet to your notebook. And when when you rerun this magic, you will see more than one here if you've added more or you can remove. So all that is very real time. And then as you are bringing and removing cluster you can then try your training example on different cluster just by sitting in one notebook session. Great. So we actually had a question there that came in from rock about you know what is the Jupiter notebook and hopefully that what we just showed gives you an idea of how the Jupiter notebook is sort of. I mean, how would you call it Tom the card it gets it's really what runs the show it's it's your direct interface to your abstract model you know we're doing all the hard plumbing in the background but here your Jupiter notebooks you know really building the model or allowing you to to make things happen right. It's just it traditionally used to be called I Python notebooks. Now it's called Jupiter notebook, they continue to add more and more features it can give you authentication with external ADL depth servers. So this is this is a very nice tool industry standard, which is constantly evolving for data scientists, and that's why it's very popular predominantly used for writing Python code, but with the example of each we have shown even when you are in a Python kernel for a notebook using magics you can put your our code, and we will just take that code and post it on our kernel or in some other language. Yeah. Awesome. Thanks. Okay, so you know we're building out our pipeline here showing the training engine now with the connections actually now we actually see a model also being stored in a central persistent storage library. So now the config map. So a model can be you know it's it's very subjective concept. It depends on library what you're using. Once you have a model to be able to deploy that in a proper production allies pipeline, you need to see realize the model, and then you need some you can deserialize the model, and then can basically give an endpoint, which people can hit and make inferences. For us, we have concept we have represented model in in a KS resource type which is very popular config map which is nothing but a key value structure. You can provide the path of your serialized model. Where did you store your model on persistent storage using the training cluster. You as part of the training job, and then the intelligence about that model, what what libraries was that model serialized with how to de serialize that model, how to plug in new input to that model that goes in in a script called library, which, which people who are interested in deploying this model will have to write. And we maintain that where the scoring script is and where the model is in this config map. Again, we will be using connection feature, while creating deployment cluster to make deployment engine aware of what models, you have to deploy with them. Great. So we've now gotten to this point in the almost have the full thing built. We got our config Mac built, and now we're going to create an inference server deployment. Right. So now deployment engine is is in that first block in the pipeline is number third block where you have your training. You have your notebook. You have your config map, which, which represents your model. Now finally, you want to deploy it. So again, bring up a deployment agent engine, which has the compute libraries to run the scoring script, and then just connected with the, with the config map. So that's what we're doing here. We defined a model in config map. We use connections to let the deployment engine know about that model. And I see here it says cube director can inject the contents of config map into the JSON file within the clusters. Exactly. And that's that's what the connection feature is essentially when the server is connected to director will be constantly watching that for you as things are changing there, it will be reading that and getting the contents and sticking it inside your config metadata. And you have config CLI, which you can constantly query. On top of that, we also give the lifecycle event hooks, which tells that, you know, things have changed here, do you want to reconfigure do you want to make use of this new model So all that is happening and changing real time and things are constantly evolving. That's that's how this dynamicity of this pipeline. Fantastic. So what would you say is happening here. This is finally you have your ML pipeline running. You, you have published an endpoint, whatever that model was in this particular example. So if you're interested in predicting to go from point A to point B, how much time I'm going to take in based on the training data set which was for New York City. So while training the model, these were the interesting features to the data scientist, you know, let long, you know, day of the week. If we ask you for these, you give us new input for a deployed model using the pipeline, it will go to deployment engine, you plug it in. And then it will make some prediction for you. So at the end of the day, 1679 seconds is the answer. Yes. Yeah, it's not the most optimized model. No, it's actually fantastic because this is really demonstrating everything. This is coming from the perspective of the user from some URL anywhere into this model and after a few simple inputs, you get the outputs. Of course, this is a, as you mentioned before, simplified for demonstration. Exactly. And this is just making a rest rest API call to the deployed model on the published URL. It could be an RPC call. Instead of Python, you can write a rest client in, you can use some postman or you can use any rest line to consume the model up to the end user. Okay, so that brings it all full circle. And it looks like we've got lots of more things to kind of tell people about that this is a very live open source project with more to come. Right. So this project, for this example, we are showcasing how you can build dynamic machine learning pipelines. But this project is much more than that. It is trying to solve the problem of rewriting operators every day for every application and whatever the common day to operation is we are trying to take care of that and make it inside cube director. So we can, we will continue to enhance this based on, you know, what are what use cases we are seeing. So like, like we mentioned, the concept of model is very simplistic right now it's just a config map but it can be a CR in itself and it can have much more intelligence and we can constantly monitor that better. Once we define that as a CR. We are brainstorming up about that. We will be enriching our example catalog, which already has quite a few applications but we will be adding more something like distributed and the flow to utilize GPUs. We can add more CR which are basically makes this pipeline more richer by adding things like model registry data set management and feature engineering sort of application in the mix. So the secret is already better than config map because it's base 64 encoded but still we want to be further solidify that and encrypt those so that inside the part. People cannot just decode it who has book and whoever can do to execute inside the part. So we're working on that. There are policies for role scaling placement constraints there there are a whole bunch of things that we're already working on. All those issues are listed in the URL don people can just go there. Take a look start contributing ask questions. Yeah I was just going to say contributions that's the beauty of this it's an open source project these are the things that we have seen kind of as the experts and founders but I guess Tom is there more you would say there as well as we this is open source. So it's completely, you know, we're trying to get into incubation stage so each piece in the process of, you know, going through the process with cncf to get that done and of course we'll move through the pathway to fully fully support and release open source project within cncf. But please don't don't let that slow you down. We'd love to build out the community of developers. The more people we have working on this the better more quickly we can enhance it to add additional functionality. And cardiac what is this we have basically all the examples we showed you in a whole lot more available they're also pasted in the chat right right so we are constantly updating the open source project with more and more applications. So internal teams are building and outside folks are also continuing to build and add more and more. So we have already built quite a few to start with legacy kind of, you know, if you call her legacy today, using cloud distribution that is there using map are, you know Kafka it's it's it could be a huge pain to write an operator for something like Kafka right. And we we have tried to solve that by having a computer application, which takes care of Kafka. We have quite a few machine learning kind of application like TensorFlow spark is another very popular one which can be used in the machine learning areas as well as for compute and many more and this will continue to add more and more here. I want to point out, similar to how, you know, blue data was acquired by HP, we've also acquired what is very popular in the machine learning from the data's perspective map bar, which is why I see map R 610 that is rebranded as the Esmeral data fabric, and it's integrated into the HP container platform as well. So that completes our presentation of all of our data. We've got our Twitter handles here so you guys can bother us please bother us as much as you like we'd love to you know, we love this stuff where the nerds. We have a slack channel, you can reach us on email, the blog post is also posted there in the chat, and there was a question also about, you know, when can you get this actual presentation and in Julius could even answer that when that will be available. But, you know, Tom take us back to the beginning here and wrap it up. Sure. Thanks Don so what we remember when we spoke about in the very beginning is the difference between stateful and stateless applications. What we've demonstrated today is with TensorFlow and the Jupyter notebooks, you can use cube director without having to write your own operator for TensorFlow or Jupyter. So, you know, you can use the Jupyter by itself, you know, passing the animal files as we provide here is able to deploy and manage those applications doesn't have to be TensorFlow it could be spark could be something else is as a cartoon pointed out, we're adding some examples of the animal files but we'd love to have other people jump in and provide those animals showing how you can run other stateful applications with cuba with cube director on kubernetes. That'll help us to demonstrate more usefulness of this open source project not only for pipeline deployment from machine learning, but for all types of applications. And we've been trying to keep up with some of the questions please go ahead and type them in right now to the chat, or the Q&A, I'm not seeing a Q&A pop up. Julius you can take over on Q&A or. Yeah, so everybody feel free to ask your questions down at the bottom right of your screen in the Q&A tab. At the bottom, the recorders right up the screen. So we've already got one from Steven. How does this relate to interact with cube flow in the concept of ML ops as this will be also available in Esmeral CP. Anyone to answer that. Yes. So yeah, since you mentioned Esmeral CP, I can briefly answer that but cube director is more of a, you know, open source project in itself. So it's, it's pretty extendable in terms of who do you want it to use it along with, but specifically in ECP, we have plans in coming releases to tie it nicely with cube flow where you do that application can be for, you know, your starting point where where you are building your application coming up with a pipeline. Then you want to take it to next level where cube flow already has richer components in terms of hyper parameter tuning is in cutting more kind of workflows using our goal. You can utilize that and how to bridge them together is first you need a common storage. We're trying to solve that problem because cube flow solves the problem of storage slightly differently where every user has its own kind of persistent volume, which is not the case in cube director. So in ECP specifically we will try to solve in terms of, you know, how to get their user depending on what tenant they belong to can get the tenant storage. So if they have access to the common storage and they get serialized model, then you can start probably if you train the model in cube director you can deploy it using seldom or KF serving on cube flow side. And that's kind of a nice, nice bridging. So those kinds of things we are already working on, you should see some of them released in future releases. Thank you, Carl. Let me just get a couple of things here. So just for the audience's sake, when we say ECP, that stands for Esmeral container platform. So it's for full disclosure again, Esmeral container platform is an HPE providing product. It deploys and manages your applications on Kubernetes. What we presented today is an open source solution called cube director that does work on the Esmeral container platform from Hewlett Packard Enterprise. However, you can also deploy cube director on any open source Kubernetes system. So what we're showing is a general usage of that. And then there's a great question. So what's your plans? How are you going to integrate with with cube flow? Are you planning to replace cube flow? The answer is no. Cube flow is a wonderful tool. Okay, we are going to augment cube director so that together these two tools provide the additional functionality as Karthik pointed out. So in Julius, I don't know if you saw this other one that came through in the chat. Okay, go for the Spark question. Oh, in the chat, let's see. Yeah, I can get it. Is there a difference between using cube director to manage Spark and the Spark operator? Yeah, that's a good question. And just now Tom mentioned ECP, we also have Spark operator. But fundamentally, the difference is Spark operator is kind of more native to Kubernetes. In the operator, we are not trying to say here that, you know, this is one size fits all like this can solve all kind of problem that all the operators are solving individually. No, this is more like a generic, you know, for if this does not serve your use case, then you evaluate. Can you make use of this? Or do you have to write your own operator? So a Spark consumer, if they want resource manager to be native Kubernetes, then they should use operator. But the application that we have will have some resource manager as part of the virtual cluster, which could be yarn or which could be Spark standalone. Right, because cube director is just launching given for a given role parts, but it more intelligent resourcing, it leaves to a resource manager, and it relies on that. So that's where a specific operator like Spark operator is kind of will be ahead of a cube director Spark application. Does it answer the question? Yeah, that one came in from from rock. So if he has a follow up, you still have a few minutes. Anybody has any questions and another question, what is what are the advantages of cube director with network service mesh in providing connectivity among clusters. Tom you want to take that. I'm not entirely sure I understand the question. Okay, this the service mesh is a way for different applications to find out about each other, and to connect. Okay. I wouldn't say that cube director has an advantage over network service mesh. It would use that so when we deploy the inference cluster we deploy the training cluster it would register itself with the service mesh. And then the pipeline would be assembled by querying the service mesh to get the endpoints for the components of the pipeline. Right, and just to clarify the connection that you get a feature is not doing anything on the network layer. It's just basically it's giving the config metadata of different cluster to a given cluster. When you're talking about more like a service mesh like Istio kind of thing so yeah it's definitely a very different concept from that. What we can do is using cube director application can utilize something like a service mesh like Istio like you already does, and we have been talking about that. So they will be complimentary and not competing for sure. Great. Well I hope that answered your question if not please feel free to ask a follow up. And yeah if there are any more questions please ask away down at the Q&A tab. I got one for Karthik. How do I get one of those shirts? Oh these shirts? Yeah where'd you get that? I think we just, it used to be in the view data office. There used to be tons of those. I think for one of the event we came up with these and then Well we own that then so we should just rebrand them. I think we just got rid of that building. Yeah I mean we own .ml. We got to have more t-shirts that's it. I think it's a standard shwag for RASMIL container platform. Please you know next time we have a face-to-face conference and we're giving out t-shirts again. Come by we'll be happy to discuss and give out t-shirts. Absolutely. Okay well if there's no more questions we can go ahead and wrap up but feel free to keep asking away. So I want to thank Tom, Karthik and Don for the great presentation and for the Q&A. And we at the CNCF will have the slides up later today on the webinar page cncf.com slash webinars. And it looks like we have a question that just came in. Yeah. Is config CLI similar? Oh no you answered that. I think I answered that. Oh there we go. Could you please give a brief explanation about cube director and cube flow and their difference? Right. Right so cube director is that's a great question actually since we are talking about machine learning pipeline. Cube operator is more of a genetic operator and it's not very specific to you know any particular stream like machine learning. It basically lets you build any kind of application. For this presentation we have utilized cube director to build an end to end machine learning pipeline. Cube flow is an operator in itself which lets you build these pipelines and gives you various components right. It's a specific technology and for any technology you can build an operator in Kubernetes world and that's what cube flow is. Cube director might have some overlap but essentially it's very different. You can, cube director lets you build your own application without writing any go code. Cube flow is an operator in itself to extend it. You have to write go code or to add more components to cube flow operator. You have to bring in new operators in itself. While cube director is an operator where you don't have to write new operators but new CRs which is a cube director application for every new application. Great. Well thank you guys for a great presentation. The webinar will be up later today on the CMCF webinar page and I'd like to thank everybody for attending. Have a great day everybody. Thank you. Thank you. Thank you.


So hi, I am Jixir. I'm from India. I belong to Punjabi Wikimedia user group. And I just want to share with you about my project that I completed with my community. It is called audio book project. So in audio books, what we do, the idea is to create books using the audio books content, using the Wikisource content. So we take books from Wikisource and create audio them out of them, why I will share in the next slides. So the first of all, I want to share what is the program project objectives. It is first is the accessibility. We want to increase the access of Punjabi literature. As we know that in this era, we, most of the people, they don't want to read, but listening is easy for them because they can listen whenever, while they are working out, while they are doing any, any work, but reading takes some time. And also it takes, it becomes another activity for people. So with the audiobooks, it helps our literature to reach to more people. Second one is preservation, because we are creating the digital content in form of the audiobooks. Second is diversity. What we have seen in our community that most of people, they want to join, be part of Wikipedia, but they don't want to make any edits. They don't want to prove read books. So, but they have some, some of people, they have expertise in special form, special fields. Like with this project, we got some, we got some people from theater group. So they have, they have quality to use their voice better than the like normal people. So with this project, we are also creating diversity in, in our user group because more of, more, more people are coming to our user group. The importance, importance is accessibility. First of all, because as I already told that reading in this area, most of people don't like reading, but they can listen. As we know that audiobook industry is growing very fast. So we can also be part of this industry using this projects. Second one is that its importance is that in, in our, one of my friend, he has the some difficulty in reading. Like they have, he, he, he has, his eyesight is not good. So for, for that, what we used to do in college, we used to record our lessons and, and he used to listen from that. So somehow he got past with this technique. And that's why we are also thinking that some, there are some people who are, who are not good in reading because of their eyesight problem, but they can consume literature with this, these kind of projects. It is also convenient because as I already told that reading, reading is a, a, another task. It is a, I would not say challenge, but it takes your time. But listening will, listening is convenient, convenient for most of the people learning, because learning is, because in this project, we also provided training to our community. A professional radio jockey has provided training that how you can use your voice to record audio. So it is also learning and culture preservation is a big factor because you can now, if with this, with the help of this project, you can preserve your literature for the long term. Next one is a content source. We take content from wiki source books that are already on wiki source. So we don't have to be very worried about the license issue or anything. And another is that the literature that is already available in wiki source, that gets an another form, which is audio form. And another thing is that we ask people, people like from a community that what, what book do you think that we should create audio book? So people can suggest what kind of books are like in trend or what is what, what books are important for the community. So this is the process that first is, first we select books, then the completion of books, like we have to prove, read it, we have to, what is that? Yeah, that the transclusion thing and all of the things we have to complete because for the, with the help of this project, we have to create a book totally complete. Like the last point is the transclusion, we have to translate that book and also providing voice of training. As I already told that we, we provide a voice of training to participants who wants to create audio books. And also another one skill is also developed that of recording and editing. So whenever someone record any audio, so it, it will not happen that he or she can create in a single take. It, it, there are very fumble when we record audio. So with the help of, of this project, someone can also learn how to edit audios and then upload, we upload it on comments and then we connect it with the relevant wiki source, wiki source item. So we also developed another use case of comments because most of the time we think that wiki sources only, wiki sources only wiki, wiki comments is all only for videos or photos. But with the help of these kinds of projects, we can also use comments in another, in another terms like audio books. So this is a contact information. You can, if you want to have any question or if you want to know more about it, you can always contact me. Yeah. Thank you. Yes, please. Yeah. So audience for sharing your project. And I just wanted to know that what kind of audience are interested in your project? Like I can see that this project is maybe very fascinating for the school students, as well as I see that senior citizens, they have a spare time, they can also get engaged in this project. So if you have any experience you want to share about your audience, it would be great. Thank you. Thank you for this question. So for the consumer perspective, our audience is those who, who are like quite busy or who don't find time in reading stuff. So because they have to, they need separate time for reading books, but they can use their headphone to whenever they are traveling or working out or doing anything. So first off, the audience are our audience are who are busy in terms of consumption, they consume content. And when we talk about creating content, we target those people who, who wants to join Wikipedia or Wiki movement, but they are not interested in creating articles or proofreading books. So because with this project, we got three or four newbies because this is our pilot project. But in spite of that, we created 10 audiobooks. So our those people like who are in theater or who want to, who want to go for these kinds of skill, like in the radios or these kinds of skill, they joined, they joined us because they want to explore things, they want to get training. So in terms of consumer, our audience is people who are, who are unable to like who, who finds feel difficulty in seeing who had less time to consume content. And when we talk about creating content, we, we, we, this project, it is specialty of project that it, it create diversity in our community because more of people, more fields of people are coming into the community. Thank you. If you have, because we are running out of time, if you have any questions, you can find me here and you can, I will try to address your question. Thank you. This is Jaxeer from Punjabi Wiki community from India.


Welcome to Geneva, Switzerland, and the World Summit for the Information Society Forum 2013. This year the forum has brought together some 1,500 crucial participants. To answer one question, how can we best use ICT, information communication technology, the internet, mobile phones, to improve the lives of billions of people across the developing world? There is a very strong bridge and linkage between the development of ICTs, the access of everybody to access ICT, and the fundamental rights that each person has as a simple citizen of a country. We've seen that ICTs can really play a major role in helping to empower people, whether they be women, organizations, individuals, companies, to really optimize the resources and to reach out to a market that they could normally not reach. The international community has already set itself important targets, development goals like ending poverty or reducing childhood debt, getting children into school. Many believe that by using information and communication technologies you can increase your chances of meeting these goals. It has to do with access to different services, access to information that means different rights that the person has the right to access to information, to express themselves. The internet is a wonderful tool for sharing and collaboration. It's why you can't really talk about its future, or the future of ICTs, without talking to those most affected by it. These technologies are really to serve people, to make lives better for people, and it needs to be something which is developed in coordination with the participation of the people who it's being developed for. Multistakeholder approach means it's not exclusive to any two particular parties, it's not governments or civil society because there are other groups. Everybody in an equal footing has to sit around the table because this is an issue that has been raised, that is here, it's present and it's going to increase in the future. To help drive the process forward a number of action lines have been developed. They're like a shopping list with what needs to be done and who needs to do it. They include issues like putting infrastructure in place, giving people access to information and teaching people the skills for what to do with that information. For those people who don't know how to read and write, they're really at a major disadvantage when it comes out to developing these technologies. They really need skills development, they need education.


Last time, we talked about how the jQuery dollar function helps you find elements. The dollar function does not return DOM elements themselves though, but rather a wrapper that augments the element with many useful helper APIs that jQuery provides. For example, there are add class, remove class, and toggle class. And they do exactly what you think they do. They add remove or toggle CSS classes on an element. This feature is now present on the DOM directly on the class list property. This feature is sufficiently supported all the way back to IE 10. Handy! See, jQuery really did a lot for the OpenWare platform and we have some more episodes lined up on this topic, so if you find this interesting, you should subscribe. Previously, we talked about Query Selector, so why not watch that one in the meantime?


Everyone believes are good Everybody right this side that side.  It's just a fact. That's it Just take it out.   It's like I hear you I feel that it's like one of my favorite thinkers is or was Krishna Murthy. Who's that?  They stopped like what Jordan Peterson talks about it's like At the like he has he has he has very interesting comments Somebody asked him in the crowd is like well, what do you think about homosexuality is like, what am I supposed to think? What's there to even think about? It's like, okay It's something it's a yeah, there's nothing to think right It's like same thing with heterosexuality. What is there to think about? What am I thinking? This is just you're doing what you're doing. There's no there's no digging into it There's no like oh, well, I'm gonna put a label. It is what it is. That's that's what it is Well, you know people try to label things too much like everything's a label.  I like that. All right. It's like I'm only this box Right. I'm only this and nothing else. Right. Right. Right.  That's interesting. You know when I started this I'm out of way to the third guest. Oh, right on this. You know the new mirror proof show and that's right, brother Like oh, you're gonna do just crypto.  You think that's what I care about Right, I gotta do whatever the hell I want to do whenever I want to do it. How I want to do it I think people like have a There's two things with labels, you know, we're going off subject here, but Labels give people empowerment and it's because people respect labels. They don't respect people like when you go to When you go to court and you're looking at the magistrate or the judge, you're not respecting the person Respecting the judge the crown the label. Yeah, that's the myth not the person You know, I think Michelle Falcon Esquire you cover the Esquire part. All right, or a doctor We respect you just wrecking the title doctor Or all people say I'm an entrepreneur like that's your identity only.  He's like, that's all we had That's our only option we had back in the day. Mm-hmm.  Like if I didn't work for myself, you know what I'd have nothing on the table, right?


10 common English phrasal verbs with come from espressoenglish.net Number one, come across, means to find something by accident. For example, when I was cleaning my room, I came across my middle school diaries. Number two, come along, means to accompany someone when going somewhere. For example, we're going to get ice cream. Want to come along? Number three, come back, means return. For example, he's still hoping his ex-girlfriend will come back to him even after all these years. Number four, come off, when something becomes separated or unstuck from another thing. For example, the paint is starting to come off the wall in the kitchen. Number five, come on.  For example, I don't want to dance, I'm no good at it, everyone will laugh at me. Oh come on, nobody here cares whether or not you can dance. Number six, come out, means appear or leave the inside of a place. For example, it's cloudy right now, but the sun should come out later. My little brother is hiding under the covers and doesn't want to come out. Number seven, come over, means come to someone's house. For example, if you come over tomorrow after school, I'll help you with your homework. Number eight, come through, means produce or deliver a result. For example, I thought my favorite basketball team would lose the game, but the offense came through and scored 15 points in the last five minutes. Number nine, come up, means appear, often used for when a task or responsibility appears unexpectedly or when a topic appears in a discussion. For example, I'm sorry I missed your birthday party, something came up at the last minute and I couldn't go. I thought someone would mention the policy change, but it didn't come up during the meeting. Number 10, come up with, means create or invent something. For example, every time I ask him to do something, he always comes up with a list of excuses for why he can't do it. Do you want to learn phrasal verbs the natural way? Check out the phrasal verbs in conversation course at espressoenglish.net. It will help you learn phrasal verbs easily and naturally in the context of everyday spoken English. Visit espressoenglish.net and check out the phrasal verbs in conversation course.


My name is Roy and we'll be talking about edge computing and how this edge computing is being used with open stack cloud to host multiple applications. Over here I have just given an example of IoT. But you can host multiple applications like IoT applications, 5G enabled applications, AR, VR applications, any kind of applications. Yeah, so I'll be collaborating with Nilesh, these are very very short bio, that is we are open stack engineers. So this is what we have in our plate today. Those who are not aware about what is exactly edge computing and those are aware about cloud computing. So for them it's just a quick intro to edge computing and distributed computing network with open stack, then a spinelift topology. It's a network topology and a director based deployment method. How will be deploying the exact, the open stack, then how to scale your edge deployment. That is basically your open stack cloud, then potential failures, limitations and at the end we have very interesting demo for edge computing. So stay tuned. Yeah, so you guys have heard about exactly what is about cloud computing, right? So what is a cloud?   But what exactly is edge computing? Any guesses? Okay. Yeah. So edge is nothing but whenever we have some kind of production servers deployed and it's kind of difficult to manage production servers at different remote locations from a centralized location. At that time this kind of concept is useful. So this edge computing is nothing but a distributed computing environment where we are managing this environment using open stack cloud. Okay. And then we can use this environment for hosting as I said different kind of applications like IoT, VR, AR kind of applications. Okay. So DCN with open stack, DCN nothing but distributed computing network. So if you see over here, this is a block diagram which shows the block diagram of open stack. So over here, the upper part is if you can see the first is under cloud, then we have container registry, controller nodes, compute nodes and volume. So this is nothing, the first block is nothing but your open stack environment. Okay. So forget about this part. This is our exactly edge nodes that is edge computing. So first I'll just focus on the upper part. So if you guys are aware about how exactly open stack architecture is. Open stack has its under cloud node, over cloud node, then the storage node. And on the over cloud node you host your VMs and then on that VMs you host your application. So if you see we have the under cloud and we have container registry for storing the images and we have controller nodes, compute nodes and volume. So the compute nodes will be using the local fMirror storage or any kind of storage which we are having. You can use that storage. And then comes our edge site that is the DCN site. So in between we have L3 routing. So L3 routing is nothing but your MPLS network where you have your, what you can say, L3 layer of devices, switches, routers and that switches router are connecting to our compute nodes which resides at remote locations. So if you see in this diagram, I have my open stack environment upside and this open stack environment is connected to my edge nodes. Compute 1, compute 2 and compute 3. So these are my edge nodes. So talking about the topology. There are multiple different topology in network like star, hub, ring, mesh. So what kind of topology is useful in this scenario for hosting our edge computing. So if you see I have a spine switches at the top. We have three spine switches. So I was talking about L3 routing in the previous slide. So L3 routing stands over there. So these are spine switches under the spine switches. So consider these three columns as a single server rack. So this is the one rack, another rack is the third one rack. So each rack I have multiple nodes under cloud controller, controller 1, controller 2, and rest of the nodes. So each rack has similar kind of nodes. So this is how exactly spine lift topology works. I have the main spine switch. Main spine switch is connected to the switch which is located in the rack and the switch connects to all this compute controller and under cloud nodes. So if you are aware about how exactly open stack deployment works. So there are multiple deployment methods for installing or setting up this open stack. So we are considering over here the director based deployment method. So director based deployment method is nothing but we are using some sort of YAML files. So YAML files are nothing but it's a kind of what things you need to deploy or what kind of network you want to have, what kind of services you need to have in your open stack environment. So these are nothing but the YAML files. So using this YAML file we are making this director based deployment. So initially in the first slides I said open stack has two parts that is the under cloud and over cloud. So considering this edge scenario what are the things we need to make change in our under cloud node. So this is a snippet of a JSON file. So as I said there are multiple nodes in open stack environment. I need to define parameter for those nodes that those nodes should be visible to my open stack cloud. So this is a JSON file where I need to mention those parameters. So I mentioned just info about one of the nodes. So I mentioned MAC address, the name of that node, number of CPU, memory it is, the physical machine type, username, password address. The last important thing is deploy interface direct. So this is the only change which I need to make in my under cloud in order to make this environment work. This is the first thing and the second thing is Swift URL. So Swift is nothing but object storage in open stack. So this object storage is used to store some kind of images, some sort of data and it works on the under cloud. So once, if I want to just transfer the data from my edge nodes to the original central site. So this will be used, this will be done by using Swift URL configuration. So that was about under cloud. Then what about over cloud nodes? So over cloud we can have multiple edge nodes. So this is just an example or snippet of one of the edge nodes. So there is a default role file for each of the nodes. So if you see the location, there is user, share, open stack, triple low heat templates, role and compute.yaml file. So this, what this exactly yaml file do? So this yaml file has all kind of definition regarding the edge nodes. All kind of information, what things I need to have for that edge node. So all this information is present in this file. So likewise you can have multiple search files and just put it as a parameter while deploying your open stack cloud. So I will just read out what are the things over here. So this is role, compute, az1. So az is nothing but a kind of a zone, zone one. Then the name of the compute node and the description if you want you can put some basic compute node role. Then the count, so right now I have only single nodes, so this account is the one. And the kind of networks which you have, which will be using internal API networks. So internal API network will be used for communicating your compute nodes with the controller nodes, then tenant network, then the storage network. Then you will be having your host name, then role parameter defaults, then tune the profile virtual loads and display upgrade deployment. So these are the kind of optional parameters. So as I said, this specific edge computing is being used by telecommunication companies for hosting their applications. So if you take an example of any telecommunication companies, they are not working in a single country. They are working in multiple, all over the region, all over the globe. So how they exactly communicate with the central one. So if you see over here, I will be deploying my cloud at the central side. This is OpenStack cloud. My OpenStack cloud is the director node, controller node. And we can have controller, compute as well as storage node. So this is my central side where my OpenStack environment is hosted. And these three are my edge nodes. So my edge nodes at the center is any kind of application, any kind of operating system. And these two are connected via my MPLS network, that is the back hall network, where my physical router switches, all those kind of devices will be present. And this is a part of application where we can host any kind of application on your edge nodes. Coming to the scaling, let's say my business grows and I need some more resources, some more servers to put at my edge side. So how exactly the scaling of this edge computing works. So here we are scaling the compute nodes one by one or in group or in batches. The scalability of compute node is limited by what the under cloud can manage. It's all dependent on resources. Exactly.  So your under cloud should be capable of managing all your edge devices. So as per my knowledge, till now 150 physical edge devices has been tested successfully in the environment, production environment. And yeah, so whenever you'll be doing scaling, it's a kind of, you know, iterative job. So it's better to just scale in batches or one by one so that in case some failure happened, it should not disturb your entire environment. So this is how exactly scaling works with the compute nodes. Yeah. So planning about the potential failures. Let's say I'm deploying this edge computing environment. So how should I plan to deal with the failures in my environment? Okay. So regarding the controller nodes failure. So this is a kind of HA high availability management. So I'll be having some three controller nodes. So in case any one of the controller nodes gets failed, the other two can manage the load. And there's no need to worry if the controller nodes gets failed and compute nodes. Yeah. There is need to worry because my application will be hosted on the compute nodes. If any one of the compute nodes gets down, I need to worry. And the storage nodes. So storage nodes has, you can consider any, the local storage or some external storage as well. This is a kind of, you know, important things which we need to consider while handling the potential failures. And limitations. This edge computing being a kind of new technology or being used with this open stack cloud for the first time. There are some sort of limitations or drawback we can say. So the very first thing is can deploy only compute nodes as the edge side. So if you remember the very second slide, I have mentioned three edge nodes, three compute nodes. So I cannot have controller node or director node or storage node at my edge side. I can only have compute nodes as my edge side. And then network latency. Whenever you are hosting your application on the compute nodes, the network latency should not be more than 100 milliseconds. The network dropouts and site specific network. Yeah. So for the edge nodes, the network should be same. It should not be different. Yeah. So we'll just see the demo. Good afternoon, guys. Thanks, Rohit. My friend Rohit just talked about the theoretical part. I will focus on the practical part, how we can deploy it. And at the end, how you can deploy your IoT application or any edge application onto the environment. So this is demo regards to the open stack edge computing using the DCN technology that is distributed computing networks or nodes. When I said distributing compute nodes, it means that my compute nodes are located onto the remote side. And onto the remote side, there is no controller or no under cloud nodes. You can see that in the central side, I have under cloud controller and compute. However, onto the remote side, there is only one compute node. So my cost is saving. I don't have to set up another open stack environment onto the edge side. Only the processing of the application which will carry by the open compute node. And this point will manage the L3 routing between the two different networks. So that is actually the basic and the minimum configuration for the open stack edge setup using the distributed computing networks. So the next part is the setting up the over cloud nodes, how I can deploy it. So once my under cloud is ready onto my under cloud, I have to mention two important things that is the subnets. So as I am using only two subnets, central side and the remote side. So I have just mentioned lift zero and lift one. If I have multiple subnets or multiple remote sites, then I have to edit all that subnets over there. For the lift zero, I am using 24.0 sider. However, onto the lift one side, I am using 34.0 sider. So two different networks. So definitely I need to have a L3 routing between two different networks. That's why we are using the spine for L3 routing between the two different networks. Plus the important point is that whenever we are trying to set up a DCN or edge computing, we should have a DSCP relay between these two networks so that whenever the remote compute nodes want to set up a networking between the central and the remote side, the central side should pass the network details to the remote side. So by default, the nodes works onto the control plane network. So you can see that here the physical network of each device is set by default set to the control plane network. So as my remote server having the different subnets, so I need to change that different subnet. The physical network is changed to the lift one. The reason is because of the different different sider subnet, 24.0 sider network and the 34.0. So once my undercloud is set up, it's part to deploy to the overcloud nodes and that is my template files which I am using to deploy the overcloud nodes. Important is network files, role files and so on. Let's deploy it. So this particular topology and setting on KAMU emulator, it is not a KVM livered layer. So I am not able to manage the power cycle automatically. So for that matter, I have written a small python script. This is python script. This script will automatically manage the power of my compute nodes or my nodes which are getting involved into the deployment that will automatically turn on the machine, turn off the machine, automatically pushes the configuration. So that while running that script, it will also ask me to pass the absolute path of the template file where I am storing my templates. So once I ran the script, it asked me to pass the absolute path of my deploy script. The script is running. It's trying to import the node. You can see that in the bottom, this side, the nodes are imported. It's starting the VMs. You can see that the VMs are not it started, but it will start. Still the nodes are introspecting. Now you can see that the power status has been changed from off to on and then you can see that the machines are on. The machine's color has been changed. That is the console. The introspection is going on. What is basically doing is so whatever we have mentioned in the templates, it's collecting that data. It's storing into the under cloud and once it is ready, it will push that configuration on to the central nodes as well as on to the remote nodes. Whatever the nodes are involved into the deployment, all gets automatically deployed by the script. Still it is introspecting and now you can see that the power status has been changed to the off. It means that the operating system gets installed on to the nodes and after some time it's automatically off. It's still introspecting. Introspection is completed and the console has been gone. The introspection is completed and now it is waiting for the next call. There are different different calls involved during the deployment. Once the nodes provision states is available, the next call is waiting on call and once the script finds it out that the provisioning state has been changed, it will again automatically starts the node and it will push the next configuration. Now you can see in the bottom the stack creation is in the progress state. So whenever we run the open stack deployment in the backend, it will create this stack. It will combine all the configuration and push that configuration on all the nodes into the sidebar. You can see that the progress what it actually doing. So before this step one, what it will do, it will collect all the information about the networks. The first part is to collect the networks detail. Once it has all the network details, it will push that network details on to the overcloud nodes, controller, computes and the storage nodes. At this moment, my nodes are still in the off state. It's not power on state because it is waiting for the callback. Now it will start once it gets the wait on callback signal. You can see that the power state and the provisioning state is on and wait call. It will move to the active state once it pushes all the deployments to the overcloud nodes. Now it's deploying the rest of the configuration what it collected before the step one. Now after the deploying, the nodes will again turn off. It's going off and the provisioning state changed to the active state. Now at this moment, the open state deployment just collected the information what we passed into the template files but it's not been completed. So there are total five steps to complete the configuration. So at the very first step, it will collect all the network detail, software detail, deployment detail, what networks I have to deploy on to my overcloud nodes. For example, on to the control node, I want only selected in networks. However, on to my compute nodes, I want two, three networks. Let's say on to the controller side, I want external connectivity but on to the compute side, I don't want external connectivity. So I will create my templates according to that. Now you can see that we are on to the step three. As I said, there are total five steps. And to the step three, what it will do, it will basically do the pacemaker configuration. So the pacemaker is another feature inside the open stack that will automatically manage your resources. We are on to the step three. Yes, we are now on to the step five. It's basically at the step five, it's basically verify your deployment, whether the previous steps successfully executed or not. And at last we can see that the overcloud is deployed in 82 minutes. So once the once the open stack is deployed, what we will use to do is we used to create the VMs so that the end customer or the user can deploy their application. So the next part is I am deploying three VMs. The one VM is on age site on to the when I say age site, it means that my remote site. And I will deploy two VMs on to the central site and we'll see how we can access that application. So you can see that here I have compute leaf one that is my remote remote compute node where the name of the VM is rd underscore age and the status is active that VM is running on to my remote location compute node. And I have another VM that is rd central, which is on compute leaf zero that is on my central site and the name of the VM is rd underscore central and the status is active. That means I have right now I have two VMs on central and remote site with the name of rd age on age site and rd central on central site. And the another VM is web server for simplification of easily easily go around to the different different sites to access my or we can say that to easily navigate to the different different application. So three VMs are currently running. And as I say that I have another web server for easily navigation to the each application so that I don't have to go to the each site and check and then I have to access the URL for the application. So I have contributed all the URLs in one single page so that I can easily navigate at the very first page. I can go to my dashboard and I can check my VM details my hypervisor details I can access anything from the dashboard. So there are two ways to access the open stack environment one is basically three ways you can access via horizon dashboard CLI and using API as well. So these two VMs are currently running that is rd underscore age and rd underscore central and the web server which is hosted on to the central site and as well as on to my remote site. Okay, so we talked more about just the deployment and we were talking about the IoT how we can deploy the application so just my friend says that is just not about the IoT. It can be a telco application as well if it can be a broadband application as well. It can be a non telco applications as well medical applications, educational applications, it can be any application. So here as a IoT application we are using a radius desk that what what this application will do is it will allow the users to easily access the internet from the mobile devices. So we have deployed two applications one is on central side and one is on remote side. So you can see here the port detail is one zero one five five one five five is the IP of my central server. And once the next slide is coming video is coming it will be replaced with the one five eight one five eight is my remote remote server remote computer node where the application is running. So here I tested my username whether it is authenticating or not. Yes, it is authentic authenticated so that I can access that application or from the users from that region can access the application. You can see that the the port is changed sorry not this one this one the port is being changed to one five eight it is one five five one five five is central and one five eight is remote. And the username is of course the username is different for the remote sites cause that application will be locally to the remote users. We can test the application from the CLI as well the central site is one five five one five five and the remote is one five eight. I'm sending the API request to check whether that application is really working or not. So I'm sending just API command. Yes, I'm getting the access accept received access at accept acknowledgement that means the application is well working on to the central site. Let's see on to the remote site. And yes, we are getting the success message that means that the application is also working on to the remote site. So yes, that's all about the deploying your IOT application on to the open stack each site and on to the remote site. Thank you guys. Do you have any questions please feel free to ask. So as my question is what happened if my L3 connectivity is lost to my age notes. So the answer is like, of course, if you are deploying your open stack environment on to the age site, at least there should be some failure link so that the traffic can be easily moved from one link to the another link. For example, if in a data center, we usually see that there are two links or multiple links into the data center so that the redundancy should be there. If one goes down, the other link can be takeover, but it does not hamper the application which are hosted actually on to the compute node. So of course, there should be a routing between the two different networks which is easily configured. Yes. So do you think we are going to see the open stack requirements in private? Thank you. Sorry? Sorry. So my question is, in your opinion, this one you showed here, would it be see open stack requirements in private? Yes. Yes. So the question is, do we see any age deployment? So if I were to directly, this presentation is about the open stack at the far edge of this. Yes. I really want to try to delete this. How does this compete with any other metal? Well, not sure about the Kubernetes open shift, but yes, for the telco applications. This definitely is going to help. And yes, the customers are still deploying their application on to the age side. This application has been tested only for some kind of telco customers. Some VRAM devices like which telco customer uses. For Kubernetes and all those kind of thing, the testing is still in kind of progress state and we are still developing and testing those kinds of things. So the reason is, basically, if we are talking about Kubernetes and the open shift, the RAN application is not yet to be containerized. Once it is containerized, yes, there may be a chance we can deploy that CNF, the container application, on to the age side. But right now, if we don't see any containerized application, so no idea on it. But yes, from the open stack side, we have the VNF, that is the virtual network functions, that can be easily deployed on to the age side. So the question is, can we use the DVR? Yes, definitely we can use the DVR, that is, DVR is distributed virtual routing. But here is, we are actually provide, and it's also depend on the use case. So if I have a telco application, I will not use the DVR, because I am directly providing the provider networks to my compute node, so that there will be a direct access of the application. In case of DVR, maybe telco customers will not use that. But yes, you can definitely use that. It's up to the use case. Thank you. Thank you so much.