 All right, I will get started without him. So welcome everyone. Can we go to the agenda yet? So today we'll cover some announcements. We have some information from Cheryl about the end user community. We have an incubation review, an annual review from OPAS since it's about its one year anniversary since entering the sandbox. We have a discussion topic around the CNF test bed that was announced recently, and then we'll go over CNCF SIG. So let's kind of speed through this. So yeah, awesome. Congratulations to the container defaults for recently graduating. I think it's a fantastic project and it's great to have our fifth project at the graduated maturity level. So thank you very much. Next slide. Just some reminders here. We push back the talk notification acceptances for KubeCon Europe to 311. So I believe that's next Monday. Everyone should get their notifications on that. So sorry for the slight delay. Next slide. Final kind of announcement for summer code for CNCF. We have a lot of awesome project ideas out there. So if your project is interested in participating, please just send a pull request and add your idea there. So we have a good uptake and we were formerly also accepted into the program this year again, so that's awesome news. Next slide. So this is one topic that we've discussed in the past around having time for project presentations in addition to kind of the normal TOC meetings that we have. So I believe Quinton suggested this a while ago and we're going to be implementing it now that every second Tuesday of the month will be dedicated to at the same time as this meeting will be dedicated to project presentations. The goal is to do about two at a time to kind of work through the backlog. The Creo folks have volunteered to go first at the meeting next Tuesday and I'm looking for one other project that I'll shoot a note out on the mailing list to ask for a volunteer. Anyone have any questions on this or any comments on the TOC? Cool. It takes silence as it's in school. Moving on. So how are we going to manage the schedule for that? So honestly, first come, first serve is basically my policy for folks who reach out and we'll kind of go there if it gets crazy then maybe based on when they file the GitHub issue. But cool. All right. Sorry, maybe I can just speak on Brian behalf. I think he had a concern that we need to sort of prioritize some of these things depending on what the state of the backlog is that we should perhaps have some prioritization function. I'm not sure what exactly the backlog looks like at the moment and if we can clear it fast enough that the prioritization is sort of academic or whether we want to try and do something more prioritized even that. All, you know, how about this? I could kick off a discussion privately with the TOC and you kind of make that decision, okay? Yeah, I was going to... Sounds good to me. There's a huge backlog still. I know I have at least two projects. So you probably know what I was going to speak up that are waiting to be published. Cool. Thanks. All right, thanks, Erin. All right, I'm going to go throw it over to Cheryl to talk a little bit about end user updates and all that jazz. You there? Thanks, Chris. Okay, cool. Yes, I'm here. So first off, case studies. So I would like every non-sandbox CNCF projects to publish a case study in the course of this year. This is a one hour interview. If you represent a project, then I would really love if you could sign up at that link there to do this case study and it will be over the phone. You get full approval on it before it gets published. Note that these case studies are only for end users. So if you look at the list of case studies published on the CNCF website, you can see what kind of companies and organizations we're looking for from there. Next, please. The second request I have of the projects and the Kubernetes SIG leads is that they come and actually meet the end user community. And if you have questions to ask, then you can have a 30 minute time slot with the 78 companies of the end user community. So we've already scheduled a hand for the projects and a couple of the SIGs, but actually the TOC is very welcome as well to come and ask questions to the end user community. So this is a really good opportunity for you to actually gather requirements and meet the end users directly. So again, sign up link right there. Back to you, Chris. All right, so SIGs. I have a quick question for Cheryl. Have you been coordinating with SIG Contribacts? And like I know from the steering committee's point of view with Kubernetes, we've established a new user group type of organizing structure. And it might be worthwhile to try and connect the dots between the outreach things that we've done within the Kubernetes community and the efforts across the CNCF. Yeah, I opened it up directly and the Contributes SIG just signed up directly. Okay. So I haven't coordinated any further than that, but I would be very happy to chat after this with you, Joe, and figure out how we can make sure these... At least get you talking with the right folks. Yeah, definitely. That would be great. Hey, Joe. Before you joined the TOC, I was trying to kick off a financial services and user CNCF thing, which Cheryl and I have been working on. And we just spent out in the last 24 hours that it sounds like you and some of the similar people were trying to get something off the ground as well. So we should join forces on that. Yeah, the Kubernetes stuff is more like trying to separate out, say, for example, the cloud provider SIGs, which are focused on implementation versus user support and community types of things. So it's more sort of technology, maybe sort of horizontally focused versus something like a financial services would definitely be, I don't know whether it'd be vertical or... But it's a different axis, one way or the other. Okay. Cool. I don't want to take too much time. I just want to make sure we connect the dots there. Another brief comment, Joe, I don't know if you've discussed some of the scalability issues that Kubernetes has been having with these end user groups, the Slack stuff being one of them. Is that something we also need to hook close to groups together on or... I'm not quite sure I get what you mean. Possibly. Although, quit in the last time we discussed this, the CNCF unfortunately wasn't interested in helping with moderation. So it might not be... I wasn't suggesting that they provide moderators. I was suggesting they try and help solve the problem in a different way, which seems to be a desire. Maybe, yeah, I wasn't sure. I guess I wasn't sure in that message about whether it was like, we're not supplying moderators or we're not engaged. It's a good idea to investigate for sure. So context for folks, we're dealing with a certain level of abuse and code of conduct stuff with respect to the Kubernetes Slack. And a lot of this is trying to actually create the right forms for contributors versus a wider community. And we don't have a good solution there. It's a really hard problem. And so this is sort of completing a conversation that's already in progress around that. Yeah, so if you're looking in chat, so we actually did speak with the end user community last week about the Slack moderation for Kubernetes Slack. And what the end user community thought at that point was that they would rather move to Reddit or move to another tool that was better suited for user support and community support rather than try and find the necessary number of moderators from the end user community to manage it. But that's a sort of form, that's the sort of questions that I would like you to be able to ask directly to end users. And Jayce could probably add some color to that conversation too, if you'd like. Yeah, so I will say that there wasn't wide representation. There's probably about five different people from the user community. So it was not a scientific study by any means. It would be nice to actually get a wider group of people to weigh in on it and maybe frame the argument. So it's a little better. And just to understand what the needs are there, but Cheryl was extremely helpful, did a short notice meeting and yeah, so I think it's more just solutioning at this point and we're working on what that might look like in the community. Awesome, thank you Cheryl, anything else? Or are we good with our end user? No, that's it for now. Thank you. Thanks, Cheryl. So off to the topic of SIGs. So we've been discussing this for a long time and last week we're kind of very close to finalization. There were some kind of final comments, I think in the poll request that Quinton's been doing a good job of addressing with others. So Quinton, do you have any comments here? Otherwise, I suggest we kind of formally go for a vote and get this thing done. Yeah, I'm comfortable if we give a vote. I think the only two items that I'm aware of that are not fully resolved yet are whether to split some of those SIGs now or later. And I have kind of been motivating us to try and split them later once they're actually formed and once we know that space a little better. But if there is general, if the TOC feels that they would rather split them today, we can do that. One of the problems is we don't really have a good agreement on exactly along which scene to split them, which is one of the reasons why I thought it might be better to split them later, but that's one not 100 cent resolved area. And what was the other one? Oh, the other one was the nature of the control structure between the TOC and these SIGs. And to what extent the TOC has active engagement and control of these SIGs versus them being more autonomous. And the wording in the document is fairly clearly that they are under the control of the TOC, but there were some comments that they perhaps should be more autonomous than that. I think those are the only two unresolved issues. And then there are a couple of formatting issues and more minor things, but those are the two items that I'm aware of that have not been totally resolved yet. But I do think that we can vote on the current state and I think we have reasonable resolution paths for both of those issues going forward. Yeah, I think we can probably go ahead with starting to set up SIGs without necessarily having a final 1.0 charter for those how they're gonna work. I think we could spend quite a long time arguing about the detailed language in the proposal if we really wanted to. But I think the intent is clear and I think we should be soliciting leadership for those SIGs right away. I agree. I would like the TOC members themselves just to vote on that there and say, yes, that is the plan. It's in what's in the document is the plan and we're executing it as opposed to we haven't agreed on what the plan is. So to do that, we probably want to have a target date which might slip for a 1.0 document that we're gonna vote on and then initiate a process of soliciting leadership and for exact SIGs, right? So to do that, somebody needs to basically put together language that we can vote on proposing something like that. I'm happy to put together some language and kick off a formal vote. We could put a deadline on maybe this Friday for final comments. So I thought that deadline was today basically and that we could kick off the vote today or do we think that the proposal is not sufficiently detailed to vote on? I'm not totally clear on what we're saying. I think in the past, we've solicited objections from TOC members on the call and indeed from the wider community to what's being proposed. And if there isn't a allowed vocal objection, then we basically articulate the vote immediately. I think we solicited that two weeks ago and decided that we would... I wasn't here two weeks ago, so apologies. Okay, let's go to the file file, yeah. I mean, I don't want to nitpick about it but I think we've done all of that and we should just vote. Great. I'm in favor of moving forward, Peste, but some other people think not. There are no strong objections. I'm happy to put something together today and send it out. And the last time we also discussed to bootstrap with one SIG first to kind of test drive things to see how it works before adding a ton more SIGs. And I think we suggested maybe the governance are safe kind of one in being the first one. Yeah, I think that there are a couple there that are important for different reasons. But yeah, start with one and move from there as fast as possible. I think as soon as we start soliciting people who want to push these things forward, we'll find that there is momentum in certain areas. All right. Thanks, Chris. Consider that done. So moving on to the next slides, which I believe it's Torrin to talk about OPA. It's been about almost a year since they've entered the sandbox so they're due for their annual review for the TOC and also this is coinciding with them requesting to move to the incubation level too. So I will let Torrin should be on. You there? Hello? Or Tim presenting? Can you hear me? Sorry about that. Yeah, we hear you now. Okay, sorry, we were dialed in and then I guess that was automatically muted or something. Okay, no, I think it's like star six to unmute if you're doing it. Oh yeah, yeah. All right, go ahead, it's all yours now. Okay, thanks a lot. Yeah, so I'm Torrin. I'm one of the co-founders and core contributors to the OPA policy agent. So what we thought we'd do is just give a quick overview of the project before we dive into some of the progress we've made. So open policy agent or OPA is a general purpose policy engine. And what that means is that it basically provides a building block, a reusable building block that you can take and use to unify policy enforcement across a range of different technology. So the whole goal of OPA is to help different kinds of components in your stack enforce policies, right? So whether you're talking about the API server or a custom internal microservice or a CICD pipeline or an object gateway or something like that, OPA exists to fill the gap of enforcing authorization policy or policies within that component. And so today folks are using OPA for a variety of different use cases. The two main ones though are around API authorization in microservice environments. And the second one is around admission control within Kubernetes. So there are a number of different people using OPA for API authorization. We typically break that down into kind of two categories. So there are companies like Netflix that are using OPA for building out like an internal security platform to enforce authorization over like internal services and internal resources. And then there are companies that are embedding OPA as a basically as a library to implement authorization for their end users, right? So every time an enterprise software company ships software to their customers, they have to have some kind of authorization system in place, right? And so they expose role-based access control or an IAM style system to their end users. And what we've seen in the last year or so is a lot of growth in terms of the number of companies basically offloading that implementation to OPA. On the Kubernetes side, admission control side, specifically, we see tons of companies using OPA for enforcing all kinds of different invariance or guardrails or constraints or rules or whatever you wanna call them over workloads, right? Over deployments and pods and ingresses and services and so on, right? So anytime you wanna roll out Kubernetes in a large organization and possibly a heavily regulated industry, you need to worry about where images are being sourced from, what labels are being applied, what teams can expose certain host names or paths or ingresses and so on. And OPA provides a really good solution to enforcing those kinds of policies. At the project level or in terms of software that OPA actually provides, the core thing is a declarative policy language that lets you express rules that answer questions like, can this user perform this action on this resource? It comes in the form of a Go library basically that's quite lightweight. We have very few source level dependencies. We have no run time dependencies. And you can also run it basically as a daemon if you're not embedding it in Go. And then the last thing that we also provide is sort of a suite of tooling that helps people author, build, test and debug their policies. So we provide things like an interactive shell that allows you to kind of experiment with policy. We provide a test framework so you can write basically unit tests over your policies. We have IDE integrations with VS Code and so on. So we're really basically taking policy and treating it as code and providing all the building blocks you need in order to do that. And then just in terms of background, we started the project actually in early 2016 at Styra, the company that I work for. And we joined the CNCF Sandbox around March of last year as Chris mentioned. And that proposal was sponsored by Ken Owens and Brian Grant. So are there any questions just about OPA at a high level? I know some people might not be familiar with it. I'm happy to just, if there's any kind of confusion around what OPA is, I'm happy to address that now, but otherwise I can move on. Okay, I'm gonna take that as a no. So this is just a kind of a summary of some of the stats we've been tracking on the project. And we tried to show the kind of year over year growth of the project. Obviously for the sort of canonical information, go check out the CNCF DevStats page or the project health page that they build. That's got much more information, but we thought we'd just distill some of it here. So in terms of contributions and commits to the project, we had about 480 commits over the last year compared to 410 the year before. And about 75% of those commits last year came from Styra, 7% from Chef, 5% from Cisco, and then about 14% from sort of a long tail of different users. So obviously the contributor base is relatively small to the project, but the trends are encouraging here, right? The year before it was like 93% Styra committing to the project. So we're pleased with that trend. In terms of actual contributors to the project, it basically doubled year over year. We started tracking the Docker Hub polls basically a year ago almost. And at the time there were around 80,000 polls. Over the last year though, it's grown to about 480,000. And recently we see about 10,000 image polls per week for the project or for the main OPA image. We've seen a lot of growth on Slack over the last year, almost 10X, we see about 15 people a week joining the Slack organization. So there are lots of people on Slack asking questions about OPA, asking questions about policy and Kubernetes, and then just talking about their use cases more generally that they want to apply policy for. Recently we started tracking the number of rego files on GitHub, so this is an approximate number of the number of repositories containing rego files that are publicly accessible on GitHub. So that's an interesting metric I think. And we see a couple of new repos every week basically popping up. And then in terms of stars, we've seen quite a bit of growth there, almost like more than 10X, that's due to a hacker news post actually that seemed to drive a lot of traffic to the project. In terms of the project itself and what we've been working on, there's a bunch of project level improvements we made. So we started holding bi-weekly community meetings since we entered the sandbox and lately we've had quite a bit of good participation there. So we've had regulars from Cisco and other companies participating, which has been great. We defined a governance model in order to meet the requirements of CNCF. We went through the core infrastructure initiative, best practices badging process. And so right now we're just passing, we haven't done the silver or gold levels, but maybe we'll look at that in the next year. And then thanks to the CNCF, we were able to get a Cure 53, an external pen tester to do a security audit of the project in the summer in August. And I think that that was relatively successful. There were a few low criticality vulnerabilities that they discovered and those got fixed. So thanks to the CNCF for sponsoring that and Cure 53 for doing a great job there. In terms of actual feature development, we shipped a lot of interesting things in the last year. We added support for basically a set of management APIs that allow you to dynamically configure OPA to do things like pull down policy and data from an external service API. We added a support for having OPA report its status back to a control plane. So you can see like what version of the policy the OPA is running with, whether there are any errors activating the latest policy bundle. And then also a decision log endpoint so that OPA can basically periodically upload batches of policy decision or audit logs to a remote endpoint. And those are particularly useful for debugging use cases, auditing and other things. At the end of last year, we shipped an initial version of a Rego to WebAssembly compiler. So it's basically an alpha right now. We're still working on that. It's not feature complete yet. We haven't covered the entire language, but we expect that to complete in the next couple of months. And then hopefully towards the end of this year, we'll have some interesting use cases that we can show off around using WebAssembly for policy enforcement. We also worked on a number of data filtering use cases as we found that a number of companies that were using OPA for API authorization, once they'd sort of solved API authorization with OPA, the next question they had was, well, how do I restrict access to sensitive data using OPA? And so we put a bunch of effort into extending one of OPA's features called partial evaluation to enable translation from basically Rego down into other query languages like SQL and Elasticsearch. So there's a blog post on that. I think it's interesting. It kind of shows how you can push policy enforcement down into the database or down into the data layer. We also added TLS client authentication for connections to OPA. We had previously only supported bearer tokens there. We had a couple end users ask for TLS support and that was actually contributed by some folks at Chef. And then we also added about 25 new built-in functions to the language to do common things like decode and verify JOTs, perform date time operations, CIDR math. We added a bunch of glob functions that are useful for dealing with things like ARNs and so on. And I think most of those came from the community. That was largely driven by people writing Rego and then thinking, oh, maybe there's some part of this that would be better expressed as a built-in and that they could contribute. And so that was nice to see. And then the last thing I just wanna call it here are a few integrations that we built that were also contributed by the community over the last year. So we built an integration with Envoy's external Z feature so that you could enforce API authorization policies with Envoy or in the Istio data plane, which complements the mixer integration that we already have. We built a Chef object gateway integration that was requested by one of our end users. The MinIO folks built a similar integration with their object gateway. Somebody built a Flask integration, Flask is a popular Python web framework. Somebody built a Kong integration and we also put together a Kafka one. And then something bigger that we also kicked off recently was this new project called Gatekeeper. So late last year, we started talking with various folks from Microsoft, Google and elsewhere about this problem of admission control and policy enforcement within Kubernetes. And it turned out that they'd already been basically working on a project around that using OPA. So the Azure folks contributed their Azure Kubernetes policy controller project to the OPA policy agent organization. And what Gatekeeper, which is called now as Gatekeeper and what Gatekeeper basically does is it integrates OPA with Kubernetes in a more kind of Kubernetes native manner than what we previously had just with OPA. And by doing so, it enables basically flexible admission control policy enforcement and auditing of Kubernetes clusters. So yeah, so we started working with various folks late last year but we kind of only officially kicked it off in January with community meetings, basically weekly community meetings that are being led by Google, Microsoft and Styra. We also have others contributing to that. And we have a number of end user participants that are engaged in those meetings. So Craig from Commonwealth Bank of Australia, folks from Replicated HQ, Capital One Intuit, Red Hat and others are all participating in those meetings. So that's been going super well. In terms of the actual project, like what we're aiming to provide, the MVP has sort of three main things that we wanna deliver. The first is an audit capability. So we want people to be able to take their admission policies and then ask the question, well, what resources in my Kubernetes cluster are currently violating that admission policy, right? So like what resources are missing a TTL annotation, right? That's a super common use case. We're also gonna be providing a standard library or kind of canned policies for common use cases. So, you hear people talking a lot about things like restricting image, the image registries that containers can pull from or doing management of labels, like doing ACLs over labels or restricting ingress pass and stuff like that. So there are a lot of these use cases that can be kind of distilled into templates or standard canned examples. And so we're gonna have a kind of an upstream community-based library of these policies. And then in terms of the actual interaction with Kubernetes, we're gonna move to a CRD model where you can basically load policies in by CRDs and then instantiate them as well via CRD. Okay, so just sort of moving on to end user kind of reports. So this slide gives kind of an overview of who is using OPA today. I don't think it's complete. We had a booth at KubeCon actually, and we had people coming up to us from all kinds of joint companies that we'd actually even never heard of, some of them that were telling us that they'd been using OPA for various things, particularly this problem of Kubernetes submission control. So this is basically a list of companies who we reached out to and who were able to publicly say that they were using the project right now. But obviously given that OPA is kind of embedded in a core part of a company's platform, some of them are not totally comfortable saying that they're using it publicly. So in terms of production usage, we have Intuit, Netflix, and Capital One highlighted here. If you wanna know a lot more of other use cases, you can check out talks that we did at KubeCon Austin in 2017 with Netflix and then KubeCon Seattle in 2018 with Intuit and Capital One. And so I think we have a few slides coming up that just kind of explain some of these use cases. So if you can go to the next slide. So Netflix was one of the earliest adopters of the project and for them, they use OPA as a kind of a core part of their security platform. So they have an internal security platform that's responsible for enforcing access control across microservices and other components in their infrastructure. This environment has got a lot of heterogeneity in it. They've got services implemented in a variety of different languages and frameworks that use different identity systems, that have different identity protocols around them that speak different protocols on the wire and so on. And they've got thousands of instances that they're dealing with. And so today they're running OPA on basically thousands of instances in their cloud infrastructure. And they're leveraging OPA's ability to take in external information, external context, data from their organization to enforce policies. So pulling in data from like a CMDB, like a config management database that has the application metadata in it, information from their employee tracking systems and so on. And they're really leveraging that core functionality of OPA quite heavily. They're also obviously leveraging OPA's ability to express policy over a wide variety of different systems. So they're implementing OPA policies over like HTTP APIs, GRPC APIs, Kafka and other things. So the fact that OPA provides a flexible and consistent way to do that is very important for them. Next slide. Chef is another company that's using OPA. They're also using OPA for API authorization, but their use cases is different because what they're doing is they're actually embedding it into Chef Automate to provide basically authorization support to their end users. So this is sort of that second use case that I mentioned at the beginning. Basically they implement an IAM style access control model in Chef Automate on top of OPA. And then they're also using OPA to enumerate the user resource permissions in the product. And they're also leveraging one of OPA's more advanced features, which is partial evaluation to optimize the policies and reduce the evaluation time. Next slide. So getting into some of the Kubernetes related use cases into it is using OPA in production. They've got OPA deployed as a validating and mutating admission controller for different kinds of security, multi-tenancy and risk management policies. They're currently deployed, they have OPA deployed across 50 different clusters with about a, and it's enforcing policy across about a thousand namespaces in total. And like I mentioned, you can check out a talk that we did with them at KubeCon Seattle that covers that use case. BOL.com is out of the Netherlands, I believe. They're an online retailer. Again, using OPA for a mix of validating and mutating admission control policies in their communities clusters. So they do things like they patch, image pull secrets onto pods. They set different load balancer properties and tolerations on workloads. And all of that is based on context that's coming from metadata stored on namespaces. So they're basically replicating namespace objects into OPA and then referring those inside of their policies, excuse me. And then I think they're deployed across a number of different clusters. And then the last one that I wanted to highlight is a company that can't publicly state that they're using OPA, but they're a Fortune 100 company. They're very security focused. They use OPA for a mix of, or for a bunch of different validating admission control use cases, as well as authorization policies within Kubernetes. They've got about 10 clusters right now with over a thousand nodes. One of the things that was interesting there was that they initially adopted it for admission control in Kubernetes about a year ago. And over the past year, it's sort of spread out into a bunch of different use cases as they've seen that it can be applied to different technology, different domains. For example, the day they've got it integrated into their public key infrastructure in a certificate RA that's serving these clusters, right? So when workloads boot up and they request a client certificate or a server certificate, they have policies in place there that decide whether or not those certs get granted. So, and that's it, I think. I think the next slide is just a conclusion. So yeah, so there's the slide. This is Amatoi, just have a quick question. Do you have an API for the OPA that if somebody wants to integrate, that can integrate easily? So the question is, do we have an API? Yes, we do. There's a Go-based API you can use if you want to embed it as a library. And we also have an HTTP-based API that you can use for non-Go embeddings. And so that's well supported and we have plenty of documentation and examples that show that. So the other one is you're talking about the admission controls. I don't know really what that means in your terminology. I assume that has nothing to do with the traffic. You're probably talking about the packaging and things like that, am I wrong? Yeah, admission control is just a process of enforcing different kind of like semantic validation or invariance over CUBE resources that are being created, updated and deleted. So it's a core part of Kubernetes, but it's a little bit obscure for some. Yeah, the admission control is used for complete different things. But okay, thank you. Toran, I had a quick question about, it's a bit difficult to formulate clearly, but to what extent is all these integrations available as open source? So if I was a user and I wanted to enforce all these various different kinds of policies that you've mentioned, to what extent can I do that using open source tools that are out there in integrations and to what extent do I need to buy commercial integrations for that? So we have about 20 integrations that are all open source today. So a lot of them just leverage like external authorization capabilities that other projects and products have, right? So CUBE has excellent, external authorization capabilities, it's got an authorization webhook, it has admission webhooks. We just plug into those, basically. Projects like Kafka, Ceph, and so on all have external authorization. We just hook into those. So the answer is that they're basically all open source. Some of them are obviously less mature than others, but yeah. Okay, so most of these use cases that you've outlined, I could go out and install a bunch of open source software and do the same thing if I offered the correct policy. Yes, yeah, yeah, yeah. And what we see a lot of as well are people just building custom integrations internally based on their environments. So we try to make the API as simple as possible for people to integrate. Thank you, that answers my question. Hi, good question about the Netflix use case. Hello? Yep. Okay, can you hear me? Yep. So one of the things I saw that in their presentation was the fact that they do the aggregation of the policy information from all various systems and then they do the distribution. So which is kind of very interesting because we are looking at OPA from our Edge Cloud perspective and we wanna do the decisioning near to the edge actually. So is that something distribution thing is part of the OPA thing or is that something we will have to build it ourselves just like Netflix folks did? Yeah, yeah, that's a good question. That comes up all the time. There's no open source control plane for OPA that does the distribution that I know of today. I mentioned a minute ago in the section of what we worked on in the last year, we added these APIs that enable OPA to pull down policies for just like basically enable distribution, enable observability of OPAs. So those APIs are there. So we have the APIs in place for you to build that but you have to build yourself today. So you have to kind of, everybody has to kind of custom build as far as the distribution of the centralized policy DBs. Yeah, now to be fair, like one of the things that Netflix said was that the way that they architected that control plane and the way that they expose it to their users in their organization is very specific to their organization, right? Because they have custom services that they're pulling data from and they have very specific UIs that they wanna expose to their users within the company. And so I don't think they saw a lot of value in open sourcing that. Like it didn't seem like it would necessarily be reasonable. So we do see people building their own control plans. Fairly frequently. It's just because it ends up being specific to that org but we'd love to see more people within the community working on that as well, if there's interest. Yeah, I'll reach out to you offline. Great, yeah, happy to chat offline. Thanks, thank you. This is Alexis just budding in to say, unfortunately I have to drop off the call in a minute. I have two quick comments. One is that speaking personally, I have come across a lot of enterprise and users who are either using or talking about OPA which I think is extremely healthy and exciting. So well done. Secondly, on a process point of view, we haven't voted on incubation for some time. And there was some discussion about formalizing the process a bit more. I would like to ask Chris if you could remind everybody in the TOC where the process documents were written down. I think it was a long GitHub issue a while ago. You're going to just kind of make sure that we do things the same for every project, whether it's coming from the sandbox or coming in a new, including DD. Yeah. That's all right, thanks. Cool, no worries. I mean, essentially it's all kind of in the sandbox. Markdown file, but there is a requirement for due diligence and a two thirds TOC approval vote. So in this case, Brendan has volunteered to do a bit of due diligence. So it's on his list to take care of and share with the group. And then a formal vote will be called if there's really no objections from the TOC. Sound good, Alexis? Sounds good to me. Thank you very much. And goodbye to everybody for now. Bye-bye. Well, thanks. Any other questions for Toran about OPA or any questions from the TOC members or concerns? Any movement or integrations around Cassandra? Not that I know of. We haven't built anything ourselves for that. I do know one company that was using Cassandra for distribution of policy to TOPAs, but not like for enforcement of policy. Yeah, happy to chat about that though, if that's interesting. Great, thank you. Any other questions that someone said in the Slack does OPA support network and rounding policy management as well, Toran? No, I'm just gonna say no right now. You don't wanna put OPA in the data plane of your network. All right, final call for questions. Otherwise, we will have Brendan and the TOC kind of work on the kind of due diligence. And then after that's done, we'll call a formal vote hopefully in a week or two. Okay? Just one last comment, Michael Payne here from JPMorgan. So we're using OPA as well as part of our Domition Control apparatus on Kubernetes, but we're also using it to enforce more restrictive network policy. So it's not in the data plane, but we are using it to further lock down our network, denial network policy as well. So it's working well for us. We can keep that in because our feedback, Michael. Yeah, I wanted to just clarify, Toran's answer to the previous question, which I guess is similar to what Michael just mentioned. From what I recall, although you don't wanna actually be like policing packets with OPA evaluations, I understood that there were quite a few cases of basically customizing things like IP tables rules based on OPA policy. So it wasn't directly in the data plane, but it was involved in programming the data plane. Is that true or not? Yeah, yeah. So it is possible that you could use OPA to enforce policies in the network. We don't do that today. Like we just haven't invested effort into engineering that. It's a really big amount of effort that goes into that and we just haven't done that yet. In theory, you could definitely take OPA's policy language and express like micro segmentation policies and then have something that translates or compiles that down into IP tables or whatever to get enforced in the network in the data plane. So it's definitely possible. And then there are, there's other kinds of use cases that Michael just mentioned that they're using OPA for around putting guardrails over like the actual network objects and the network policies and so on. So there is definitely a network domain component here. I just didn't wanna say that we're putting OPA on every packet, which we're not doing right now. Okay. Thank you. Yeah. All right. Well, thanks all. Thanks, thanks Doran. All right. Moving on. So another discussion topic, trying to remember if it was Quinton or Alexis that brought this up, but essentially the CNCF launched a new initiative similar to kind of the work that we do in around dev stats or CNCF.ci and so on. But, you know, it essentially is a joint collaboration with a sister foundation at the Linux Foundation called LFN, which is the Linux Foundation Networking folks. Essentially it's a lot of telcos, but the name of the project is the CNF testbed. So if you're familiar with the telco industry, there is a wide amount of usage of VMs through these things called VNFs, which are essentially our little apps, you know, packaged in VMs. There's been a lot of desire amongst certain CNCF members and LFN members to, you know, see how kind of a modern take, you know, on deploying applications within telcos kind of look like and, you know, trying to compare infrastructure deployments between say like a container-based stack versus a VM-based stack and so on. So, you know, the idea was to try to come up with a simple reproducible environment for folks to try out kind of both approaches and, you know, how it would look like and so on. You know, we had some generous support from one of our members packet to provide some hardware and then we funded some kind of contractors kind of work on this project. We, I linked off a very detailed presentation that kind of dives in into kind of the more specifics of what's contained in this initiative, but on the next slide kind of covers, you know, more ways to kind of get involved in how to kind of play with this infrastructure, essentially, if you want to take advantages and see how this would work for you. It's all kind of linked off the CNF testbed GitHub repo and there's a way to request accounts via packet. So, essentially, it's a bit of an experiment for us, but it's, you know, been going pretty well. We've been working on this, I think, for probably past nine plus months. So, those are some of the details. You know, I try to remember if it was Alexis or Quinton who asked this, but, you know, we're open to kind of any questions that the TOC or the community has on this specific initiative. And I think Dan's on the line also if you want to share any specific feedback. Yeah, I was the one who asked to put this on the agenda. And the main motivation was that I don't think that TOC was significantly aware of any of the work that was happening. And I also know there was a pretty contentious press release made. And I think many of the TOC members and potentially the board members as well were surprised by this. And so it seems like we need to have some way of avoiding that surprise. And yeah. Got it, Quinton. I think it was brought up at a board meeting a while ago that we're funding this, but it looks like we didn't do the kind of best job of disseminating it to the TOC. Because then there are tools like, you know, API SNU, CNCF, you know, dot CI, that CNCF funds that think that TOC should be aware of, but maybe we're not doing the best job about that. I think my biggest concern is that we're essentially setting up a this or that zero sum game between Kubernetes and the CNCF and the OpenStack community. Whether or not that's the intent, that's the way that this is playing out. And in the similar efforts that you're talking about here, things like DevStats, like that's all internal facing. That's about us understanding our community, understanding what we're doing. Like we're not actually going out and throwing shade, like purposefully or not on other open source communities. And so I'm wondering how we're thinking about navigating that so that we can, we have this be something that, you know, is constructive for everybody. Yeah, I mean, I think one of my quotes in particular in the TechCrunch article was unhelpfully negative. And I am clear that avoiding negativity is important to the Kubernetes and the cloud native communities. The point of the CNF test bed is to avoid ad hominem comments and instead have an open source replicable way to discuss differences between VNF and CNF architectures. And I think it's relatively obvious that a lot of the biggest backers of Kubernetes are also huge backers of OpenStack and a ton of the end users of cloud native projects are end users of OpenStack and that there's a huge overlap of the community of developers and contributors and such and that we're going to be coexisting for years or probably decades to come. So I do understand the point about negativity and I do regret that particular quote, but I believe this can remain a useful project for looking at this particular market development opportunity around telcos. And I think there's also a larger message here outside of just the telco use cases, which is one of containers versus VMs. It's a complicated ever changing and fuzzy boundary between these things. And I think we very much wanna make sure that we look at it as containers and VMs, courses for courses, right solution for the right problem type of thing. And I think that that didn't come out of some of the press around this. I agree. Any other questions? It's a fairly new initiative. They're essentially running kind of like a typical open source projects with open meetings and so on. So if the folks are interested, they're more than happy to jump on. I believe they had a meeting yesterday. So I'll send a note out to the list of people are interested in engaging with that community. Alrighty, any other questions from the community? Otherwise, we will see each other next Tuesday where we will be kicking off project presentations and so on at ADM Pacific. So any other questions before we wrap it up? Cool, all right. We'll close the meeting a few minutes early. So thank you everyone for your time and see everyone next week. So thanks. Thank you.