 Okay. Well, it's 10.05, so good morning. I'm glad you can hear me. This is the CNCF, CI Working Group meeting, which is held on once a month, on the fourth Tuesday at 8 a.m. Pacific time currently. We do have some colleagues who are on the other side of the globe, and one of the action items out of today's call will be a doodle poll to find the preferred start time for our once a month calls. I've shared the meeting notes in the Zoom chat. We've got our agenda notes, which have been updated from the group. Thank you. Wow. Thanks everybody for joining and contributing to today's CI Working Group call. If you haven't yet added your names to the attendee list, feel free to do so. And I'll start sharing my screen to show the meeting notes. We can do a little bit of agenda recap. We've switched up the order just a bit due to limited availability. But otherwise, I think we'll have a full hour. Can you see my screen? Yep. Yes. Yep. I can. Great. Thank you so much. Cool. So we'll do a quick recap of the CrossCloud CI project. Then we have an update from OpenNFVXCI and how we can work together on own app projects. We'll have an update from Packet and an update from VMware. We will then have an update from Oracle Cloud and meet the team who will be adding Oracle platform to cncf.ci. And Watson then will follow up with an overview of cross CD definitions. And there's a link in the doc just in case we don't get to that topic at the end of the hour. Taylor, are you ready? I will share my screen with the slides. I'm ready. And I'm able to share my screen if that'd be helpful as well. I think we've got it. Okay, great. Is my audio coming through okay? Yes. Okay, great. So, CrossCloud CI project. We do have a the first slide five there is just why we were originally here what we're trying to do. This is regarding collaboration and integration between all the projects cncf and trying to build the software and platform that would be usable for showing the integration between those projects and how they can be deployed and used across multiple cloud providers and then focusing on making it possible for software outside of cncf. Go to slide six. So that was original goal that we had when we started and that's the CI platform, which we completed the underlying and that ties in with the CrossCloud Kubernetes employer, which we're talking about for VMware and stuff. The status repository and dashboard for displaying the results from the platform. So these are built as individual components so they can fit together and then integrating with external CI system. So started with internal CI system one to make sure that we could work with others. And the first one was the own app. Next slide six, seven, sorry. So, some of the projects I'm focusing on trying to build and be able to add those working on making it possible for the community to contribute and maintain those core DNS, Prometheus, some of those that we have right now. And then slide eight. This was a pretty big deal as far as the project making it easier to add external projects so own app and doing an integration with their CI system and help this expand and make the system more portable outside of the original CI platform and get lab and other components. Slide nine. So we have AWS Google Cloud OpenStack, Azure, IBM packet, soon to be VMware and hopefully Oracle. Here's the current dashboard with Kubernetes deploying across the different clouds at the top. Here's slide 11. We build all of the projects from source where we're using the internal CI system. So that's Kubernetes on the master head release as well as whatever the latest table is. And then the same thing for the different projects that are going to be deployed on Kubernetes. For own app, we actually don't build. We use the upstream and then we deploy Kubernetes to each of the cloud, set up the clusters for stable and head release and deploy all of the apps to Kubernetes with help and run the end to end test. So quick overview. Right now the underlying platform that we're using for running the different software pieces is GitLab. This could be on top of various things. We're using the registry container registry and other things in GitLab as well. At the moment, Terraform, Cloud in it, some of the things we're using. And we're using Kube test for Kubernetes, bringing that up because of potentially moving away from that. And then Helm, try to use upstream Helm charts as much as possible. And if needed, then we'll fork those and try to contribute any changes like the own app side. We worked with them when they were focused on getting the new release of own app ready and deploying on onto Kubernetes. So we worked with some early versions of that and help contribute any changes. Okay, some of the dashboard technology. And there's been some questions on using some of that. If we haven't put a lot of docs out there, but we're trying to make those available. No Melvin was asking about that. Slide 16. So we're continuing to maintain and just most of this is updating to support new versions of various software, anything like core OS updates for GCE requirements for what's available, those sort of things at the moment. That's been a lot of the focuses of maintenance. Slide 17. So the major development we've had right now is on the cloud side. So thanks folks for helping on the VMware integration. We do have the one pool 150 was merged. We saw a few things that we needed to update Andrew you've turned around and contributed the new pull request 153. Appreciate it. So we're hoping to have VMware pretty soon through testing and up in life and then Oracle integration coming hopefully next. So we plan to keep adding cloud support for the cross cloud provisioner and however that works in the dashboard visualization. What we're looking at next is what what do we want to do for to and what's going to be valuable for the community. What can we change whether it's dashboard, how the status repository can be to utilize what we're testing. So we're looking at stuff like son of boy, moving away from cube test a son of boy which is seems to be the defect though at this point, potentially using the same for some of the cluster bring up we're working with the cluster lifecycle. SIG and some of the other groups on the Kubernetes to see where that should go. Maybe using ignition, rather than cloud in it specifically for coral s since that's now going to be the only choice in that place and saying what we can do there. Harbor might be something that we end up using for a container registry so looking at these sort of things would also like to get feedback for where to go and what would be useful community wise. Some of the things that we were looking at before would be the automation, the API history. So this is the actual status repository making it available and we are working with the network service mesh folks over on the networking. That's the CMCF networking working group and some other groups and looking at how the different pieces of software can be useful there and then taking the feedback to roll back into the cross called CI project itself. So we welcome any feedback so we can see where we're going to go with V2O and if y'all have that then please join us in these groups. The mailing list on Slack love to get feedback so that we can see where to go next. And that's it for Croscut CI. The one piece of feedback I have Taylor and I can file an issue or we want to handle this. Okay. Topics been raised a few times to me with regards to the dashboard. Hopefully you know VMware show up there soon but I've had some questions well you know what does it mean when it goes red and certainly we've seen it go red for reasons beyond the control of the platform and you know as I mentioned to somebody like unless our platform is down most likely if it's red it's not something in our control and but the way it looks however can be it's leading so maybe something with the dashboard that things are red if we hover over it or there's some inserted element that indicates that you know if it's a platform specific error or not and I don't know how you might necessarily detect that but like I said I've seen it go red and it has nothing to do with the platform but somebody looking at it might think that VMware is broken. And I think that obviously the people eager to participate in this work eager to participate in this. At the same time I think we want to make sure that if something looks broken it's clear why. And that's great feedback I think I summarized in the zoom chat there. So what does it mean to go red. Is this a cloud provider issue is this a build deploy issue where is it definitely something that we've been looking at. Some of those things are going to come down to the specifics and the error messages which can be easy for maybe a human to quickly see much harder to automate as far as finding from programmatic and showing and say pop up or some type of mouse over whether you go to another screen whatever that is. And we are slowly adding those pieces as we're going along but something that we're we've thought about how can we do this more as a overall general but thanks. Yeah I mean one way that I could conceivably think to do something would be like a stoplight insert yellow and if you can connect to the cluster instead of red maybe market yellow to or to indicate that the cluster is healthy. Yeah a few weeks ago I saw it looked like some bad data some bad data got inserted into an environment file at the build system the build completed. But now bad environment file was corrupting all of the platform deploys but the clusters were still up. And I think you know at that point the provider has done its job by using that phrase with respect. Yeah but yeah something like that. Yeah totally understand I think I know which one are referring to and it's it's actually something where we could probably stop moving forward so it's before you get to that. This would have to do with some early plans that we had potentially showing here was the last successful build or deploy or whatever it is. Anyways let's carry on maybe if you want to open a ticket with ideas or catch me on Slack we can continue with some of those. And again love to hear feedback from other folks on what would be useful especially to the whole community handed over. I guess Fatih do you want to are you available. Yeah. So this will be a quick update from opnfie site regarding what we are doing with on up integration and then relation to open CI. So opnfie is one of the Linux foundation networking umbrella projects which basically does system integration and testing by bringing different open source technologies together like open stack. There's open daylight on up and so on. And it is pretty like similar to cross cloud CI open if you cross community CI also does cross community CI but as opposed to what cross class CI is doing opnfie does everything on bare metal mostly because opnfie generally deals with telco specific use cases and benchmarking and performance characteristics they are important and they need to be verified on production like environment. And since day one we have been doing this type of cross community integration. And over time we decide to move forward faster by bringing different technologies from master branch strength like how cross class CI is doing. And thanks to open daylight community and Daniel fell who is with us today we got lots of input from open daylight community and we basically tried copying or we started copying their practices they employ in their continuous delivery pipelines. And based on those practices we started bringing open daylight from trunk into open environment and start integrating open daylight with open stack. And this opened up new opportunities and one of the projects we want to start working with is on up because on up is pretty important in networking roles. And it basically provides management and orchestration for network functions, virtualization, bnfs and physical network functions. And when we started working with on up community and start looking at how we can bring these things together to opnfie infrastructure we found out that you are already doing this in cross cloud CI. And then we start talking about like how can we do similar things and ensure that we can bring on up into cross cloud CI by again following practices set by other communities such as C&C of cross cloud CI. And this actually made some of the things we have been struggling with pretty obvious which we realize that those things, those use cases we have in opnfie XCI might be common across different communities such as C&C. For example, the basic thing, how can we bring in artifacts from on up into cross cloud CI or cross cloud CI in a similar way we are doing with open daylight artifacts. And this brings us to an obvious need that it would be important for us opnfie, C&CF or other communities who might need to reach out to on up community and get the needs we have implemented there. And instead of reaching out to on up community ourselves alone. It might make sense for us to collect a try to collect the requirements on our site within C&CF cross cloud CI or opnfie XCI or perhaps even open lab and find commonalities between these different requirements and use case and then reach out on up community. One voice so they don't have to deal with multiple communities and they don't get confused and we don't rest their time and our time so we can get things done much faster. And that is actually the second bullet point like how can we find out scenarios that are coming up with common requirements on up community and that is something I want to highlight to C&CF and cross cloud CI team that how can we start collecting these requirements. And this brings us to open CI, which is a new initiative kind of community forming, start forming recently, and we are talking about similar concerns or practices as part of open CI to establish cross community CI with a wider open source ecosystem. For example, open stack, C&CF, open daylight, FIDO, on up, opnfie, Linux Foundation, Ansible and so on. And if we can set an example between ourselves to bring up common requirements and use cases from C&CF, opnfie, communities, we can connect this to open CI high level teams when it comes to cross community CI and then make this type of approach a common practice from open CI and if some other communities need to reach out to other communities based on similar needs, they can look at what we have tried, what we haven't been able to achieve and what we have achieved. So we can set some kind of blueprint there when it comes to how to tackle this common integration challenges across different open source communities. And the second part of this, okay, it's all good that we can start an intrepad or Google doc document to collect these requirements, but we also need to make things real. So we have a progress in parallel to thinking or talking about the problems. And again, as part of open CI, we start the prototype which we have the link to that document on the slide within open daylight, between open daylight on up and opnfie to try out some ideas like using event-driven CI to get the CI systems talking to each other. So they can basically pass the information regarding whatever they have been doing in their CI CD systems, such as building artifacts, testing them, proving certain millions of artifacts are good enough for other communities to consume. And then that information can be used for other CI CD systems to fetch those artifacts and do further test integration and testing. If you need to put this in CNCF cross-class CI context, which basically, which might make your life easier if on up starts publishing events when they create new artifacts, so you don't have to go and parse their locks and so on. And this is something I already asked to Tyler Lucina Watson and other cross-class CI folks that like what do we need to get from on up CI. What information is important for cross-class CI to function and bring on up on your CI infrastructure or your CI system. And we collected some requirements from there. And we also have some requirements in opnfie site. And we put those requirements on top of the existing example requirements coming out from this prototype document on the Google Docs. And based on these things, we started this prototype and the basic hello world type of thing, we made it working between on up open data and opnfie. And Yolanda was part of this work and Daniel was part of this work as well. And I think we are in a stage that we think we should start working on some kind of better structured message types. The message types you will see in this document are just a basic message type demonstrator idea. And since we haven't received any negative feedback or disagreement regarding this proposal, we decided to work and come up with second iteration of message types based on the message types we determined on this document, basic artifact published event, composition creator and confidence level modifier and which you can read the details. And then we will share this once we have it ready with open CI community with CNCF, cross class CI with open map and with others who are involved in open CI and interest in this type of solution. And then collect further feedback to see if this is a viable solution to tackle some of the challenges we have in cross community integration. And then now I need to pass the word to Yolanda because she has been working on this message publishing and messaging protocol so she can give updates. Thanks. Okay, so what mostly is what Fatih is playing in there. We started with the idea that we want to broadcast events from one CI system to another. And then we want to be able for systems to just consume those events. So the idea is that we need to have just a common schema of the messages that you want to consume. Also a common set of types. And based on that, you can, doesn't matter what, what is your CI, if it's a Jenkins rule or GitHub, whatever, you can just receive the events. We started, for the prototype, we started to just publish the events on active MQ. So it's just a CI that publicly just publishes the events there. And any CI that is interested just can consume it. So we started to work on a prototype with Jenkins using a plugin that is called gms messaging plugin. Let me paste in the chat. So that's what we use it to just do a proof of concept between open daylight and open FB. So there was the one CI just posting those events using, we had an active MQ there and we just were just posting these events. And then the other CI was interested in consuming those. And then based on that, we were launching new jobs. And after this initial idea, what we are doing is that we are working on a publisher of our own that will allow us to, to be more active or invalidation of the messages and have, be able to provide a common messaging system. For the ones that we need to use, that want to use it. So let me paste again that. We started to work on this project that is going to do the same. It's just going to accept a set of parameters that you are producing with your CI. And you are going to pass the target where you want to publish it. And then it will just publish it in a common schema, allowing other CI to consume it. So this is just a very basic system. What we are really interested on is just on defining the structure of it. Because yeah, we define it like three types of events. So the, we had the artifact level change it. So well, three different types. We have an artifact publisher event that is when we are, the system is creating a new artifact like producing a turbo or a package, whatever. So any other CI's that are interested in consuming that can just get it. Also, we have one that is called confidence level modified. I mean, when you are passing some tests, you are passing unit testing, integration testing, whatever, you can publish your results there. So you can check if you can just count on that this artifact is okay or not. And then we have another that is called composition defined event that is just a set of nested artifacts. So when you publish some release, you have a set of artifacts. What you are doing now is just nesting everything of that. So we came with these three types of events. And then inside these three types of events, we are having like common, common fields like version, like the URL. And then you can have a set of individual, individual fields. So that's what we are interested in defining now. Okay, let me pass the in the chat. What we're working on now is that I'm not sure you can see the chat here. The link to the etherpad. Okay, so that's what we came with. So we will have like meta, meta fields that will be common to all kinds of types of events. And then we can have data that will be particular fields for each type of the event. So in meta, we just are saying what type are we having here. Any ID to just be aware of the event that you consume it. Okay, some version as well, some data time to just for tracking the events that you are consuming. And then you can have like data that are the specific fields for each type. For example, when you are publishing an artifact, you can have an intent that is called locations. And then you can publish all the URLs that you have created when you publish your artifacts. You can just embed it here. And then the external CI that is interested in consuming that we just have the URLs to consume it. And so we are on this now. We were interested on just having your feedback there and see what do you think about the types of events that we define it. Do you need more events? Any field that needs to be included there? So the publisher is done very flexible. So once we define the schema, we can use the publisher and we can just do the integration between the different CI. But what's important for now for us now is just to arrive on an agreement and to see what kind of schema do you want to see there? Okay. So that's what I wanted to show. Thank you. And what is the best way to provide feedback? Or where is the best place to provide feedback? Okay. So I mean, we'll look in the final design, the same ether path. Also a mailing list. We have a mailing list for open CI. So maybe just providing feedback there. Or, I mean, initially just having, adding some comments on this ether path can be good as well. Very good. Thank you so much. Thanks. Any questions or feedback before we move on to the next topic? Thank you. Thank you. Thanks Taylor for posting the open CI mailing list as well. Great. Next on our agenda, we've got packet updates and then VMware updates and Oracle cloud updates. So we have about 22 minutes. We may need to time box for the remaining, if possible, maybe eight minutes per topic. If possible. I've seen a VMware can give up most of it. So I mean, I can, I can do that in 30 seconds. So please distribute that to others. Thank you, Andrew. And I'll do mine in five. Sounds perfect. Okay. Next slide. So cross-coded provisioning on bare metal packet. CNCF currently uses packet to do bare metal provisioning. The current setup specifies a particular data center in which to run the tests. The machines are spun up. The tests are run. Machines are torn down. We are in the midst of, I had hoped to have a documentation for this, but I'll, I'll send it separately once it's, once the release notes are out. The availability of publishing step, provisioning step. So that the CNCF can provision in any qualifying facility rather than a specific facility. This was designed in part with the cross-cloud CI in mind so that if any of our facilities in some sort of priority order has the available capacity for as many machines as are needed, that we can avoid temporary capacity issues by relocating to a different data center. As I say, we're working on external documentation and integration with provisioning tools. I'm trying to make this as simple as possible to integrate, but still, still finishing this up. The, this basically replaces a manual process with a automated process. So that should be good. Next slide. So one of the things that we have ambitions for but is not yet on the schedule is cross-cloud CI using the ARM64 hardware that's a packet. Our C1.large.arm system type is a Cavium Thunder X system. And we have inventory of them that may be growing over the next three to six months. So one of the things I'm looking for is opportunities to deploy part of that fleet to have use for cross-cloud CI for ARM64 at packet. Similar to the bare metal infrastructure, so most of the bare metal setup will be identical. It's just that we're looking at the software support. Largely, the lead on this on the CNCF site has been Hippie Hacker. Typical issues that we need to overcome. Registry support, there's a multi architecture manifest that is used to support multiple machine types in a single manifest so that you can do something like pull Ubuntu and get the right Ubuntu for your system. Not every single registry supports this, but we're working closely with people who are doing registry builds to make sure that they support all of that. Once the registry is taken, care of packages need to also have multi architecture support. This is partly porting things and partly tooling. Actually, it's mostly tooling. Usually the ports are very small, but tooling up people's CI CD systems so that they generate ARM64 artifacts that are appropriately tagged and registered in the registries. Then what's always a question, I think there's a question came up in the notes. How does one test all this? I work on the works on ARM project, which is funded by ARM, which provides both CI CD infrastructure and test infrastructure and development infrastructure for people doing ports or builds on 64-bit ARM. We currently have bare metal infrastructure for that on these same machines. We are actively investigating what it would take to stand up a little open stack cluster so that if people didn't need a whole machine for a long time but just needed a VM that we could provide some kind of VM infrastructure primarily in the test piece of the world and actively working on that as well. And I'll drop in if you're interested in getting access to our cluster, there's information at that URL. We manage the project through GitHub. Essentially, you open an issue on GitHub and describe your needs and we're prepared to work with you to get resources for 64-bit ARM ports builds. And if you need long-term access for CI CD benchmarking testing whatnot that we can provide that as well. Within reason, the pool of hardware is finite, hopefully growing, but I don't want to announce any growth until it shows up in my inventory screens. And that's it for now. Questions? Hearing no one, we'll turn it over to Vienna. Thanks, Ed. That's really interesting. So real quick updates, we submitted a PR to add platform support to the cross-cloud dashboard that was merged last night. There was a bug that was encountered that I submitted a PR for this morning. I tested it looks good, but Taylor will have to verify. And the last thing I didn't necessarily intend to mention it, but Ed mentioned something similar. We are also working on making the environment we stood up for cross-cloud available to others eventually. We're involved in SIG testing to use the environment to provide end-to-end tests for Kubernetes as part of our own proud instance or integrating with their existing proud instance. But the goal is eventually to be able to leverage this environment to provide what I've called on-prem in the cloud, as horrible as that sounds, but to provide real end quotes hardware to people that need to run tests against Kubernetes with hardware configurations may be unlikely defined on places like Amazon or Google. So stay tuned for more of that. And that will be more with, you know, that that initiative is more aligned with SIG testing. But I raised it just because Ed mentioned something that was very similar. So, yeah, that's it. Oh, sorry. Yeah, I raised this topic. I am interested in submitting a KubeCon CFP for adding platforms to CNCF cross-cloud. And I'm interested in seeing if anyone wants to be listed as a co-presenter or submit it with me. It's, you know, we just went through this experience for adding a platform to cross-cloud. And there are a few gotchas here and there. Me without Lucina and Taylor and Denver's help and my colleague, we would have never happened. And I want to be able to both capture that, but also to try to make it easier for people in the future. And I know OpenStack, you added yours, you know, and we use yours as a reference. And so if anyone from there is interested, anyone from Volk is interested, please contact me. It's, I'll put my email address is in the agenda note. Just shoot me an email. And I think that's it for VMware. Thank you. Hey, so am I coming through? Okay. Good morning. Yes. Yeah. Okay, cool. So my name is Dustin Oberlo. I'm an engineer over here at Oracle under the Oracle Cloud Group. And we're, I just sort of wanted to introduce myself and my colleague, Ben. We're going to hopefully be one of the next providers to to integrate with cross-cloud and hopefully get Kubernetes provisioning using the services that you guys have. Yeah, that's really all I had. You're going to see me probably in Slack quite a bit. And it sounds like first steps are to reference some of the most recent providers that have come in and go from there. So I appreciate in advance your patients with with any questions that I might have and any help that you might be providing me. So that's, that's it for me, I think. Yeah. Yeah, I'd like to introduce myself too. I've been like as Dustin said, we'll be having a lot of questions asked either through email on the, the Git project or through Slack. So I'm happy you guys are welcoming us. You'll be hearing a lot from us soon. Great. Good morning. Good to meet you. Welcome aboard. Thank you. Thanks Melvin. Yes. Melvin and Chris Hodge were in charge of the open stack integration. So we've got plenty of folks on this call alone who have been in the code and added their platform to the cross-cloud CNCF.ci. So you're in, you're in friendly company. Looking forward to it. And we're doing great on time. I think we have about 10 minutes. So I'll pass it over to Watson for the overview of cross CD definitions. Okay. Let's see here. Can you bring up the doc there? Cool. So this, this doc came from some of the, the early open. CI conference meetups and everything were. One of the action items was to try to understand some of these definitions. We, we all had different definitions within the CI and CD space. So I just went ahead and went to the continuous delivery book and I just recommend that we just use the definitions that they have within that book by Jess Humble. For all of our definitions, which are going to or should influence the actual messages that we have for the, the messaging protocol that we were seeing earlier. So here, I guess a, I went through and just did just the continuous delivery side because it was a bit easier. There's low hanging fruit there. And within CI, there's a bunch of different ways to do it. And I think, you know, we can go through and maybe grab from the continuous integration book, some definitions there, but there's some overlap here, but artifacts, that was a problem of how to define that. And what, what is it that we call an artifact? Whether it be a container or whatever on environments, configuration, what exactly is configuration and then what is the pipeline and coming in and defining the actual stages of a pipeline. I think we'll go a long way to informing and influencing our messaging system or protocol. So the link is here. We can go through it or I recommend anyone to go through it and add in their comments. These are all lifted directly from the book. So we can debate it and maybe you can say, when you contact the author, I know, I think that's humble is, is some, some people here might know him. So we probably get him to come in and comment on some things. But if I think if we get through these definitions, then we can get through this protocol and then we can have all of our different CI systems and TV systems actually working together because we can get the protocol going. So that's really all I wanted to go over here. Thanks Watson. Does anyone have any questions or comments? Yeah, I'd like to just throw a comment or two around context of open CI for those who are not familiar. So part of this document that Watson's been working on. It's really about so that the hope is to kind of in open CI presents some, some type of standardization or common vocabulary, common context, common protocols, etc. That not necessarily the individual CI CD projects or platforms directly adhere to internally, but as it relates to them discussing or talking across communities, folks who are participating are agreeing that, you know, they want to come up with some kind of commonality. So that as things transfer as, as you integrate, you know, across a community, you may do a whole lot of things differently internally, but this is the expectation of interfaces across communities and people are agreeing to adhere to them to make that, you know, cross integration easier. I see hippie hacker is involved, of course, he's got his tendrils and everything. So that means sick testing is definitely aware of it. I just hadn't heard it brought up yet. I've only been attending those meetings for a month or so. But yeah, it looks interesting. There's been kind of an experiment more or less, but we, we think we've got some good traction with the past few events that have happened. And so July 2nd, I believe the meeting is in the notes for this meeting to basically kind of get some of this stuff out in the open more and start people talking about it. So hopefully you'll hear, hear more about that time or afterwards. Thank you so much. Are there any other topics or consideration before we go through the final three slides? I just wanted to put a bug in that everybody's here for the, for the next meeting potentially. I know that the sick testing is they were discussing moving their singular proud instance to the CNCF at some point. I'm kind of curious, you know, what the, I'd be interested in sort of an overview between the relationship between CNCFCI and sick testing and what relocating that proud instance means for whose responsibilities moving forward and how it might impact the cross cloud dashboard, you know, maybe one learns from the other or vice versa. If there are any plans for that, maybe that's been discussed recently, but it's sort of a newbie. It would be nice to at least have some, if there's a document that points to that, that'd be useful. This is Taylor. I'll speak to that real quick and then happy to discuss more after we've the cross cloud CI project. We've, we've been collaborating with sick testing with the conformance working group and quite a few different ones. There seems to be different audiences as the main focus and the different groups. So trying to bridge those gaps. A lot of what the dashboard was trying to do was show, highlight some of the, the collaboration across the groups and what the testing could be. And that's part of what V2 would be about seeing what would be most useful. The testing SIG has a done a lot of updates on Kubernetes SIG testing has done a lot of work on the dashboard. It still has its own audience focus, but we're trying to figure out where everything is going to go. Also the cluster life cycle on cluster API groups would be some other areas where there's overlap there. Yeah. The cluster API keeps coming up and several email threads that on, on which I'm, unlisted and someone even asked why, or should you be using the cluster API for this PR? Even if it existed, not until bulk changes their settings, we're using what they use. But yeah, it keeps, it keeps being raised. And we attend those. In fact, there's one coming up in two minutes, one of the, the cluster life cycle. And then there's a cluster API call on Wednesday as well. So a lot of different work across the board and trying to see where it lands. A lot of what the, the cluster API is doing is trying to say, what is available fully right now versus what is in development and maybe the next thing. I think that's it for today. I'm going to close out listening. Sounds good. These meetings are once a month, fourth Tuesday of the month. They typically start at eight AM Pacific time. We had a doodle vote out to adjust the start time. So that it's a little nicer for our friends in New Zealand. I will do another one for July 24th and send that out to the CI mailing list. So some ways to continue the conversation after and in between the CI working group meetings is to subscribe to the CNCF, CI public mailing list. It's not very chatty at all, but feel free to join and post, post your notes there. And you're also welcome to join the CNCF dash CI channel on Slack to request an invite. Go to slack.cncf.io. Yes. Is that also the Slack where open CI is discussed or is that a separate? Open CI I believe is not on Slack. I think there's a different tool. Perhaps Melvin can speak to that. Yeah, sorry, I was just typing in the, it's in IRC only right now and hash open CI. Melvin is set on free node. Yes, sorry, free note. It was nice to meet everyone, hear your voices and we look forward to collaborating with you in the future. Thanks all. Thank you. Cheers. Thank you everybody.