 Hello. Yeah. Good morning. How are you? I don't think we have a lot of people probably joining today because it's kind of close to the holidays. But in any case, the presentation is being recorded, so it will be uploaded. But just let's give it like maybe a few minutes to see some more people join and then maybe we'll get started. Cool. So are you in the east coast? I'm on the west coast. I'm in California. How about you? I'm in Bay Area. Oh, great. Awesome. Yeah, me too. Yeah, I'm asking because of the timing. The timing is a little bit earlier for west coast guys. Yeah, but we get audience from several places. So yeah, we do have a bunch also in the Bay Area too, but also people from other places. So we have a Lena just joined. Morning. Hello. Is everybody ready for the holiday? Yeah, yeah. I think I might not get that many people today because a lot of people are just kind of checked out, you know, for the holiday. Yeah, a lot of meetings have been canceled. Like we had a TOC meeting canceled on Tuesday and next week we're not having it either. Yeah. So I'm sure nothing's going to go up. Nothing's going to happen next week. Yeah. I guess the week after. And then it's 2021. Yeah. Yeah. That's wait a couple more minutes. We're gonna get started. Yeah, before the meeting starts, maybe Ricardo, you can briefly describe what this thing is about because I know a lot of six. Yeah. Yeah, so, you know, the sick notion, I think started with Kubernetes, right? They would all the different scopes of Kubernetes, like signal, the SIG network, SIG API machinery, I think. And then because the CNCF started to grow, I mean, the CNCF started with Kubernetes, right, but the CNCF started to grow and different projects started to join the foundation or started to be donated to the foundation. And then it was all cloud native but not related to just Kubernetes, so different areas like observability, application delivery, like CI, CD, continuous deployment, continuous integration, and also on the networking side like envoy proxy. So I think this, and then the CNCF has or had this structure with the TOC where they looked at these projects and they reviewed them and they decided whether they would be a good fit for the foundation and then with these stages like sandbox, you know, incubation and graduation. But I think what happened is that so many more projects started to get interested in joining the foundation and the TOC became kind of overwhelmed with all these different requests and and then the meetings were only like, I think, twice a month and so there wasn't enough room to provide to the community or provide time for the community to present and engage the projects. So they started these six, you know, with the different scopes, right, with networking, runtime, you know, CI, CD, and yeah, and this is where we are, right. And so we help out the TOC and engaging more the community with the different projects and so they can present and give a status on some of the projects. And some of these projects are not even part of the foundation. So they may join the foundation or they may be part of some other foundation, but we just want to engage the community. So there's more engagement and excitement about all the cloud native space. Yeah, sure, sure. So I'm guessing, but other people may ask, so what's the difference between this thing and the colonnades is sick. Yeah, yeah, yeah. And I think there's a ticket open from, I think Liz, she's a TOC chair and she opened a ticket on renaming some of the six. So it hasn't happened and something may happen next year because there's confusion about what between the naming, you know, this is called sick and the Kubernetes is also called sick. Right. So, so we might change the name. I don't know, sometime next year. Sure, sure. Okay. Yeah, we can get started. We got Quinton. Happy holidays. Thanks for joining. Yeah, we can get started. Okay, let me try to do this. I was on mute. My apologies. Yeah, I was saying good morning and apologies for not having seen you for so long. It's been a great year. How's everyone doing? Good, good. Are you in a boat or something? I am, I am. Nice. Can you see the screen? No, not yet there. Oh, I know what happened. I need to click this year. How about now? Yep, yep. You see this nice. Yeah, sure. Before we start, I actually just sorry I joined a couple of minutes late. I just wanted to check in. We have very few people here is basically the chairs and and the TOC representative. Do we, is this a general problem or is this because it's late in December or do we need to do anything about that? Yeah, I think it's one of the reasons it's late in the, in December, but we could use more audience to write during even November, I think it was, you know, generally like eight or people. Oh, okay. After, after coupon fatigue, a lot of people have checked out for, for a couple of weeks. Yeah, I can quite imagine. I was, I struggled personally to get in here, you know, the, the password is not in the invite and you had to kind of dig into the links in the thing to the notes to then find the password. So I wonder if there isn't a bit of friction there as well. That's, that's not hoping. Maybe, maybe we need to do a little bit of an outreach and just tidy everything up so it's easy for people to find us and join the meeting. I also don't know who exactly has us in their calendar. I had to work quite hard to get Amy to add, add it to my calendar wasn't even there for some time. Yeah. So yeah, it sounds like, yeah, something we can do more on next year to try to get more people. Right. So, yeah, that's great. Quinton, maybe we can actually have a meeting or something and kind of brainstorm on, you know, offline. Yeah, thanks. Good. That makes sense. Yeah. Cool. Okay. Now I, I'm going to get started. That was good. Yeah, sure. Good morning, everyone. Today I'm going to let me do this meeting to express the open yard, which we just joined the same group of people. Join the CNCF the sandbox project. This is the Today, I'm going to briefly describe what is open yard is about why we develop for this and what is the main functionality, what problem is solved and what may be the next direction of this project to the audience. So the Okay, this is the agenda of my today's talk. I'm going to first describe the background of the program a little bit because I guess many people already know about the edge computing Kubernetes, etc. And I'm particular particularly we are on describe some challenges of using a Kubernetes to manage edge use cases. Now I will describe the design and I talked about some use cases of the open yard in the real products, but not in many details, but just in high level. So, So, edge computing is kind of a new kind of computation paradigm compare with the cloud computing. Well, in the cloud computing everything. People put data workloads to the cloud and run a service in the cloud and gather results. But for the edge computing, it is kind of doing in opposite way in a sense that the actual computing happens in the edge side, regardless of the far edge or neo edge or just edge. There is a centralized place to collect the data and the due to orchestration. Can happens in the cloud, maybe, and that's the kind of a common way that people did all happens in the on-prem cloud in on-prem system but anyway, the idea is we run in general the workloads run in the edge and the workloads run kind of distributed algorithms. You can think about that like MapReduce, big data, AI algorithms. They take the algorithm taking the local data as an input. So then they send the results back to the center and the entire workload. Most likely we are going to be managed by the center. There are a few characteristics that are driving this model to the production and the people tends to use it because this model has a few advantages like they have low latency in terms of the response time of handling data because the network transformation delay is kind of reduced. They have lower bandwidth requirement in the public networks because many data analysis and the computation happens in the edge side. There are some kind of autonomy requirements in the sense that even if the cloud edge network connection is down, the application still can run in that provider service, which is pretty important in some like content library use cases. And the last one, last but not least, they have better security and privacy model because many data, some sensitive data does not have to be sent to the cloud, which can be a concern for many people. Going beyond that, there is a kind of new model is called cloud edge computing. Basically, this kind of cloud platform that unites the cloud edge nodes and IoT devices. So compare with edge computing. This is a direction of view from the providers perspective. Basically, there is a cloud which manages which run the centralized control plane. In the edge side, they have compute nodes that are closer to the device and data. And there is device layer which each points to all the remote devices that people can connect to and points to the remote environments. Those devices typically are the data generator and which provides the data and by all the applications running the edge. This is a kind of pretty interesting architecture or framework in terms of the edge computing nowadays. Briefly talk about the Kubernetes. It is the content or translation platform. The nice thing about Kubernetes is it has a nice abstraction of infrastructure layer with well-defined APIs. They can provide a unified user experience regardless of which environment they use, even in the private cloud or public cloud. This is a very powerful point of the Kubernetes. And after a few years of the world, I think Kubernetes has a pretty strong ecosystem. It has a lot of controllers, plugins, solutions to resolve all kinds of new cases applications. And I think one of the most important benefit of the Kubernetes is it is very highly extensible. The use of CRD makes the integration or the broader use of CRD make the people, make the ecosystem is very easy to be integrated in the other system or provide or extend its ability to create a business logic. So that's my reason, that's the reason why people start to all kinds of solutions based on Kubernetes to resolve all including the edge computing program. I think Kubernetes itself is kind of fits on the edge computing model because it is still a layered design. It has centralized control plane and the nodes and they are kind of layered design and it is a distributed system. So all the design like in them are using the kind of has to consider the case that it is running a distributed system, the reliability, they need to resolve all the kind of reliability issues. Entire the controller logic, the reconsider logic can tolerate in a transient failure because it has a retry logic and all the least watch mechanism which is used in most controllers and many plugins are designed to handle failures. And especially in edge face, the failure scenario, we need to handle more to the scenario or more problems in terms of the reliability, availability issues because there is an obvious, you know, differences compared with cloud computing is that the environment in the edges, the networking to the cloud to edge networking is not very reliable. So if you look at Kubernetes layer, so it kind of fits the edge computing layer and the nodes, the only differences, the nodes can be now presented or managed in the edge side instead of the cloud side. And the application running in the edge nodes can still, you know, manage and manipulate the devices and spread everywhere. So, yeah. So that's a reason we think, you know, Kubernetes naturally can fit the edge architecture, but for from where a high level. But indeed, we will have have some challenges if you really want to use community to in edge edge use cases. Now I'm going to describe some of the challenges that we have been found, we have been found and and some some on some of the points that we are going to address in the project. So, okay. Here are a few challenges in terms of the how to leverage how to use Kubernetes to manage it as you edge application. The first one is unreliable network. And there, there, it is kind of common in the edge, in the case that the cloudy edge networking is not very reliable. And in some, sometimes this network problem is not hardware problem sometimes can be a, you know, I don't mean, I don't mean straighter the decision because there are there are use cases that people kind of local I mean just trying to avoid, you know, public cloud networking and they just can cut off the network kind of activities for what a reason like to save the bill save the cost. So, so in a word that it is kind of, you should expect that sometimes the, the, the cloud and edge nodes, there was no connection. And sometimes this is not just a transgender part, it is not a transient problem it can takes for quite a long time. There was no cloud and edge node connection. And this is a problematic for the Kubernetes architecture because the node that the COVID running in a node is not a, it is a stateless but it has to relies on talk to the API server to get all objects status once it restarts, then we have a problem that if the node and the API server is not connected and then the node is the restart. All the previous running part cannot be recreated by the KubeLit because KubeLit just cannot simply get a states of the parts and all the get a spec of the parts. So that's one problem. And another thing is in the cloud side, we only have problem, we also has problem if the cloud and node there was no network connection because API server relies on the KubeLit to send the hobbits to indicate the health of the node. And there was no controller in the Kubernetes. If it doesn't receive, if API server doesn't receive the hobbits for sometimes like say a minute, now the node controller will think the node is offline and from apps perspective, node controller will start to indicate parts. This is another problem that people in the cloud side, we will find the part is getting deleted if there is no cloud and edge networking. The problem is kind of kind of a unique in the edge side. It is that the network connection may be okay, there is network connection but maybe it is one directional, unidirectional network basically it is okay. As that technique to allow the edge node to access the public cloud API server, but the reverse direction is not allowed because for all kinds of reasons because the edge node may stays in the internet. Then the problem is that if the cloud side cannot access node, some well known or some people, a lot of people relies on the KubeLit API is to retrieve log and use ESAC to do the debugging. This kind of functionality is broken if there is no network connection from the cloud to the edge. So that's another problem that we are going to face in the edge scenario. The third one is there is a need for pool well application management or what I mean pool here is you can think of it is like a region because it is kind of common that in edge use cases there are a bunch of nodes that are spread across different regions. The region can be a factory, it can be IDC, some independent IDC so the environment would be much more complicated compared to the centralized cloud provider cases. In those cases, if the application runs in different let's say regions, they may have different network setup, different network configuration and it would be nice and it is kind of required, we can have the ability to do the intra region management such that if the applications try to avoid running applications in same application replicas spread to different regions. And if there are there are services and they want to talk to each other and they should try to avoid making a cross region networks. So this is another kind of requirements. So in OpenYard we are trying to address these three problems maybe but there are also indeed there are also other problems which are currently not handled by OpenYard but it points to our future work. The obvious problem is the resource requirement. I think this was a big problem in a few years ago because I'm guessing you guys are pretty familiar with Kube edge and I think one of the main advantage of Kube edge is you can try to resolve the resource requirement problem. Because I think in a few years ago the edge note that running the entire software stack for the Kubernetes has limited resource in terms of the CPU and memory. But indeed the Kubernetes node components such as KubeLid, KubeProxy, even the CI consume not a huge amount of resource but it's kind of non-initiable kind of amount of resource to run those node components which can be a problem to run Kubernetes in edge. But in a yard we are not going to handle this problem at this moment. In the next couple of slides you will see in OpenYard we are trying to leverage all existing Kubernetes components. So we kind of have to realize on the Kubernetes community to do the cost reduction or all these node components. And the last one is the device management. So at this moment I don't think that we have a kind of, you know, especially in a Kubernetes side for the device management and there is no kind of standard model and abstraction. People used to just create their own CRDs to describe our device like KubeHDRs. This part is kind of pretty open area. OpenYard didn't handle it because we don't have a support in the node side to support the various IoT protocols like MQTT protocol. We don't do that. But it is indeed one of our future direction to support that. But we probably will do some other ways is that instead of create everything from scratch by our own or by the OpenYard community, maybe we can leverage some existing framework or infrastructure or system that open source the system that are primarily designed for managing IoT devices only. So we are thinking about doing that kind of integration in the future. Alright, so next I'm going to describe the height of the design of the entire OpenYard. So the basic idea is the primary design principle for the OpenYard is we are trying to extend the Kubernetes without increasing the modification to all the core components. So with this primary goal, then we can kind of achieve the second goal is that we are trying to have a solution that is fully compatible with upstream Kubernetes from an API perspective. But we are indeed trying to solve some problems like support some very typical edge characteristics like autonomy, cloud edge communication problem and some poor web management and want to support the heterogeneous computer in the edge side. And we want our solution to be, you know, Kubernetes native in a sense that we are trying to resolve everything by implementing the add-ons, plugins, and we will quite the entire OpenYard we are going to be keep up with the upstream release. So, so once the upstream, you know, release a new version, we will release a follow up release. Well, we see a couple of weeks that's that's our plan. Hopefully, and we have, we're trying to achieve the 100% API compatibility in the sense that everything, if you have a operator application, whatever YAML that works in the, you know, cloud based in a cluster, you should work in a YAML cluster without much, I think without any modification from the users perspective. That's our goal. All right. So, these three, these figures that kind of brief described the high level, the OpenYard architecture. So it has two parts. So it has cloud side components. It has edge side components. Edge side components are the other components running in the node. Cloud side controllers is kind of pretty typical. It is just a bunch of Kubernetes controllers, CRDs, and we have a tunnel, we have a tunnel server running in the cloud side. So that is pretty much the cloud, a bunch of controllers and add-ons. And then in the edge side, there are about, there are some components, which the most important one is the Yard Hub. So it's kind of, it is a proxy to proxy the traffic flow from the node side to the, to the, to the, to the, from the edge side to the API server. But the reverse direction is handled by a kind of tunnel service, which we call a tunnel. If you look at this figure, we have a tunnel server and a tunnel agent. So this tunnel system was, was invented to handle the traffic flow from the cloud side to the edge side. All the existing Kubernetes components like, you know, kubelet, kubelet proxy or flan or other existing add-ons, there was no change required on their side. The only change that they probably need to do is they need to point to the Yard Hub when it's kind of startup parameters instead of points to the API server directly. But that is all the configuration problems. Not exactly. There was no cold chain required. And we, can I, can I interrupt you just for one second? I have a question. Unfortunately, I have to drop off the call shortly to go to another meeting. Thank you for a, first of all, great presentation. This looks like a really interesting project. I couldn't help but notice that there's a lot of similarities with kube edge, of course. And I was just wondering, I understand, you know, the Huawei started the kube edge project and you guys compete almost directly with Huawei in many spaces. Other than that kind of concern, are there any reasons why you decided to build a separate system from kube edge rather than become a contributor to kube edge? Does this solve some problems that kube edge does not plan to solve or are there any technical reasons? Okay. I can answer that question. So for kube edge, I don't know if you guys are familiar with it. The biggest problem that I see is it changed the core kube it. So it kind of, they want to resolve the resource requirement problem that problem a few years ago. So their decision is to completely rewrite kube edge, get rid of a lot of things. And even they change the basic communication model between, that usually in the kube edges, like the least words, they use the WebSocket based communication channel. They create their own WebSocket channel to communicate it between the ad side and cloud side. Now the problem of changing kube edge is API compatibility. So that's a problem that we face. And some of our customer was asking they are hesitant of using the kube edge because they worry about API compatibility. And they get rid of it because they read a kube edge. Many kind of Kubernetes APIs, they cannot support it. So that may be okay a few years ago, but nowadays they have their own problems because of the API compatibility problems. They are trying to rewrite their, you know, node side components like their own, their own hub, kind of edge hub, they create an edge hub to bring back some of many of the kubelit functionality back on it. So that's, you know, you will see the problem there. So overall, I think the biggest difference is from high level is I believe they are going to have their own community because there are a lot of solutions tied on their current architecture and the way they make the things work there. It is okay because there are a lot of contributors there, there are a lot of users there, but they probably have their own community, but in our side, we are trying to leverage the Kubernetes community. So that's the reason we build this system. So if you look at it all the way that readers, the API compatibility is always our primary concern. So we are trying to make sure once the system is built. So Intel the applications that running the Kubernetes community can be running the system. So that's, that's a pretty much our goal. And as you can see, so because the kubi idea has been that way it is difficult to make them to convert to a plugin based solution. So, so that's the reason we are trying to think about how can we solve the problem without, you know, changing the core components. Okay, thank you. That answers my question very well. Thank you very much. Okay. I have a follow up question on that. So the, what are some of the implications of, like, not modifying the kubelet code or, or the changes that a kubi edge is doing for this project right so like, does that mean like performance wise, you might have some penalty or Okay, there's a few things I can make a curve. So because, first in the kubi edge I have to admit that it is much more complicated that our system because it provides more functionality they provide kind of the edge device management, which we didn't touch at this moment can simplify the problem. So there could be edge if you look at the entire, you know, architect there, I would say there were one third of the components are trying to handle the device. So the performance wise I don't think it is not in the data planes or the control plane kind of thing. So the performance is not that critical from my perspective. So, if you look at the way that we do, it's kind of the thing. Yeah, there's some performance loss because you are doing the proxy. There are some kind of performance loss but as I said is is control plan is you probably have some a little bit delay on, on, on get the logs of the part, maybe not not not noticeable at all. That is the thing that they can think of. Other than that I don't see, I don't see there is a performance issue there. The pre, the resource consumption that indeed can be a problem because kubi edge they are, they claim they are binary they put everything in a binary and the binary is kind of 50, and thousands of micabytes. But, but in my perspective, as long as you use Docker, the memory will be brought so it is Docker is not controlled by you. So, yeah, well, yeah, but completely. So our solutions may consume more resource on the edge node, that is for sure. But one trend that we will find out when we talk to a customer. Yes, the resource was a limitation a few years ago, as I said, but nowadays typically in the edge side, they are, they kind of have a moderate, you know, powerful machine to run this kind of components is kind of normal. It's not so the resources not very hard constraint for our primary use cases. Got it. Okay. Thanks. Sorry, this is Diana have a follow up question to this whole thing just curious that when you're comparing a kubi edge to open your is one of them designed more for being disconnected from the network for longer periods of time, or is it is that similar between the two. I think for that, in that aspect, they are similar because I will talk about the NASA couple slides but in general we are going to both, both will catch the cloud side states in the local. So, which means in both systems, if you have you don't have the cloud edge communication, the edge side is still can be wrong autonomously basically, once the asset restarts they can recover the pause that was running. And then like what how long can you be I was involved in something like this recently were an edge, but there was a problem with the edge systems that were had very poor internet connection. And I was just wondering how long are these use cases wanting that disconnected state to go on, like is is a day reasonable, or is that not reasonable. The day I think it's okay but as I said, sometimes the network connection problem is not part of a problem is intentional. We see some cases some companies, you know, network administrators just cut off the line because they said I don't want any public cloud. I only allows public connection connection by me, I only allowed a few minutes, once I needed other, otherwise I just caught up kind of the line. So, the whole problem is I think the system will work the whole problem is the longer, you know that the network discussion worse, you know, the state mismatch will happens more. Okay. Yeah, because, because the edge side it just cannot responsive cloud side you can start, you can create a lot of pause in the cloud, but none of them are going to be wrong, because there is no community connected. Okay, yeah, the network seems to be like a bigger problem than the resource, like you said a lot of these edge devices have incredible resources now. More than what we would normally have in a server in a data center, I'm finding. So, I think you're I agree with you on that. But the connectivity still seems to be a problem for people. Yeah. So, so, so in the IoT they have a few models, which I didn't cover in these slides. And there's one model is direct connect IoT device directly to the cloud, which is not a model that we are seeing because we are we are we are more like you know edge implication model like there is kind of little bit powerful machines running in the cloud side. And the IoT device just connect to that machine. So, so that's the reason we don't have to worry about a problem with you install everything in the edge device directly then then we have a problem in terms of the resource consumption. Okay, thank you. Yeah, what, what is the, sorry, what is the resource usage footprint on the notice we are talking the resource usage. Um, I think, I think, um, well, I, I don't have a direct management but I will say some range about like one or two core and the two gig memory this is my estimation. And I believe if you really want really want to run something really reasonable workload. So you've already had one part. Maybe I don't think there's a reasonable workload hundreds of parts kind of thing. Then then that memory that that resource should be required. I mentioned that the docker is a container runtime. Is it the like 100% of the container runtime or do people use like container D or cryo. It depends. But it depends how many customers customization they want to do if they want to just install the coordinates default. Not as good as the job docker but we are handling a few many cases that are still there. Thank you. Okay, so yeah, one more question here and so maybe you'll go over on some of the other slides but some of these edge devices also. And because of what Diane mentioned about network connectivity, some of these devices need to store a lot of data. Sometimes it's like video right so or like lots of information. So do you also have a way to connect to some storage device. So so I need to clarify that we are not saving the data for the application. We are only catch the data for the management system like API servers. So we are only in cash to manage it object manager data so in the local local storage that won't require many storage for sure. So, so I guess the story just would depend on what workloads are and what whether they want to use some physical or volume configure with Kubernetes, right. Again, so we are not going to catch in the workload data. We are catching the metadata. Because we don't really need to make sure if the cloud and the outside network is done, the Kubernetes component can work. We cannot guarantee that the edge applications still work. So edge application has to design a way that if they have their own handle of network offline to a centralized place. But in general, they are distributed algorithm, they won't distribute algorithm, they can talk to your neighbor, not to the centralized cloud. They can run that. No, that's the nature. Got it. Yeah. Okay. Thanks. Okay. Next, I'm going to describe the yard hop. This figure looks a little bit complicated, but in general, I try to go through it. So, the goal of we have an ad hub is we're trying to achieve a goal, which is the application of availability is still preserved when the cloud edge networking is off. So particularly what we were trying to resolve that if the net, if the current edge network is off, and the node is restarted, the cool it still can figure out what are the pause that I need to start. So, so the idea is we are we have a hard kind of proxy all the traffics from the corporate from them. And this node components to the API server. So the idea is, it will check if the network is online or not offline, if it's online, it will send a request directly to the API server. Once the request is really satisfied, we will save the results update the results to a cash manager basically, if you have a good networking, the hub what hub is keep doing is keep updating the the API servers, the objects status by monitoring the attribute request response to the local cash. And if, if the hub detect that the last connection to the API server, it will, you know, kind of serve the STP request from the cobalt or not components, by looking at the local proxy, and get a result directly from the cash. So we can think about more, more, more intuitive way is that if there is a least part API request, if the connection is good, the least request that we're sent to the API server. And the hub will, we'll get the response from the API server get all the list before it sends back to the corporate that is saved all the least objects into the local cash, and keep updating that every time there is new list request. So next time if the network is done, if the company to send the list request again, it will just check the local storage and give the all the parts that they have stopped back, and from the list request results back to the corporate. So this is how it does. So basically, the idea is we will catch the cloud manager locally through the yard hub into the local disk. So currently, there is a slight difference here so we use a kind of simplified mechanism that we don't use a database here we still use the kind of just text the local fire just plain plain fire to save the objects in a local disk we don't use a database here. There are a few reasons for this is the simplicity for sure. Secondly, is that the data the amount of data for the metadata is not a big is not a big number because think about how many parts are going to run in the nose. Maybe just metadata for hundreds of nodes, and maximally, so less than one mic kind of storage is kind of enough to save rose data. Indeed, but but again, there are loose some functionality in terms of the benefits of other benefits of the database, like a reliability kind of thing. But yeah that's that's what we choose for now. We just save as a file in the local disk for all the object that we catch in the car in the car side. I need to have some other problem because we recreate a pause requiring to recover the IP and Mac stuff. We do see some requirements say that oh, once you if you recreate a pause please keep the same IP and Mac for whatever reasons. But we were trying to achieve that but that requires kind of supports to the senior plugins to really really support that. But our all kind of young hub and kind of we, we have some solutions to work with their, their CI plugin to make sure they can, they can keep the IP and Mac once the party is recreated. So this is pretty much the high level view about the how young hub handle the, you know, the node autonomy problem, basically rise on cash and that you approximate to handle. So if you look at this figure, regardless how long your your your cloud and the edge network is off. It is just keep off there just get everything from the local cash and that local cash you never get a refreshed. So that's that's kind of passive passive mode we solve problem. All right, so the next part is the tunnel part so we are trying to resolve the problem that like makes the goal of this. This tunnel is trying to make sure the API serving the cloud can access the cool it and calling the logo or the API in the edge. There are a lot of, you know, tunneling solutions existing but many of them follow the same pattern. It is that in general it is the remote agent side of your creator, you know, the long TCP connection with the server. And they use this tunnel, then this workplace tunnel and every request come through that tunnel to bypass all the you know firewall sitting between the agent and the server. So, instead of, you know, doing our own tunnel server implementation. We designed to leverage the Kubernetes API server network proxy, which is, I think from the version 1.18, they start to support this. The API called the incorrect ingress selector, which means by sending that all the you know, network of traffic's going outside of the API server can be redirect to the API server proxy which which is in short is AMP. We leverage the AMP implementation to do the to implement the tunneling. But there are a few things because the AMP requires our GRPC protocol. So, in any API server, I think after 1.18, the API server can send the request through the GRPC. But before that, there's you just send the planned HTTP request to support the older versions so we in we kind of implement, we call the interceptor so you can see it just like a very simple translator kind of thing. It just just encapsulates all the HTTP request to becomes a GRPC request. That's all about it. And the AMP server and AMP agent, they are pretty much at the upstream components. But we do have some additions and changes on that in the sense that they want to. In the upstream AMP server, they were they were choose a random AMP agent to build that they were they were established to turn tunnel between the multiple AMP agent to one AMP server. The AMP server will randomly pick one agent to do the network transformation. But in our side, we have to do a very explicit the routing, because if they want to access the node ace, they have to go through the traffic has to go through to the node ace API AMP agent. So, so, so in our project, we kind of adding the routing policy in AMP, and to make sure that the and they will find the right connections to connect to to get the to communicate to with the cupid running the edge node from the cloud side. And, and we are trying to upstreaming part of the solution in the AMP community as well because this is kind of not the requirement by our own. It but also because it is also because by other, you know, users you say, it'd be nice to add a more specific specific or particular routing policy in the AMP server. The question is the interceptor is required to handle the old API versions right so when it's that because some people, you know, have to have to keep different versions of Kubernetes or yes. Yes, because because the ingress selector feature is only supported after 118. So, but in many of our many of customers are running system in lower version is like 116. So, or you know, so in that case, the API send request coming out of the API server is HTTP request. So, the AMP server require the input to be the jrp jrpc format so we just use the interceptor, you can see treated as another proxy just do a protocol conversion from HTTP to jrpc and that's it. There was no no. Got it. Got it. Okay, so. Yeah. Okay, the next one is the pool of management. So the goal is we're trying to have a modeling for pool of nodes on and we can do a pool based the deployment application management. So this, this part is pretty much leverage the existing way of the communities, extending committees by using the CRDs. So in general, so we introduce a node for CRD to manage to manage a pool of nodes, and we introduce a new workload called the United Department to management of workloads across different pools. So, so which means, if people define say okay we have a pool A and a pool B, and we register the pool B in the United Department customer resource. This controller will generate, we'll create and manage to when it is departments, one respect to the place knows and one just respect to the one respect to the previous notes. And you can specify the different replica replica numbers in plan and pool B and that you can upgrade them in the United way or using different ways is up to the customers. So, and and we, and we also leverage Kubernetes topology of our service to bond the East West traffic so in the past to the service model in the committees. There is no topology basically, if you have a service class class IP types of service this you know, this service routing rules will be updated in the IP table of all nodes. There's no notion of the topology. So, I think in Kubernetes one after 118 there's a new feature called topology rest service. So, it is kind of fits a line with our current our requirements very well. In a sense that now they can choose to just update the IP table of the parts of notes, or exactly in our case is a pool of notes. Then, then, even if the, if the service ending points trying to talk each other, they are born, they are bonded to the same kind of pool of notes, which is very, very good feature and to feed our use cases. And this is also the use case will be people having different pools and different locations right. So, you probably can have two factories, they're not very mobile, but they belong to the same company. So, you can say, you can think about that way. Got it. So, next I bring up some use cases. I won't give some exactly the examples of the use cases but pretty much currently on the open yard is used you can think about, you can think it as a edge pass call. So it becomes a foundation to support quite a few other past platforms that build on top of the resources that in the edge side. For example, we have a use case that supports the IOT pass, which is IOT pass is a device is a passing major IOT device very specifically, then there are these IOT pass itself has quite a few some components that some needs to be distributed to the edge side, some needs to be distributed in the cloud side. So, we run everything. So, in that program, all the development model is converted to container and using Kubernetes and using the kubi yard system to manage all the edge side node. And use the kubi yard system to manage using open yard to manage the components that belong to the pass that need to run in the remote side. The same thing happens in the CDN, a content library delivery. Also, there are quite a few services that need to run in the remote side. And the last one is we also have a use case that connect to our IOT pass platform. Well, a lot of algorithms for AI applications that need to run in the remote side. So, those tools or applications are encapsulating to the Kubernetes workload and are deployed in the edge nodes. So, so from high level view is like an open yard is kind of serve as an edge pass core to serve other edge platform. This is the primary use case. This is the typical use cases for open yard for now. All right, the last I will briefly talk about this entire community. So, open yard is kind of a new project so it only have a age of about six months. It's kind of it has a small community at this moment. We are still trying to use a kind of normal or standard way of the driving the project of going. We will have a quarterly based release and we set up a kind of roughly six month roadmap. Currently, we will have a bi-weekly meeting nowadays. In this meeting, roughly we have about 20 attendees at this moment. And thanks for the CNCF because once it accepts to the after donate open yard to CNCF, we got more chance to collaborate with other companies. We have a kind of interaction with Intel, VML, and an environmental group. We are trying to, they're also very interesting this project and we are trying to align our interests together and they're trying to contribute to the project as well. Yeah, that's all for today. So, yeah. Thanks for letting me present it and I'm happy to answer questions. Thank you. Thank you for presenting. Very good presentation. So, one more question, one more question about the adoption. So, are there any, is there anybody using the project already? I mean, you mentioned like people using it for or the use cases for AI and CDN. So, any of these people who are contributing using it or other people that are not necessarily contributing. Yeah. So, a few things. So, basically we have internally in Alibaba cloud, there is a cloud product which is entirely built based on the open source version of open yard. They are pretty much the same. So, and all the customers of that product, you can say that they are directly using the open yard at this moment. So, which is the philosophy that we have, we're trying to make sure everything is consistent so then we can apply the same quality to the project. So, make sure this project is kind of production ready at that stage. And is there anything that the community is doing to get more adoption or like reaching out to some places who are having these challenges? Sure. Sure. So, that's the reason we are saying that if you look at the collaborator. So, it's kind of nature. So, Intel VMware, they are looking, they're coming to us to say they have similar use cases either in their production line or in their, so pretty much in their production line. So, all the Intel and VMware have their own, you know, solutions to handle the edge computing. It's not new problem. It's a long standing problem. And they build their own solutions already. But the problem is they cannot, they cannot find the good collaboration with the Kubernetes community, because their solution are pretty much standalone and they are not built for Kubernetes for sure. Now, they are trying to find the, you know, the collaboration to, to integrate with their solution with the solution in the Kubernetes. That's why they, they reach out the open yard. The primary reason they choose open yard or not choosing the Kube edge or only they have tried is because of the compatibility. They like our design of not breaking the API compatibility. So this, I would say this is the biggest difference. And that's why they're trying to approach us. Got it. Okay. Yeah. Well, thank you for presenting. Looking forward to, to the project growing and getting more adoption. It's already in the CNCF. So, I think, I think, yeah, we probably will leverage you the power of CNCF. You know, nice way, because this is a good platform to, to, to let people know this project. And we are trying to, yeah, so the, the, the, the, some of the problem is that if you look at our meeting is kind of Asian Pacific time, you know, friendly. So now it is not a very, because nowadays most of the customer, even for this collaborator that they're coming from China side, but I do, I leave my, you know, connection information if you need. So we have a slack channel so people may just, if they couldn't attend a meeting, they can connect me and I can point you all the meeting records or ask me the question directly. Yeah, sounds good. Yeah. Yeah. You can send me, I'm on Slack on a CNCF Slack so you can send me that information and I can post it on the meeting notes here so basically do it more. Yeah. You tell some people how to contact you and. Yeah, yeah, just the slack is the only has its own selection or so people, if you they just visit the GitHub, they can get it so. Yeah, but you do have your own slack. I mean, but yeah. You do or you don't. I have, but yeah, but I would say the same thing. So if you send the message in the Slack channel, I'm going to see it. Okay. All right. Thank you. Happy holidays and yeah. Okay. That's all for today. Bye bye.