 we go. All right, thanks everyone for joining us today. Welcome to today's CNCF live webinar, engaging IoT devices from Kubernetes with Ocry. I'm Libby Schultz and I'll be moderating today's webinar. I'm going to read our code of conduct and then I will hand it over to Kate Goldenring, software engineer at Microsoft. A few housekeeping items before we get started. During the webinar, you're not able to speak, but you can enter all of your questions into our lovely chat box. Go ahead and say hi to us, tell us where you're watching from, and leave your questions here. We will get to as many as we can at the end. This is an official webinar of the CNCF and as such is subject to the code of conduct. Please do not add anything to the chat or questions that would be in violation of that code of conduct. And please be respectful of your fellow participants and our presenter. Please also note that the slides and recording will be posted later today to the online programs page at community.cncf.io under online programs and will also be available via your registration link and the recording will also be on our online programs YouTube playlist. With that, I will hand it over to Kate to kick things off. Awesome. Thank you, Libby. Well, hello, everyone. So today we're going to be talking about AUCRI, specifically how AUCRI can be used to both discover and manage IoT devices from Kubernetes. And just to kick it off, who am I? My name is Kate. I'm a software engineer at Microsoft, and I'm the maintainer and core developer of AUCRI, which is a CNCF sandbox project. And beyond that, I'm generally very active in the open source community, focusing on contributing to Rust and Kubernetes projects. One that you may know of is Creslit, which is another CNCF sandbox project, which enables running WebAssembly modules on Kubernetes itself. So feel free to follow me on either of my socials, but today I'm really focusing in on AUCRI. So let's talk about what we're going to talk about. I want to back up and talk about the motivation behind AUCRI and where it came from. And then we'll talk a little bit about what AUCRI is. Go through some scenarios, IoT edge scenarios that can be simplified with AUCRI. Then we'll look a little bit at AUCRI's architecture. And all this is going to lead up to a demo of using AUCRI to discover IP cameras and then use them in a streaming application context. And then go one step further of managing these devices by performing a firmware upgrade on them. And then we'll end with talking about what's next for AUCRI. And then throughout this presentation, feel free to put any questions you have in the chat. We'll have plenty of time at the end. And we'll address all those questions that we can. And then at the end of all the slides here, we have a link to AUCRI's documentation. So that'll also link out to our GitHub and other resources such as our Slack. So feel free to navigate to there, maybe bookmark it, explore during presentations. So looking at the motivation, oftentimes Kubernetes is running the cloud where you have racks of servers that not only themselves are very homogeneous in their compute and resources, but also their environment. It's very static. However, on the edge, not only are these nodes themselves very heterogeneous, so they support different amounts of compute, but also is their environment. So you have all these tiny IoT devices, think MCU class sensors, controllers, et cetera. And not only are there a bunch of different ones, but also they're constantly scaling up and scaling down. And oftentimes, these devices are too small to run Kubernetes themselves. So they may be MCU class devices that kind of have one fixed function, or maybe they don't want to be modified to run Kubernetes. So think brownfield devices. So AUCRI came from the question of how can we dynamically leverage these devices in a Kubernetes cluster when these devices themselves can't run Kubernetes? And so the goal of AUCRI is to create an open source standard way to connect these devices to a Kubernetes cluster and manage these devices from a cluster, which is really why AUCRI stands for Kubernetes resource interface. It aims to be that interface that abstracts the way of the details of discovering and using IoT devices on the edge. And it does that by first discovering the devices. So we look across the network locally on the device or attach to the device across the network locally on the node or attach to the node for these devices. And then for every device that AUCRI discovers, it connects it to the cluster by creating a Kubernetes resource to represent the device. And then we have a controller that can automatically deploy workloads to discover devices. And what's unique about AUCRI is that because it is really focused on the edge, AUCRI actually means edge in Greek, we handle those occurrences that are more common on the edge, such as devices dynamically disappearing. Maybe there's a loss of connectivity to the device or devices all of a sudden coming online. And AUCRI will see that. It will remove the Kubernetes resource we've created to represent that device. It'll bring down the workload that we've automatically deployed to use that device. And then if new devices come online, we'll automatically see that deploy appropriate workloads. Also, because we're focused on the edge, we were built in Rust to optimize to being as low footprint as possible. And we really work on and we run all of our tests on some of the common lightweight Kubernetes distributions, such as K3S and MicroKates. And a final note, I mentioned this earlier, but we are a community-based project. We're open sourced and a CNCF sandbox project. And this becomes really important when we talk about the way AUCRI does discovery because the more people working on AUCRI, the more types of devices AUCRI can discover. So like I mentioned, there are a lot of tiny IoT devices out there on the edge. So what IoT devices can AUCRI discover? One thing to note is that IoT devices do not need to be modified to work with AUCRI. Our goal is to not run anything on the devices themselves. They're oftentimes too small to even put anything on them. Rather, we want to communicate via the protocols that they already speak. So we call this pattern of communication that we make with these devices are discovery handlers, and they're oftentimes just protocol implementations. And currently, AUCRI has support for three discovery handlers. Specifically, we have support for Udev for discovering devices on the local Linux device file system. So these can be any USB device, such as USB cameras, USB microphones, or they can be embedded devices such as GPUs. We also have support for discovering industrial machinery via OPC UA. And finally, we have support for discovering IP cameras via the ONVIF protocol. And that's the one that we're kind of highlighting in our demo scenarios today. However, the thing to note is that our discovery interface is fully extensible. It's simply a GRPC interface. So if you wanted to add support for discovering a new set of devices via a new protocol, all you need to do is implement that interface. And that discovery handler, which is the implementation of that interface, can run in its own pod. So you can simply install AUCRI via our Helm chart and just add with our template, your discovery handler, and already you've enabled AUCRI to discover a new set of devices. So we have community members working on discovery handlers for Xerocomp, which discovers MD&S-based devices, and co-op for constrained devices. And I linked on the bottom these slides, which we'll share out after this, the direct link to the documentation that describes how to go about making a discovery handler. So originally, when AUCRI was created, we were really focusing on device use. Specifically, we had this one scenario in mind where AUCRI would discover devices and deploy a long running pod that acted as an information broker. So you can imagine, say we had an IP camera, you're constantly, this is an example show later, pulling streams of frames from that camera. Or say you wanted to constantly be monitoring the temperature of the thermometer. Those were kind of the scenarios we were originally looking at. Another one would be a protocol translation gateway. So maybe you discover a USB camera and a broker, that's this long running pod, advertises as an IP camera. And so out of this came the term broker being for the workloads that AUCRI's controller automatically deploys on your behalf to discover devices. However, as AUCRI evolved, there became a desire to have single task Kubernetes jobs deployed to discover devices. And so in our latest release, AUCRI version 0.8.4, we added support for deploying Kubernetes jobs to discover devices. So this opens up the world for more management scenarios for AUCRI. And so those are kind of the two buckets to kind of focus in when thinking about using AUCRI. You can use AUCRI to of course discover devices. And then beyond that, you can use AUCRI to either use devices, kind of process information from devices, or to manage devices via its new support for Kubernetes jobs. And so we're going to highlight both of those scenarios in the end with our demo. So let's look at some common, let's look at a IoT scenario on the edge and talk about how you could do it today without AUCRI. And then we'll look at how you can use these IoT devices in a more abstracted way with AUCRI. So in this scenario, let's say you're a farmer and you have an issue on your farm. You have some coyotes that are coming in and eating your chickens. And you've decided you want to solve this problem and you have some, you have some IT backgrounds. You decide to set up an IoT scenario where you're essentially going to install some IP cameras on your farm, do some inferencing to identify the coyotes and ultimately alert you that you need to go out and scare away the coyotes and save your chickens. So you decide to do this from the cloud and you take a microservice approach, deploying one frame server pod to each camera. And what this frame server pod will do is it'll connect to the RTSP URL of a specific camera and grab the footage from that camera and basically serve it over some interface. So you deploy one of those for each camera and then you deploy an inferencing pod that uses a GPU to do some coyote identification. And then finally you have an alerting pod that will ultimately tell you to go out and scare away the coyotes. So this is all doable and however you're on a farm, it's on the edge and maybe you have some latency issues or maybe you want to follow the laws laws of data gravity and process data closer to where it originates. So you decide you are going to install a server directly on your farm and you're optimistic about scaling out your farm. Maybe you think you're going to add some fields or add some chicken coops where you might need another server. So you go ahead and add it to a Kubernetes cluster to easily scale out your deployment. We can walk through the same setup that we had in the cloud and let's look to the right of the screen and see kind of the steps involved with this so that we can see how they change with Ocarina. So now one thing to note is the only information that's going to the cloud is that final alerting information. The rest is being processed locally on the edge. So we do the same thing. We deploy a frame server to each camera manually configuring exactly what camera it should be grabbing frames from. Then we deploy an inferencing pod and that inferencing pod needs to know how to find that GPU and connect to it. It needs to know how to pull the information from each of the frame server pods and then it'll pass information off to the alerting pod. This is all doable again. It only took four steps. That's not horrible but what happens as the environment changes? What happens if a camera goes down? So now that frame server may be erroring and maybe you need to send someone out into the field to fix that camera to get that frame server back running or maybe you need to manually bring down that frame server. What happens is if you add one, two, three cameras to your environment scale out your IoT deployment. Well you need to go and manually deploy each frame server and configure it to talk to the appropriate camera. Say you do in fact get another chicken coop, install another node. Well you need to now deploy another inferencing pod to gain the advantages of another GPU and attach that to your alerting pod. So one thing to note here is as the environment continues to change, you'll need to continue to interact with the cluster and make management interactions. However, we'll see that with Aukri, all you need to do is three initial configuration steps and then the environment can continue to change. You can continue to scale up and scale down your IoT deployment and Aukri will adjust on your behalf. So let's look at that. Same setup we had previously but you'll note that our first step here was installing Aukri and you can do that via Helm which is basically the package manager for Kubernetes. So now that we have Helm, sorry, now that we have Aukri installed on our cluster, which is that green box, we can go ahead and tell Aukri what to find and what to deploy to what it finds and you do that via Aukri's custom resource definition called a configuration. So in the configuration there's two main sections to look at. The first is the discovery handler and that's what we were talking about earlier. It's the protocol, discovery protocol that you want Aukri to use to find your devices. So in this case we're specifying on-biff to find these IP cameras. Not depicted here, you can also add some filters. Then you want to specify what broker or what workloads you want deployed automatically to discovered cameras. So here we're going to specify for the IP cameras we want to deploy a frame server to each camera. So after applying that to your cluster, Aukri will discover the cameras and automatically deploy a frame server to each camera. What you'll also see is and then it provisions each of those frame servers to connect to a specific camera. It does all that for you. What you'll also see is this larger blue box that represents a service layer so Aukri can also automate the creation of services. It can create services for each device or each broker and it can also create a service that contains the output of all the brokers or devices of a configuration. So you'll see here it's the latter one. We have one service that can be pointed to to get all the frames from all the cameras and that's ultimately the service that the inferencing pod can point to and know exactly how to get all those frames. Speaking of the inferencing pod, we can now go ahead and configure Aukri to discover a GPU using Aukri's UW discovery handler and then deploy an inferencing pod. So this is just another configuration. After applying that to the cluster, Aukri will find the GPU, deploy an inferencing pod and now we have our entire setup. So what happens as the environment changes? Say you add cameras, Aukri will discover them and immediately deploy frame servers. Say you add a node, Aukri will detect the new GPU and immediately deploy another inferencing pod. So you can see the environment can continue to change but we're only going to have those original three steps. So this really illustrates altogether how Aukri can simplify device use on the edge. Let's look at that second bucket that we talked about which was device management. So same scenario we had previously but now our objective is to not only use the devices but also manage them. So in this case we want to perform a firmware upgrade of these cameras. You can see we've added here at the bottom the firmware version. Let's say they're all at version one and our goal is to get them to firmware version two. So we can do this once again with another Aukri configuration. In this case once again we're using on-vift because we're discovering the IP cameras and our workload now is going to be a job with a specified image that is a firmware upgrade. So once you apply that to your cluster you'll see we now have an upgrade job deployed to each camera and the result will be that the cameras went to version two. And this is actually really similar to the demo that we're going to show at the end of this talk. It's going to show a use scenario and then we're going to perform a firmware upgrade on these cameras. So let's zoom in to what that green box was in our scenarios being Aukri and look at its architecture a little. So Aukri has an agent that runs on every single node in the cluster and a controller that runs on the control plane. The agent does the work of discovering the nodes, sorry discovering the IoT devices and creating Kubernetes resources to represent them and the controller does the work of deploying your specified brokers to the discovered devices. So the flow of this as we saw the first step is to install Aukri's first custom resource definition its configuration and as you mentioned earlier in that configuration you specify what you want to find via the discovery handler and you specify what you want to deploy to what you find via the broker and then you can also here specify some services that you want automatically deployed. Once the configuration is applied the agent will look across the network locally on the node attached to the node etc. It will tell the discovery handler to look for those devices. For each device that's discovered it'll create a Kubernetes resource to represent that device using the device plugin framework and it will also create a second custom resource definition the instance to represent that device and the instance not only represents the device but it also represents what nodes can see the device. It also has a list of what workloads are currently using the device and it even has connectivity information in it. So for example for an IP camera it would have the IP address, MAC address, RTSP URL, all the information that a broker would need in order to know what device to connect to. Then the Aukri controller will see an instance that's been created for a device and it will deploy the broker you specified in your configuration to one of the nodes that can see that device and that broker will connect to the device take whatever actions it was intended to do. One thing to note is that this broker and this diagram we put the word custom broker because that's really what you bring to Aukri. We've created this platform for discovering and automating the deployment and then it is your workload that we will deploy on your behalf and so in our demos there are samples that we've created but this could really be anything that you intend to do with the device and all of this is kicked off via an installation with Helm which as I mentioned earlier is the package manager for Kubernetes and we can break down this installation a little and see that by default the Aukri controller and agent are installed and then you can additionally set what discovery handlers you want deployed to each node and then you can build that configuration which is really just YAML via this Helm installation so you can give it a name you can specify what workload so in this case we're specifying an upgrade broker and you can even set this setting called capacity and capacity is how you specify how many you use a device at once. So this is really important with shared devices so say you have an IP camera that four nodes can see but you only want three workloads using this device at once you could set this capacity to three and that would mean that only three nodes could use this device at once even though all four can use it so it's way that you can manage how much it's way you can manage not overloading a device and making sure that it's not being requested too much so with that being said let's kind of walk through the demo that we're going to show it's going to look pretty similar to our earlier scenarios but you'll see our demo is going to consist of two Intel node nodes they're both running Ubuntu 20.04 and they're going to be connected via a k3s cluster which is a common Kubernetes distribution for edge scenarios and you'll see that we'll have two IP cameras on the network and these cameras are going to be mocked IP cameras so they're full implementations of the on-vith server and discovery service however we're mocking them so that they can support the use the update system firmware handle that's a part of the on-vith device management and so when you call out to that upgrade system firmware these cameras will call their upgrade service which will then reboot them with an incremented firmware version so we'll have these two IP cameras on the network and our goal is to discover them and then we want to use them via a streaming application so we're going to deploy like in our first scenario frame servers to connect to the cameras grab the frames and serve them and then we're going to ultimately have some application that's going to consume the frames from those cameras and display them so let's walk through what that looks like so we'll install Aukri with the with an on-vith configuration and specifying a frame server broker and we'll see that a configuration is going to be visible in the cluster and then the agent will discover the cameras and create two instances one for each camera and then the controller is going to deploy those frame server pods and you'll note here that even though there's two cameras there's four frame server pods that are going to be deployed and that's because we're going to set capacity to two so we're going to allow each node to use these cameras and the reason we want to do that is say one node where to go down it creates a highly available scenario where the other node is still processing the cameras still grabbing frames from them and so our application will constantly be getting the streams you'll also notice that we're going to use the ability to automatically create services and we're going to have a service not only to point to each individual camera's output but also to point to the output of all the cameras and our streaming application will point to both of those services and we'll see how we'll have a feed showing all the frames from all cameras and a feed showing one feed from each camera as well so we'll have created a scenario where we have this application that's benefiting from the work Aukri's done and then we'll take the scenario one step further and show how we can use Aukri to manage these devices and perform a firmware upgrade so we're going to install another configuration this one's going to be an upgrade configuration that specifies an upgrade broker and then the controller will ultimately deploy those jobs that will do an upgrade of these cameras and they'll go to version 2.0 great so now we can jump in to the demo and I'm going to just voice over it here and we'll go ahead and play it so the first thing to notice in this demo is that we have these two test cameras on our network you can see that both of them have firmware version 1.0 and these are the cameras that we're trying to discover and use with our streaming application and then ultimately we want to upgrade their firmware increment it up to version 2 with an upgrade job and so the first thing we're going to do is look at what our cluster setup is so we'll just simply query with kubectl get node which we're going to do in a second here great and you'll see here that we have a two node cluster as we saw in our diagram running k3s version 1.21 and now we're ready to install Aukri with its helm chart so we're going to deploy our on-vith discovery handlers we're going to create a configuration and in that configuration we're specifying that we're going to first use deploy our frame servers to each discovered device and notice that we put capacity as two so we'll have a broker deployed to each device on each node so we should have a total of four you'll see here that we have an agent deployed to each node and one controller and an on-vith discovery handler deployed to each node we had two instances pop up one for each camera and now we have four pods those frame server pods that are pending and about to start and you'll see once they started now we also have services that were created one for each camera those longer services and then one larger service to point to the output of all the cameras so all of that was immediately created via our one installation so now let's go ahead and visualize this with our streaming application this is a sample application we created for demo purposes the only thing we're changing here is we're specifying we want to use the on-vith services and now we can watch and confirm that it's running quickly popped up and now we want to access this application locally so we're just going to grab the port of it and do some port forwarding to see it locally on the computer great so now we can finally see our camera streams you'll see that this top box is pointing to both cameras so it's pointing to the larger service created by aukri and the top bottom two frames are each pointing to the service for each individual camera so at this point we know that we've successfully used aukri and we have an application benefiting from the work of aukri now we want to perform an upgrade of these cameras so to do that we're going to install another configuration and this time we're only installing the configuration so you'll see we're disabling the default features of our helm chart the controller the agent some RBAC configurations and specifying a broker job since this is a short-lived upgrade job and specifying the image for that we created for this demo so we're ready to go ahead and install it and once this installs it's going to be pretty quick we're going to immediately see two jobs created one for each device and then two pods created that are part of that job so if we look we'll see yep we have two jobs that were immediately created and now we have two pods at the bottom there that are pending and once they run now they're completed so that means they successfully upgraded the cameras or starting an upgrade so as can be expected when a camera's upgrading it's going to restart so we'll see that our stream we don't have any streams coming from the cameras for the time being and for our mark our firmware upgrade suite that we set up it simulates an upgrade by doing a 30 second time out during the reboot and it's going to restart the cameras and increment their firmware version so we'll see that these are going to come back online there they are and if we refresh we'll see now the firmwares at version 2.0 great so this demo showed how you can use upgrade to both use these devices and an application context and also how you can perform management actions specifically we showed firmware upgrade via our new support of deploying kubernetes jobs great um so let's talk about what we showed that ocre can support and what ocre does not yet support when it comes to device management so um what we added in our latest release was the ability to add a full kubernetes job spec to ocre's configuration you used to only be able to add a full kubernetes pod spec now it can be a job spec so this means that anything you can do with kubernetes jobs you can use do with ocre um so you can specify how many completions the job needs to have how many should run in parallel how many times it's allowed to back off before completely terminating and failing so all that comes out of the box with kubernetes you can do with ocre and that's really to say like ocre is very come 100 kubernetes native we support and run on all kubernetes and do what kubernetes can do what we do not support is currently is more of a managed rollout and kind of configuring what how those jobs should be deployed themselves so for example say you had nine cameras and you wanted to upgrade three at a time we don't have a declarative way of doing that currently what you could do though is what we didn't show is in ocre's configuration you can specify some filters in that discovery handler section so you could use ocre to discover all nine of your cameras and then you can add filters to say okay only upgrade these cameras with these ip addresses and you could deploy that upgrade configuration and then modify it with the next three ip addresses and the next three um but something more declarative to say like three at a time does not yet come with ocre another thing that we do support is you can continue like i was mentioning to deploy multiple configurations to use different to use same devices or different devices in different ways what we would love to support and would have been useful in this demo is showing some of that management information in the ocre instance so you saw that we had to show the on-vift device manager to look at the firmware version of these cameras well it would be great if all of that information such as the firmware version was in the ocre instance as well itself along with that connectivity information so with that being said that is the content of what i wanted to share with regards to device use and management with ocre if you're interested in learning more our documentation website there docs.ocre.sh will kind of lead you to all the important resources namely our github our slack and on it you can find some demos so we have our signature demo is it helps you set up some mock usb cameras discover and view them with that same streaming application we showed in our demo if you want to reproduce this demo including the mock ip camera setup and the firmware upgrade suite um i threw together hack and v that that models this demo so this is that's at the bottom of the slide feel free to check that out um and we may move that to our documentation site and make it more of an official demo and then finally we have a slack on the kubernetes slack um it's the ocre channel um and we do monthly zooms which was actually this morning so um next month feel free to hop on and discuss there and then if you want more of an overview of ocre another um introduction we presented at kubecon europe last year and that included a bit more detail on our discovery handler interface so if you're interested in what does that g rpc interface look like and what was the motivation behind it that talk would be a great reference for that um so with that said we have plenty of time for questions um and i can go ahead and start looking through the chat now and please continue to add questions there looks like we have a couple if you want to dig in awesome yeah i hope people ended up being able to hear me um check and see yeah um so with one of the supports uh one of the questions we got from james lou was does ocre support discovering iot devices devices using modbus so currently we only support udev obc way and on this but modbus is definitely something we've thought about supporting and there's been some discussion around it and it certainly we could support so um if that's something you're interested in and um contributing please check out the link that i showed earlier or go to docs dot ocre dot s h and it'll get you there um yeah related to the previous question um so zirconf was another one um so yeah we have someone contributing to zirconf they um kind of they took a break from the implementation but they got really far um one of the issues we had with zirconf is um so zirconf is essentially md and s so um device device communication with a discovery service on top of it and that discovery service um it uses the hobby demon is kind of bulky and so we had to pause on that implementation because at the time when it was being supported our discovery handlers were embedded in the agent so adding support for zirconf really bulked up the size of our agent um and so we paused there but now that our model is extensive we have our new extensibility model and our discovery handlers run in their own pods it's really good time to circle back to that implementation um that pr um should be revived and if you're interested in reviving that please um go to our um github and check that out um it would be good to get some more um momentum behind that implementation it's definitely something that we got really far with there's even like a proposal up on describing the motivation behind it and everything on our documentation um thank you um Tobias for providing the hack md link that I put here um another question can we deploy the different application pods based on the camera property or capability um but that okay great um so say that you have different cameras um so maybe you have a camera at your house um one's at the front door and one's at the back door and you want a different broker deployed to the one at the front door as the one deployed at the back door um if currently with our on-vift discovery handler the information that gets from a device I believe is ip address mac address and application and um camera name so if you were to name your cameras differently so maybe you named all the cameras that um needed one broker one thing and all the cameras that need another broker another thing um you could create two different configurations to deploy different brokers to each of them um be on that um other details like um deploying brokers to ones that had oh we also have scopes that's another thing with ip cameras so um you can query any scope on the camera and kind of filter it down what devices you're targeting that way so you could add a scope um to target them that way and if there's anything that our discovery handler doesn't um make specific enough that you would want to add like extra filtering um that's also a feature request that you could add on ocre if there was something else that you wanted to target more devices that were more specific um is anyone working on building energy management applications with ocre like backnet um or bac net I'm not familiar with bac net um maybe if someone in the chat wants to add more context there um but uh energy management application so my assumption based on what this question is is maybe you have a broker that's monitoring the consumption or use of a device um that would be a long-running pod maybe you're doing some ml there to kind of warn you hey this device is using too much energy at the moment um or just to kind of gather data on energy management I could see that being a scenario I'm not even sure if that's what you're asking about since I'm not familiar with bac net but um would love to hear more about that and maybe if you want to start a conversation about that James you can add an issue on ocre um and we can have more of a conversation and kind of look at it um more in detail and people in the community can pitch in there too also our slack would be a good place to throw that question um okay so another question um is ocre similar to digital twin we get that question a lot you didn't read too much into ocre um so the idea behind digital twins is that um you kind of create a representation of a device so you have um a device and it has all these different um settings or maybe the digital twin states what firmware the device should have maybe it's states we're talking in ip3 camera context maybe it states um what zoom it should have all these things and then the assumption is as you modify the digital twin um there'll be some kind of um workload that's working near the device that will make sure that it manages the device to match that digital twin um there are similarities there um the main thing with ocre is that it adds in that discovery part and it is kubernetes native so ocre is for kubernetes run on kubernetes and we didn't really get into this detail but the underlying implementation of ocre is it uses the device plugin interface so how the device plugin interface works is it really was intended for static devices so like gpus embedded in servers but we took it further and used it for network and shared devices um and because of that you have this like kubernetes representation of a device um and that leads to a scenario where you could um with pods you can request cpu in memory and with ocre enable scenarios where you can request an ip camera um so it does have circling back it has the similar fields digital twin but there's a lot more kubernetes um to it um an implement do you happen to have a whole implementation list that support the discovery interface um that would be great to have because we know that we support the three that i've mentioned a few times but um i'm not sure how many people in the community have their own so i think some people have worked on mqtt i feel like there was another one that i hadn't heard of that someone was working on it would be great kind of you know how there's um supported a kubernetes clients in different languages it would be nice to have a list of like this is what other community members are providing but we don't have that um currently um does ocre implement uh integrate with the cd solutions like rancher fleet if yes can we claim that implementing different rollout strategies is just a matter of configuration in fleet um i haven't used rancher fleet um i would imagine k3s is a rancher product um we should be able to implode uh integrate with it so ocre can run on um ideally any kubernetes we run all of our end-to-end tests on micro k kubernetes tested on k0s aks eks um i would assume it can run on rancher's solutions um with rancher fleet if it's continuous deployment solutions um so basically you're saying have rancher fleet do the work of the deployment um so basically the ocre agent could do all the discovery um and resource operation and then maybe you would use rancher fleet to do your deployment scenarios um that's that probably is very possible and very powerful um so the controller and agent are completely independent and so say rancher fleet had a way of watching for crd's um and taking actions based on that that may be a really useful tool for kind of honing into what management could look like with ocre so if you're interested in trying that out i would love to see where that goes um thank you for the clarification on bac net building automation control that anyone else is curious about it i would love to look into that a little bit more um and so roadmap um another so we had a comment um about ocre being kind of like service discovery with kubernetes um yeah i think that is a fair summary of what ocre is um using ocre with azure digital twin um we've had an issue up on ocre with that um and there is definitely some power there um but we have not taken steps towards that currently um yeah i think we got through most of the questions there um feel free i'll i'll settle in for another few minutes i mean we have until the end of the hour but if people are still um chewing over some questions um feel free to post them here we can wait a couple more minutes and then we might just end a little early and i believe um liby mentioned that there's a slack we can go to to continue to chat um or edrick actually posted the link to ocre slack um where you can continue to join the conversation as well awesome i did just post the slack link for cncf as well so there's plenty of places for everyone to get the info they're looking for are there any other questions all right well thank you everyone for joining us kate thank you so much for your webinar and all your great content um everyone hit her up at the all of the handles and links that are provided and um join us again for another cncf live webinar and uh we'll see you all next time and thanks again oh wait one more um okay great last question um can you discuss what the community has been doing with ocre and um in pillars or production um so what has ocre been doing what production scenarios have been used with ocre um yeah so we currently um were pre-release so we don't have any production solutions a lot of what's going on right now is in the research space so there's um research communities that are trying out ocre with devices um and a lot of our demos are kind of in that research mode um but there hasn't been production scenarios that i'm aware of right now we're kind of in that um speccing out phase where people are kind of bringing their ideas and looking at incorporating ocre um it'll take a little bit of a push um some community involvement to get us to a place where we are fully release ready and there are production scenarios yeah awesome well i think with that last question um thank you for having me livey and um for letting us talk about ocre and i appreciate all the great questions this is awesome thanks y'all so much and we will see you next time everybody have a great afternoon