 Hello, folks Hosted the meeting notes and zoom chat if you have any items you'd like to Talk about no, I left the arm. I'm listening. I did the status discussion. I think it'd be good to go through that and also Maybe touch on the CNS as well as we we're on the call And the conformance testing as well. All right and in a Be happy for you to join the we do have a weekly CNF meeting on Thursdays that's focused on the CNF test bed and CNF conformance if If you'd like to join us what time is that? Pacific time was that the one which was on eight o'clock or something like that on Thursdays and Yeah, I'm gonna grab you the Meeting notes here. So that's 1415 UTC or 715 a.m. Pacific Okay, so yeah, that should be okay. You keep time Okay Yeah, and that meeting is focused specifically on the test bed and conformance Yeah, I wasn't sure if actually that had been collapsed with the Telco user group or not or if it was kept as a separate invite. That's why I got confused and the The talk from user group you could think of as more of like a traditional user group. So it's where people can Bring problems and concerns are when we're talking about like gap analysis and stuff. So whether What's what's missing from the software that we've been shown and the the test bed is In some ways you could think of it as like a reference implementation, but on a very Maybe a It's not trying to be as opinionated on on picking a specific set of software because we want to make it where Anyone can plug in whatever options they want. So if if you're trying different Network plug-ins, there's a lot of different options or okay The conformance will be about the testing so They all work together, but they're they're separate Hi Denver. Yeah, I'm not saying Ed and this was The one item that's actually listed here is I Have put that the meeting before that had been cancelled. So I Had been put back here as as Ed. So but I don't know if he's planning to join on it. All right. Well, I did try to reach him on Slack on the packet and see and see a slack, but I haven't heard from him. So Do you could you talk through a little bit on on any further work happening on CNCS CI or what activity there's been there or? Sure and I guess maybe to a step back a little bit and then I get back into CNCS CI So ideally this whole meeting What we would be talking about on the next session is What we would be talking about on these group meetings and maybe I don't know if it should be a working group or a user group or what But the idea would be Any type of CI Technology or work that we could share ideas that would be useful across any of the CNCS projects and not specific to the CNCS CI dashboard So when we're talking about this, it's it's one effort, but as you're aware, there's a lot of efforts different projects for doing their own CI which is a separate type of thing and That could be anything from Make if you're thinking working group or we trying to come up with solutions that would help the projects directly or Just sharing best practices and stuff across the group So if there's anything from your end that's Interesting and could be shared then that would be good and I would like to Push the group to be more towards that versus a Stat it's not really a status update for this I know that that's kind of been or where it is, but I think it's mainly because we haven't had people bringing up other topics Okay, that's good. And from my angle, it's really more for how we can Encourage or have more of the cloud native projects having some element of CI or validation on arm or multiple architectures overall And how we enable that to happen. So on the outside, we've we've worked with a number of the CI CI company and frameworks to actually provide access to resource or get them to Operate on our platforms as well. But I think the intent is is predominantly to really enable projects to work seamlessly across architectures, whichever they are Sounds good. And I think as far as the multi arc that's gonna Probably apply in many places. So it does apply to this of course this initiative and Then there's all sorts of stuff within just the Kubernetes Testing communities I saw today Someone talking about the multi arc image support for prowl and making that more available for testing. So I know Those communities are looking at that. I didn't see it was specific to arm, but I know There was the desire for the multi arc images to be made available in other places So that's I think there's probably many different communities for you to come and talk to on that but with regard to arm and Just being More independent of architecture for the CI If you'll have anybody on on your side that could talk about that best practices and maybe this could be a place for that. So if we Say hey next month, we're gonna have someone from arm talk about multi arc support and we could get it pushed to All the different, you know, if it sounds like something you could do and you'll have someone internal We could maybe push it out to all the CNCF projects That'd be something I need to reach out to some of the community people but Yeah, and I did mention the basal work which has happened over the past month on the slacks. So that's Yeah, I saw that. Thank you. So that that's really should that's it is something I know has been An issue for quite some time and that should be a One less blocker for enabling other things and there is work around envoy which is coming together as well So that's in terms of CI. So that's something you will be able to Pass along as well and communicate here too Right And Well, I'll try to address maybe some of the same CFCI stuff and then happy to talk offline and Chris, I don't know if Paterson if you have any items that you'd like to talk about No, it's the first time I've been here to attend. So I'm not sure yet Just as some background. I'm the product manager for GitHub actions. Oh, okay. Awesome. So I was interested in what's going on in this working group and Obviously, there's ways we can help Yeah, it's something I'd love to talk about You know, whether it's, you know, we obviously provide a lot of free infrastructure and we've had some Conversations at least with the community Kubernetes community around prowl, but Yeah So That could be interesting and and maybe If we can find a way to show it a relevant way to fit in with the same CF projects and that would be a topic that we could Communicate It is something from the So I'll just refer to as a dashboard to this CI dashboard, which is its own initiative And If you're not familiar with this and just a quick overview The idea with this is to have And this project is currently in kind of a maintenance mode looking at a Refresh, where are we going to go from here? But the idea is for the primarily the CNCF incubating and graduated projects, although Looking at some other projects how to have a quick view of their most Recent stable release as well as the latest commit on Their master branch or their head On it right now. It's a daily basis. So whatever it was. It's a snapshot view of What's the status so it's be kind of like going to every project and do they have Build badges and other stuff, but we split these out so that we can talk about is it building Is it What does it look like for deployment and then When we're doing this, we're actually saying with the intestine environment. We're saying looking at the latest stable Kubernetes That we're supporting in the environment and the latest head And then some type of combination of architecture and Potentially other run times We had Docker at one point right now. It's just container day And then saying so if you look at the way these kind of flips between those and There was a point where we had some e2e tests, but part of this has to do with working with The projects to get something that's it's relevant and then it would be the full set So it's a query that we're doing The full set So it's a quick like view of where the projects are and then you get links back into the projects and of course they can do more extensive stuff and Prometheus does a lot of scalability things Which should be more extensive than what we're doing, but it's it's just another view of What This the health of projects are So one tying into where things are to answer Philippa Where things are and where it's going so it is in maintenance and we are trying to keep versions updated and And other things but we're looking at where does where do we want to go with this? And the whole project is built in a lot of different pieces. There's a Well, there's the pipeline underneath and that could be any different thing, but it happens to be based on on get lab The different pipelines Sources pulled up stream at one point builds Were all done internal so like and some of them still are so builds Would be tested. So this was about Validating things external to whatever the project did And they were actually rebuilt the binaries create the artifacts and then push them out And the recent projects instead of doing that what we've done is we have integrations to whatever see eyes they're running and I think one of them that would be a Valid new one. I think is Well, I can't recall Denver you may recall which one is moved to get ab actions and was on Travis So now all of the The integration is it. I don't think it's a Etsy day. You recall Denver You're muted. Okay. So I'm Get get back to that in a moment. So the the idea with this move that we've had started to do and Had gone forward before going into kind of a maintenance mode to decide what we want is to integrate with the pipelines from projects and If we look at like this as an example, so they're tough and the tests at least at the time Several months back. They didn't have any arm CI So that's why these are all in a on that and They may also have failures because of the Other reasons but but that would be one of the things so the idea with this would be to encourage and help the projects to get All their builds publicly available so that you have public information so that you can see that the actual binaries are building and passing all of the test and then the next part is and this is a Another level of difficulty is ensuring that the projects publish artifacts At least for releases, which most are going to do in a way that you can say have a doctor image, but ideally they also publish artifacts for their Master builds on at least some of them like Kubernetes has Has has them for every commit and then multi arc they do it for some So we're able to get those if they can publish them then you can test all of these different things and so you're you're basically What we end up with is a health status That's able to allow the projects have autonomy and control over How they do the pipelines, but we help them get there and then likewise for the test would be something similar or The test may be something where they don't want to run the infrastructure for that, but they provide the actual test so we're able to deploy the environment Using their artifacts that they build and validate that they work on different versions of Kubernetes and that's kind of where things were going and part of this as far as going to maintenance mode is to Recheck on what parts are actually valuable to the different projects and then getting the community to Getting to a place where the community can Maintain a lot of their own things in a way that's good for them each of the one of the projects and we can contribute Or collaborate on on how all the pieces work and have enough contributions on that and and that's besides a little bit of the shift on What was mentioned earlier with regard to others fancy F initiatives like the telecom efforts The projects all of it the software is on like this cross class CI which is the base org and there's a lot of different Repositories under there The dashboard is its own thing that gets deployed and the Behind that is what's called the status repository. This is what's pulling all the information and about all the project and Each one of the projects have their own configuration that tie in and say point to the project and Say what architectures they support and stuff like that Prometheus doesn't have the External CI information, but let me see if I can find them quick see in C&I configuration does is try to see I What's that system the C&I configuration Oh, yeah, oh I don't think we have that one enabled but Looking at the it's got it happens to have like see here we go. Well, this one's listed CI system right here Right, right so that this would be an example of that External CI so that's actually part of this CI proxy That we have that integrates and pulls information back so the Github Actions is one of the integrations That we were doing and We actually have a test project that has some sort of Actions so part of this was waiting when as a CNCF incubating or Graduated project going to fully move over and a lot of them were doing a split type thing between Different CI systems for quite a while And I believe that there's a couple of the projects that we were supporting And I think we may have actually disabled ones recently That have moved over So I this would be is If it's valuable to me for then let's do it and then part of it would be contributors to to help with the maintenance of these type of things like Maintenance of the project. We're trying to push as much external So if you looked at like what this is right here Essentially, this is something where potentially linker D2 could host This similar to this file similar to how they would have a get back a github folder with the different configuration We have our own get lab, which is our pipelines, but that's a separate because this is really part of the overall system Yeah, that's interesting So I guess I'm trying to like do you I guess part of what seems like you've been trying to do Is provide infrastructure, which is interesting now. Is there any Anything you're trying to do around Validation or a sort of some sort of official statement, or is it just like Hey, if you don't have CI will help you get it set up So I'm trying to kind of Understand or is it really just this hey you've got CI We we can help validate that you meet, you know Give us your test suite in some sort of standardized way and we'll run it Against some subset of Kubernetes Repose Our versions There's been a lot of different goals from those have changed as far as this dashboard Denver was One of the Few founding members on that but when it was started more than three years ago now Part of it would be trying to give visibility to the CNCF projects There was some initial goals of More like focusing on interoperability And how do we do that and tie these all together was part of that and there's still some possibilities in that especially If we externalize things but when you were building it all together and saying We're going to have all of these things running in the same environment And we're going to do all the builds for all the versions the matrix of How things all fit together and different versions you could say stable envoy and fluently but everything else is Going to be on the develop branch well It starts getting more and more complex on that so That kind of shifted away as far as goals although it's more there if we say it's focused on the testing and you don't have to do these because these are external But so marketing Tying in like pushing like how to what are these looking like these are CNCF projects that you could see that and the health of those How they work with Kubernetes and different versions and if things are broken so if you say and we've seen that so we've seen like a head version of Kubernetes and different projects start failing So some of those were the goals And then it's not really about providing The resources at this point and that kind of shifted very early on to say we're going to provide a CI for the projects Because of the CI needs Prometheus like I said needed massive scaling But test needs its own type of thing with the heavy hits on on the storage side and the different extensions So that moved away I think at this point if you were looking at What the working group which would be separate from the dashboard so the dashboard is not the working group From the working group side what's still listed if you go look at the CNCF SIGs and working group page Is somewhat towards that you could say helping CNCF projects and part of that could be helping build their CI out But that's someone spread across CNCF efforts like there is a you can request for lab infrastructure Now that's separate from do you actually have a CI system? Do you is there a CI? Platform setup that's Generic enough that's going to meet all the needs of every CNCF project. That's a big undertaking People have put stuff forward but so far. I don't I don't think anything is a perfect fit I think what would be more likely Chris is If we could say here's right now to rather than saying we're going to take it all on and solve all your problems with one thing would be Providing a place for people to get started and have options that are easily available. So if they said Where can I run any of this? Well, there is CNCF If you look at the CNCF IO on the community section They have an infrastructure lab This is fine from a top level But if we said from a working group side, we could probably group these and say Here's some places that you could run stuff And then if we look at what are some of the things that you could do Here's some places that you could run stuff and then if we look at what are some CI pipelines that we could use Maybe if we had a section that talks about how you could use of actions Along with whatever else people want to do and I know from the arms side there's There's a lot of efforts on self hosting as well as using hosted versions But I think something like that could be used at a much higher level To be useful across all CNCF projects Okay Yeah, that seems reasonable like I don't know feels like Like if I'm sort of break this down like I mean in the end everybody's artifact needs to be a container like how however it is you get there you get to a container I think the part that you talked about that seems interesting at least from a working group and like how The CNCF would support projects is that testing thing and I think the dashboard is interesting. It's like hey The question though is how do we do it in a way where The working group is really doesn't have to Build out Infrastructure is the right word but like hey you provide your tests in a uniformly consumable way. It's like You know you provide your deployment in a uniformly consumable way and your tests in a uniformly consumable way and will Generate and run a pipeline across some set of versions of things and give you a green or a red based on what that is seems Really interesting the build Part feels like yeah, it could be there, but totally should be external like it doesn't make any sense in my mind for The work CI working group to be actually managing or providing anything about the pipelines. It's really more like Well, you do your build. There's lots of ways of doing that You know And the output is yeah Your container in some place that we can pick it up. I don't know Yeah, absolutely. So that's what you're talking about is as where we were headed and What you know, this is I don't know what we call this Denver the v2 or v3 I know there's internally. There's been so many revisions, but The next iteration of this is what you're talking about Chris where The pipelines are externalized and The focus and we have a lot of design around the efforts that we did Documentation on like what would artifacts look like and This what you have right here is kind of a hybrid where we were Essentially prototyping it so the external proxy part which is working We didn't expose this but you would ideally the links like from tough wouldn't go to Our system which is running it. This is what how do you actually run the software together it But instead the links would actually bring you directly to wherever tough is which happens to or the test I'm sorry. I brought it test and for the test that happens to be Travis. Okay, fine And then it you click another and it goes to, you know, get abaction to click another it goes somewhere else So you could ideally click these and they go wherever they are and on arm it may be totally different Maybe they have integrated and they're running it in the same CI pipelines or maybe it's on a totally different system That's fine But the idea was to externalize that and send them out and then yes, like what you're saying on the testing if if we have a good format Where we can talk about that core DNS worked with us initially and was very interested in doing that and Prometheus somewhat to Of what is the good format that we can provide our our ED test in and the ones that we did run were in a container as far as those parts but the main thing is describing the format and everybody can say, okay, we'll make sure you can start us up in the way that you say, then we'll handle the rest As soon as we have that we can pull those in and run them against the deployed artifacts You don't see it in these particular links, but we have other places where we did work. We're saying how do we tie in the artifact from the test and that would be the next This if we go over to x86. So if the test didn't do it. But if we look at like the another one we say, where is the artifact we found your build it passed where is the actual artifact for that build that matches that it's actually for the commit. So we will deploy that into our environment. Then we're going to run the set of a to e test and ensure that it passes. And what what this would be similar to is You can say Kubernetes Eat a test or the conformance test specifically, you can run sonnaboy on your own Kubernetes cluster and get the results, but you can go get the Kubernetes artifact that you want directly from Kubernetes. So that's the idea here is we're saying, we're going to run it ourselves and make sure Your staff works on these different versions. These builds work with a deploy to Kubernetes and ensure all of those works. Beyond this, maybe we decide we would love to see core DNS work or Prometheus working with Kubernetes and Jaeger and all of these running together. But we do it. It's complex enough that if you do it all internal, then it's the maintenance of it is is too much complexity and everything else. And that's, that's how we're shifting over makes sense. Okay. I don't have any great ideas right now, but that's interesting to know. We'll get to know they're still interested in it. And I do think at the top level if we can break down the different offerings that we have, we can break down the different offerings that we have. Interesting to know. We'll get to know they're still interested in it. And I do think at the top level if we can break down the different offerings and pieces and the dashboard would just be one of those. So we say we're not going to run your actual pipelines, but we'll consume them and show how it works. And we'll also tell you best practices on how you should publish your artifacts as containers. Here's how you can do it. Here's some examples because there are examples that you can see out there on when they publish and how they show it. So we'd also, we'd also like to push CI systems that don't make it easy to communicate what artifacts were published with the pipeline because they don't all do that. So if you have a successful build and you create an artifact, it'd be nice to have that metadata in the pipeline. So if I come in and reference the actual pipeline. Okay, okay, what's your artifact? Oh, it's here. That relates all the way back to this commit. We're good. And then you can keep creating. In the end, what you're talking about is potentially confidence for someone else that says, I'm going to use Envoy and Tough and Vitesse. And I want to see how it all ties together with the different commits, builds pass, deploys pass, EDs pass, so that I know that my deploy of that combination into production as a customer is good. Okay. But we've got to have the base systems and feel confident in those. Yep, that makes sense. Alright. Well, if y'all would like to think about it, maybe we focus on something for a next call or something next month. And if you want to talk to anybody from the arms side that wants to present on it. Arm items and I'm sorry, fleet. That's not with us. And and from the arms side and then I don't I don't know what you want to talk about either from the get upside or I'd be, I think it would be really good to look at what type of CI. I hate to say services because then people say they want to call up support and ask you to do something that's not really talking about but what type of things can we help with as a working group. That would be useful. Okay, yeah, I'll think about that some I mean I might be some based on what you like I like your ideas there I mean I think that some best practices some examples of how to use different things. And it's the other side I mean I really like the idea of like a dashboard is interesting because it's, it's kind of for the projects but it's also for customers of the projects it's as much. You know in my mind, both of those things because if that is a reliable source of some amount of compatibility, you know centralized compatibility and viewport testing that customers rely on. Then you know it also incentivizes the projects to, you know, make sure their stuff is in good shape might be another way to look at it. Absolutely. That's a good way to view it. Yeah, like says my first time here so I just kind of trying to understand the land land and what the work you're trying to do and obviously happy to help think about ways that, you know, actually get up can help out. Sounds good. Thanks a lot. Well, and unless there's anything else I think we could end here and decide on next time and we'll update a section for adding agenda items. Anyone wants to put them for the next call. Okay. Thank you. Cheers.