 Hello. Hi, everyone. Welcome to the Seek App Delivery Meeting. And my name is Li, and I'm co-chair of the Seek. And very nice to meet you guys. And just a reminder that the whole meeting process will be recorded, so please agree on that. OK, so we do have some very important items in today's agenda. And first of all, we'd like to know the recent update from the AirGap Working Group. Because I remember last time the AirGap Working Group talked about the working partner. And we also talk about that. We need to approach the community to get what's the recent practices of the AirGap delivery in the current ecosystem. So I'm not sure the team here is from AirGap Working Group. Are you in the meeting? Yep, I'm here. OK, cool. Yeah, so I guess our update is we had one meeting so far, one official meeting after many, many doodles figuring it out. And we've just started a charter and a couple of documents that we're building that are linked in the agenda for this meeting that you can take a look at. The first two items we are targeting is collecting our users how they are currently installing Kubernetes in AirGap environments. And we're going to collect those use cases and develop a best practices document. And we're doing the same thing for chain of custody. That's one of the biggest concerns that people have with AirGapT is how do they consume upstream artifacts and maintain chain of custody when they've written an AirGapT. So we're starting another document for that and collecting what people are doing and how they're doing it and help to come up with best practices for that. So that's kind of the first two things we're focusing on. Either those things interest you. You can either fill out the document or you can come to our next meeting, which will be this Friday at 10 o'clock AM Pacific. And that's kind of our update. Happy to answer any questions. We can contact with CINSAVE to advocate all these documents. Yeah, at some point I think we need a waiver. We can store them. We could actually make a page on the GitHub repo where we store working graph documents if we wanted to. Yeah, I also agree. Did you just notice new house? That's not my new house. I wish this was my house. This is actually a $25 million villa that I've built on the internet. You know, right now everything is fake, so that's the actual thing. Interesting, OK. But I can also move from another room. That's funny. Yeah, so we can actually have working documents. We don't put a lot on GitHub. I was just looking at the GitHub repository. There's nothing really there. And we could make subfolders for the individual working groups that they can post all their documents there. So I think that would be a good idea. Yeah, I agree. Yeah, I can do that to create the folders and everything. And then you can file a PR against it. For those who don't know where it is, it is actually here. But that's good because that was one of the comments in an earlier discussion that we don't have a lot of things online, actually. So this is our, in case you didn't know, we have a GitHub repo where we can store stuff. So we create one subgroup. I'll take this as an action item and expect it within the next couple of days to be there. All right, so I think we can move to the next topic, which is about the operator working group. Not sure if the co-chair is here, if not. Yeah, I can also give an update because I was part of the meeting the last time. So yeah, we have two volunteers now who want to chair that working group. As mentioned in the doc as well, let me post the charter here for those of you who haven't seen it. Sorry, too many documents open right now. OK, so I can look. Just give me a second. So the list is impressively long of people who aren't there. So Garrett and Mark volunteered to chair the working group. We have already, we should have already received a meeting invite. I think it's every second Thursday that we set up that meeting. And the first work item for the working group will be to work on the operator definition that we started a while back and then dive into other topics. I think there's some additional comments that Matt posted in there that should also address in the next meeting. And overall, we should bring it up in the next update to the TUC as well that this one's forming right now. So not a lot of work done yet, but there are scheduled meetings on the calendar. We have people who take care of the work as it's going to be done. And first topic definition. Then further topic should really be also collecting the best practices. It was one of the big discussions. There are lots of best practices out there over how to write and structure operators and also helping some other people on developing operators in case they need support and then eventually moving into more of like an interoperability type of discussion. And also obviously interacting with other projects. We already had this discussion between operators and AirGap even, but there were some issues there and also with some other communities related working groups that there were certain requirements and that the working group can bring up these topics and were also discussed. And the flow should be the working group brings it up to the SIG, the SIG can help to engage with the other projects. What we deliberately removed as non-goals is that we're not going to obviously write our own SDKs for building operators. There is already quite some out there. We don't want to create yet another one. And per se, it's also not the goal to recommend new projects that should be added to the CNCF for the time being. And also excluded everything that's non-cubanese-related operator-wise. Yeah, so that's pretty much the work that was done there. The more compressive thing is I think the list of people who are interested is longer than one single page. So I expect hopefully things to move forward rather quickly on this workbook. I'm still marking the writing hand. Go ahead, Matt. I just wanted to note one thing. I think you said the meeting was on Thursdays. According to the CNCF calendar, and it's listed on there, it's on every other Wednesday. That can be as well. I might be wrong. It is definitely on the calendar, so I might be just wrong about that one. The first one was on the first day, so I thought. The first one was on Wednesday, is what it says on the calendar. I missed the meeting. OK, you're right. Yes, the next one is your write is next Wednesday. And it's 6 p.m. GMT-1. And this and the air gap meetings are on the CNCF calendar, or the TOC. So if you go to the TOC GitHub repo, and just in the read me, there's a calendar link there. If you go there, it has every meeting, including these working group meetings on there, if you're trying to find out when something is. All right, that's it. Yeah, but thanks for pointing it out. But yeah, we have all of these scheduled. And let's wait for the next update in two weeks from now. Don't expect too much progress over the next two weeks, but let's see how far we can go. I also noticed that in the definition of operator work, we actually did not mention what's the difference between controller and operator. That was one of the big discussions when the question came up, what's the difference between a controller and operator? And the other topic was, can something be an operator if it's not using a CRD? OK. Despite the correct definition, it does not. But we had a discussion about flux. Flux uses a GitHub repo. So it's like, would flux count as an operator, or doesn't it count as an operator? So I think that discussion will be interesting. What's the controller, and what's the CRD? OK. That's pretty much the update. Yeah, I think the operator working group need to raise a wider discussion about these fundamental issues. We may want to collect some feedback from the community about, OK, what is your impression of operator? Because I do talk with several guys from the community. And the feedback is more like the operator is for you to install a software instead of operating a software. I think that is one of the common misunderstandings about the operator we are talking about today. Not to mention the day two and day three operations. Is still considered an autoscope of the current operator implementations? Yeah. I think what we should do going forward here, once we have a first definition, we need to get back to the TUC anyways and ask the TUC for what they want to see. Right. OK, so let's finish this topic and go to the third one. It's a big discussion actually about Harbor graduation review. And we talked, I actually talked with the TUC about this part. And I think it's more like a collaboration review from multiple sticks, for instance. I'm not sure if there is anyone from Vimeer to give us some more feedback. Yeah, OK. I'm right here. This is my call. I'm one of the maintainers of Harbor. And I'm the one that added it to the agenda for today. Essentially, Harbor has been up for graduation for the last six months with CNCF. And we had to go through a set of reviews by Sieg Runtime, which gave us thumbs up. Sieg storage, which had one concern, but then that everything was good with Harbor. And then we're undergoing a review with Sieg Security now. Quinton had said that maybe Sieg apps or Sieg app delivery should also review Harbor. I personally didn't see a connection there. But following with the CNCF guidelines, so I wanted to talk with you guys and see what kind of review you can do or with what context in mind, since you already had three other Siegs review Harbor. The ultimate goal here is for your Sieg to either give us a thumb up or thumbs down or something in between on our bid towards graduation with the focus of what you intend to review. In the meeting notes, I added a couple of items like our PR that we have for graduation, the Sieg apps review ticket that, I believe it was Ricardo that created it. He's from Sieg Runtime. And then also the due diligence document, which is some, if you want to review Harbor, this is basically how you get started and it's a fairly comprehensive document that talks about the CNCF graduation requirements and how Harbor meets them in each one of the different categories. So what are the thoughts from this Sieg and I know that Matt has gone through this process with Helm just very recently. So I don't know if you have any thoughts on that too. Can I first jump in and just say something real quick. As somebody who's gone through the process of putting this together, it is incredibly laborious to collect all of this information. Are pretty small. Can you all hear me? Yeah. Yeah. No, no, I heard it. The benefits are pretty small going from incubation to graduation as far as you as a project have and the amount of work you go through. I want to commend you for putting this time in. You did more than I did for Helm, especially going between all these Siegs. So I just want to call out and give you props for having the energy and the stamina to go through this for so long and to do so much work and to write this up, stuff up so clearly. Like your due diligence is what 29, 30 pages. That's incredible. And so props to you for going through all of this. That's all I wanted to say. Yeah, thank you, Matt. Appreciate it. Yeah, from our side, maybe what we can do as a Sieg. So I don't actually see any issues that would be bringing up what we can do if we have to share the due diligence document. We can also provide, usually at the very end, we provide the, that's this recommendation section usually. And just give us maybe a bit of time to read it through and then we can make the recommendation from our side as well too. Yeah, I actually read through the documentation before and I also made in person with Henry from Veneer about this project. So I do have several questions about Haber if you guys can provide information on the documentation. So the first of all is, I would like to see what is the current artifacts in Haber? For example, are there all dark images or there are some other kinds of OCI artifacts stored in Haber? Do you have this data? Yeah, I can answer that. So today, Haber, our latest release is 1.10. It only supports home charts, some charm museum, and then it also supports container images. Our release of Haber 2.0 that ships this month, actually about three weeks away from the release, is fully OCI compliant. So any OCI compliant file can be managed in Haber. That means you can push it, you can pull it, you can replicate it because Haber has a very extensive replication engine, you can enforce quota management, you can enforce retention policies, you can enforce RBAC, so all the features of Haber apply to full OCI compliance. And that's, we actually have, we've been demoing that for the last few weeks, also our scanning capabilities apply to OCI compliance. So for example, if you have a CNAB bundle, that's a thick bundle with four or five images in it, we can open it up and scan the individual images and give you a compliance report on them. Yeah, I think that is the most important thing for the CGAB delivery is caring about them because Haber now can be used as a distribution center of a software. As you mentioned, it can be any kind of OCI compatible artifacts stored in Haber and you can distribute software from that source. So I think it's important to add this part of information in the due diligence documentation and I think the co-chairs of CGAB delivery will also pay attention to that part of C, okay, if Haber is a good candidate or is there anything to need to be improved regarding to acting as a software distribution source like Docker Haber, right? So I think that is one thing I want to check out on the documentation. And the second thing is about the scalability of Haber. So I'm not very sure about how many nodes or how many, I don't know the matrix that you guys use in the Haber. So I do, yeah, I do so there is scalability part in the documentation. So have you ever considered about the scalability maybe has some matrix related to software distribution because today what I see is more about, okay, how many nodes, how many resources, matrix the Haber uses that have ever considered about, maybe you can add some part of the scalability from the application or software distribution perspective. Yeah, so we basically do scale testing from a few different angles, right? So one of it is from the end user, think the developer, how many concurrent push and pull operations we can do, how many images we can manage, you can manage 100,000 images. And we actually have customers that have terabytes and terabytes of storage on Haber with thousands of images and that works fairly well. From, if I understand your question correctly, you're also asking, Haber can be in a hub and spoke model, right? Where Haber, you can have a single Haber instance in the middle, which can enforce your policy around scanning and compliance and then you can replicate those images all over the world from the central location where you have clusters on the edge, just like folks who wanna put a Kubernetes cluster on the edge, you might have a harbor instance on the edge or if you have assets in a small, medium data center all over the world, you wanna replicate them. So central harbor does all the computer on scanning and compliance and then it populates the images to other harbor instances or even other registries so that they can be utilized by developers. Harbor is horizontally scalable, our services are stateless, so we have absolutely no problem scaling to this and we have, even though traditionally most of our customers only have two or three of these dumps that they replicate between, we have tested with combinations of many, many replication, let's call them replication workers that replicates images all over the world. But typically, customers only have two or three so they have a couple of data centers they use them for jury redundancy and they replicate their images across that. We haven't seen people start putting Kubernetes clusters on the edge yet at high volume where they also put harbor on the edge. Okay. One thing I wanna mention that since we're talking about the edge our 2.1 release of harbor which we already started working on now it will probably ship prior to cubicon if not much earlier, we're actually gonna enable proxy caching capabilities in harbor as well as P2P distribution. So that's specifically targeting the edge scenarios. So if you are putting a Kubernetes cluster on the edge where that's a 5G that's with 5G that's gonna become more and more the norm then we'll enable you to put harbor there will act as a hot proxy cache for the images that you care the most and then it will push them in from the main data center. And then we can also use P2P like Dragonfly and Kraken to push the images there in a more efficient fashion. I see, I see. So yeah, I think my question about I think you can do some more calculation about to make the metrics more end user facing so the developer will know, okay I have maybe 1000 node cluster I have one million applications to distribute then what kind of harbor architecture I need to use what kind of, how many nodes for harbor I want to deploy so it's more like end user facing metrics I hope to see in the documentation. So that is the second question. The third question is actually you mentioned I also hope to see how harbor corporative is the existing software distribution technologies like Dragonfly, right? You know, Uber also has similar project which kind of bootstrapped the image distribution. Right now, I noticed that this part is missing from harbor so what is the current status of that integration? I mean, I just answered that, right? So I said two to one will have integrations both Kraken and Dragonfly so that Kraken is from Uber Dragonfly from Alibaba and we will enable the P2P distribution of those images. A lot of that work is not dependent just on harbor, right? It's also the communities from Dragonfly as well as Kraken to enable that integration but we're already working on it. I think we have a couple of POCs already that show demos of that work and then specifically for Dragonfly we've shown that demo already and then the proxy cache capabilities and I think Matt is raising his hand. You're doing it. Yeah, yeah, so when I hear some of this what I'm also wondering is how much of this is part of the graduation review or kind of just a broader discussion, right? So I heard something that was a suggestion for docs to do better improvement on docs and now every project can have better docs. Every single project out there is this something that should be filed as an issue or is it something that should be part of a graduation review? That's kind of where I'm getting to this whole thing. Is it a mature enough project that it meets the graduation criteria or are these incremental suggestions for improvements which every project is going to continue to have? And I just want to kind of keep that in mind. So a project that's under massive scrutiny. I mean, they're going through four sigs for reviews and lots of opinions are coming around. How can we kind of keep the graduation criteria first and the other things, we kind of note that there's suggestions I should go in issues but they're not a graduation blocker for them. That's the only thing I wanted to bring up in mind because I thought like the doc suggestion is a fantastic suggestion to file as an issue over there but it's not a graduation blocker kind of suggestion. That was my only thought I wanted to jump in with. All right, I'll be quiet again. Yeah, I don't see there's any graduation blocker we're talking about but you need to give an input on your documentation to let the CIC to know, okay, what kind of functionality is your project related to the CIC? So it's better to have that kind of input so the CIC can do the review. So it's kind of that kind of discussion but that also possible that this part of information can be a blocker for the graduation. So just keep that in mind, okay. Yeah, this is actually three questions I read through the documentation. I hope that, you know, Harbor folks can add more information about this relationship with the software distribution because I personally can see their relationship. That's why I think Qtun is recommended that you guys may want to go to a partially CIC app delivery. Yeah. Yeah, and like I mentioned, you know, the Dragonfly and Kraken proxy cache they will be well-documented with 2.1 chips. So that's guaranteed. Yeah, yeah, that sounds good. So, maybe I'll... Go ahead, Ois. I think we're fine on adding our statement to the review but this is a match point here. Things might not be part of the review but the kind of the graduation review but I think it's still an opportunity to get some feedback from the CICs which we can provide on certain topics and in this case they're well covered and the questions came up. So please also take it as input that might make sense for some of these things and not just as a graduation blocker per se. So if we take the time to discuss topics I think it makes sense for all of us to share feedback as well. Yeah, they give us time and we cannot have... They generally give us time and we can have that additional note down there but I'm not sure where it is, like massive blockers but obviously the ACI compatibility was one mentioned by Harry that... So, yeah, one of the things I've seen work with other CICs is assigning an owner from the CIC that's responsible for kind of shepherding the review and gathering feedback and providing it. Without that person, usually I've seen that the process takes time, like a couple of months sometimes. So is there someone from CIC App Delivery that wants to... That doesn't have a conflict of interest. So for example, it cannot be Brian Lyles who's not here now today but who can basically own this and say I will shepherd the feedback, go through the review and give the recommendation. I think can just assign me as the contact person for Harbor Project if you have not approached anyone before. If you have, then you can just continue your process. If you did not, you can just assign me as your contact person for the Harbor Project review. And of course you can get all the feedback from any user community but I don't think that's related to the graduation process. It's not up to me to assign them if the CIC App Delivery review guys are okay with that. That's the CIC that decides that, not me. You have a two-thirds majority here that's here, so I think you're good to go. Yes, you can always ping me on the slack so I can be the contact person if it did not have anyone before. Sounds good, I'll have you. And are you thinking what kind of timeframe just so I can also set expectations on our end? Is it like a couple of weeks? I may have several other questions about the detail. Oh yeah, absolutely. So maybe I think we can, I think we hopefully can finish all of this work in one week, it should be quick. Thank you. I'll ping you on slack and I'll be able to answer all your questions. No problem. Question, are you going to be doing the review in Google Docs or over in GitHub? Just want to be able to know where to track this. So, sorry, where did you have the other six review? Because for us, usually Google Docs work better for commenced than separate, but we can do both. So Michael, if you have already done it on GitHub, we can also stick to GitHub. My document is at Google Doc, but ultimately what has been asked is that you put your feedback in a GitHub issue. That's the GitHub issue that's linked in the meeting notes as well. That's fine, I just wanted to know where to be able to track for progress. And if I need to go hunt through Google Docs, that's fine, if I need to go hunt through GitHub, that's also fine. Let me know, thank you. Okay, looking at the agenda, who put artifact hub on this one? I did, this is Matt. So I wanted to talk about the artifact hub because it is now being proposed for Sandbox and the issue had it assigned to SIGApp delivery. That's a nice one. Yeah, surprise. Yeah, surprise. So I'm happy to walk through and talk about it, however you all want to proceed, but I did want to put that up there. It's fine, so I think yeah, we can start with the review document or artifact hub. I think there are some questions open around artifact hub. What questions? We should get them documented on the poll request or the issue so that way they can be answered for everybody. Yeah, my first question, honestly, about artifact hub is even for Sandbox, who will be the long-term maintainer of this? Is this now CNCF internal long-term maintained? Because there's no, unlike other projects, the CNCF hub was created out of the CNCF and put out to contractors that used to work on it and what's the long-term maintenance strategy that would be the first one for me? Well, I guess the first thing is we're gonna work to try to engage more of a community around this, so it's not just long-term contractors, but we have not worked out all of the logistics on that yet. And I don't know for a Sandbox project if that's a requirement, but that's one of the things that we're gonna look to to engage more folks who want to, but it may be a mix of contractors, it may be a mix of other people. I don't know, we've got, the CNCF has contractors who work on lots of code bases for it. More than I originally knew, that's kind of a Linux foundation thing. They do regularly have lots of contractors working on things, even over in like the open containers initiative. Like I know somebody who's doing work over there. So we hope to have a mix long-term. Right now, the project is just being heavily sprinted out by a couple of contractors and they are doing a wonderful job, but in the near future, we are planning on going into a wider release. We're not exactly sure when that is, more when it's not so pre-alpha, it's probably more alpha or beta, right? When you think of like a Google beta, it's rougher on the edges, but it's ready to go. We'll go to a wider audience and we'll start looking for more, more basically web developers to come do that, which is a different sort of thing for the CNCF. So we probably won't be picking from the normal CNCF folks who do infrastructure things, but other people at those organizations and stuff like that to engage on it. My long-winded answer. So, I mean, obviously we can go deeper on the review. I think it would still be good to, if you go out there and could engage or recruit some people from CNCF member organizations that are willing to actively contribute, especially given that some of the member organizations initially saw it more or less as a competing project to what they have put into the CNCF and they're working on. No, it's not necessarily a requirement, but still for Sandbox, it must be insured that there's like long-term interest by somebody working on it. Yeah, and we're going to go out there and find people who are actively willing to contribute, especially given all the TUC related discussions that were held around it, just the recommendation to you guys to find somebody. Yeah, and that is in the plan. I'm meeting with the end user community later this week because we're not just going. So one of the big benefits here is for the end user community, for people to be able to discover this. And so we're actually, I've met with some of the end users and I've met with the end user community where I've got nothing but positive feedback on doing something like this. And so that's one of the areas where we will go look for folks to engage on it. Right now, again, it's in its early stages. So we are doing this, but we're being slow about it, especially as we spike things out and make lots of changes, but it is in the planning. So I'd be curious at this juncture who the we is that's working on this because it seems to be a party of two or three people, the contractors and yourself. And so, you know, one of the requirements for sandbox or incubation or anything else like that is that there are active participants and contributors to the project. So as we go through the review process, I think as Eloise is saying that it be good to have more committed people working on it than just yourself. Yeah, and those are not requirements for sandbox. For the sandbox level, having people from things like multiple organizations are not requirements. It's one of those things. In fact, in the sandbox requirements, it actually talks about things that were commissioned by the CNCF to get going. Those are candidates for experimentation, which is what the sandbox is for. And that's why you can easily archive things out of the sandbox if they don't go well. And so given the current number of people and structure, it does fit per the sandbox. And there's a separate sandbox doc that just goes through all these things. It does fit some of the criteria in there, which is something that I didn't notice at first. Other people pointed out to me. Still, I would like to see more contributors to this project and more folks actually committing to work on it with you. Certainly, it's still not a requirement for sandbox, according to the sandbox documentation. And that's one of those things. I know people who've done reviews around sandbox, who've been asked to do things that were incubation level things. And so for this, I'm really focused on the criteria that is sandbox in this case. And so, well, we are gonna go out and try to find more people. This does currently fit the sandbox requirements, which is what I'm focused on. Yeah, I would still recommend, what those have did for other sandbox projects, see how far along they are on the incubation-related criteria. You don't have to do it, I know. But especially with a project like this and the background and all the concerns around it, I think it would still be good to address these. And just don't go by the books here, but we have obviously people here who are concerned about how this whole thing came to life. And as you're obviously the one driving this forward, I see also you being responsive for handling concerns by people, because as a community here, we should listen to concerns from other people and try to help to overcome those concerns. So that would be my recommendation here. So as you're preparing for sandbox to also address these things. All right, I don't know that. And there's like a healthy flow of commits from different people, how you're engaging the communities, how people can be on board. But I guess it's all a list of stuff that still also makes actually sense for a sandbox project as well. And yeah, definitely. And I think it's still also good to have maybe a bit more of a deep dive presentation on Opera, I want to say, all right, there we go. That's not what I wanted to say. See, I'm still struggling with the naming here. Bit more deeper presentation where you want to go, what you want to do like for the app delivery working group. Just as a general information, as it fits in here and where you want to go, that would just be my proposal. Doesn't need to be the next time, but I think it would still be good because a lot of people have open questions still and to give them an audience to ask these questions. So Matt, you can think of maybe you were together with somebody else who's working on the project, doing this the next meeting or the meeting after. So what kind of information are you looking for in it? The history, the purpose, that kind of information? How it's built, what it's doing? Like what kinds of... How it's related to other CNCF projects. Yeah, these things are how it's related to other CNCF projects and projects, what your roadmap is where you want to go. Even if you say you have end users, like who's like using it right now would be interested maybe as part of that conversation as well. Okay. Now note the end user part is an incubation level requirement as far as those kinds of things go. So I'll drum up some things on that, but end users is an incubation requirement for those not familiar? It is, if you have it, I would still recommend it. You know the background of this and you know the discussions around it. I do and I know that this was started as an experiment that's in pre-alpha. That's not targeting lots of end users at the moment because it's attempting to get up and going before we shoot after lots of end users and fill out some of the rough edges. And so right now we haven't targeted a wide launch yet and that's why it's very much an experiment at this point. And so it's not trying to be an incubation project with lots of users and we will be getting there and then our next meeting will be talking about exactly that to come up with the timetable. But at this point in time, we have not targeted a wide launch with lots of users because at that point you've got to stop doing some things like breaking changes and things like that. It is very much an experiment in the terms of a sandbox experiment which is one of the things the sandbox projects are for. And so that's why we're not gonna have lots of end users. We're not targeting it. We're targeting the experiment phase. So I'll attempt to talk about that portion as much as I can and we'll see how far we've progressed by the time I come to present on that. Yeah, thank you Matt. Are there any other questions or comments on this? Yes, so what I'm hearing about you are not targeting for large scale user even for now or for long term? We do plan on going large scale. I mean, the Helm Hub goes out large scale right now. We've got, I can't remember how many organizations have put their things in. And so large scale of users of people presenting things and large scale of people consuming things through it both as a hub and it'll also be packaged up for people to take a look at. But the primary is the public hub at the moment. And so when it goes to large scale, the idea is to be able to serve people around the world and many geographies in that way. And so it's a little different than many of the projects that come through here, which are meant to be primarily self-hosted. This is kind of a different style project. So if I understand correctly, so you're saying that you want to make the artifact hub as successful as Helm Hub? Oh, far more successful than the Helm Hub. That's my goal. Far more successful than the Helm Hub. I got it, I got it. Because we're gonna list things other than just charts in it. So I was at the OPA call earlier this week and we were talking about how do they get their things listed. And we talked, you know, it was just a back and forth. I presented what we're doing and talked to them about how they would want to proceed and they very much want to have policies listed and discoverable. So it's gonna be more than just things like charts and applications. We're actually looking at how do they do policies? And they've been talking about sharing policies and they've got a couple of different ways. And so they're gonna come back to us because we gave them options. We will do everything in the artifact of ourselves. You can come up with things you want. They're gonna come back up to us with what they would like to do. And they're working through that now. And so you'll be able to discover hopefully policies in there once they work out how they wanna go about doing that. And you could have different organizations sharing their policies, even as starting points and things like that. And so that's one of the bits that we're doing. And so somebody who's not just looking for a helm chart, somebody who's looking for an OBA policy will hopefully be able to go there, search for it, filter on it and discover those. I think that part also need to be added in the goal or motivation for the project which I think it missing from current proposal. What is the goal of the project? It's currently missing from the proposal. The proposal says what is this hub is for? Anyone mentioned that the goal of the project is far? Okay. In the poll request, the language I have announced is the goal of the artifact hub is easy discovery of cloud native artifacts. For example, helm charts, Falco rules, et cetera. And to provide information about the artifacts so that end users can make decisions about using them. And so- Kind of different from what you mentioned. What do you think from? From what you just mentioned. So what you just mentioned that the goal of the project is far popular than amhar. Oh, I think that's kind of a personal thing. So from the helm community, if the artifact hub takes off and is legitimate, we will be deprecating the helm hub. We've already agreed to support that. If it is able to turn into a real supported thing with use, we will be deprecating the helm hub and pointing people to the artifact hub as the place to do it. And we will work on things like, so the helm client right now can search the helm hub. You can use helm search hub and then search for something. We will gladly do things like point you over to the artifact hub to search for charts. So that way we don't have to do duplication. Our hope is this can take over. Functions are missing from the proposal and I think they are important. So I'll try to add more of that. Like the helm comment is further on in the proposal that's in there. I'll try to find and bubble some more of that up. But that is in some of this is in the proposal. Right. And the second thing I found is missing is what you are looking for from since this, right? It's a common question. Why we want to move artifact hub to since this, that part is missing from the proposal. And you know what's interesting? Now that you say that, I totally get it cause I've told people this in the past and I was going based on the structure that I was pointed to in the templates and process documentation, which doesn't ask for that. So I can, I don't think it should be part of the template. It's just a question that we are asking and we hope that you can add that part in the proposal. No, no. And I totally agree with that. But I think the interesting thing is in the process documentation. When I was walking through it, either I skipped over it or it's not there, which may be why projects aren't including it. It's not thought of in just the process that I need to write that down. No, that's a great question and I will write something up on it. Yeah, go ahead. Just do that. Yeah, that is two questions. I'm just raising my head now looking at your proposal. Hey, this is Rob. I had a quick question. I know that we had a call and the Chris Nova organized and she brought some things over to the Falco community. And it seems like they're not in love with this idea and probably won't be participating. I'm just curious what your thoughts were on their feedback and if you're gonna take any of that into consideration. So I got on a Falco call in their last meeting and it's one of the things that we talked about. And I think there was some confusion. So when the Falco community was talking about support and what they support, they end up talking about what do they actually contribute people and hours and time and support to. And they're stretched pretty thin right now. They're talking about scaling back some of their installations and some of their support because they're getting so many questions for things that are outside of Falco. So like they have a Falco Helm chart right now and they get questions about Helm over there instead of at the Helm project, which I totally relate to because in Helm I get questions all the time on the Helm project about Kubernetes general things. And so right now they're actually said they're dealing with that problem. And so they don't wanna put hours in and support it and do that kind of work in the shape it's in. And that was not something we were actually asking them for. And so we got on. I asked for their thoughts and their feedback, how they'd wanna go about doing it. And so one of the things we're doing is we are gonna take their rules that they have listed and display them through there and they've given their blessing to do this. They just don't have the time and energy to put work into it. And they don't wanna put an official seal if we support this, which means we're gonna put man hours and our people hours into making sure all the things work because they're a bit overloaded. And I think some of that context was lost but they are very happy to have things listed and searchable and found. They've given feedback on how we should display things over on the artifact hub feedback that's actually been rolled into the hub already since the meeting, which was last week I think. And so we've already rolled out those changes to their requests. And so they've given positive feedback and haven't been so much against it as they're kind of in wait and see but they're happy to have their things more discoverable. So Matt, that is really not the way that Falco call went. Which Falco call? I'm sorry, are you talking about, Diane, the call that we had the day before the TOC call or the normal standard Falco meeting call? The normal standard one. And I put to the issue in the comments and it doesn't look like there's any confusion but and it did look like they did offer that they should be, if it is listed at all that they should be unofficial and unsupported by the Falco community. Yeah, yeah, unsupported as in their definition of support is they are putting hours into making things work. That's kind of their thing. It's not official. And we're not asking to be the official thing. In fact, in their call, they talked about how they're reworking how you install artifacts. So one of the things they're gonna do is they're gonna stop supporting the Helm chart because that's turned into lots of problems. And they're also not gonna have an operator or something else. They're moving to lower level way of doing it and that is still to be determined. And so, I mean, I'm not sure what else to say there. They don't want to support it but their definition of support isn't to give it a thumbs up or thumbs down. Their definition of support was to put people hours and time into working on it, which is one of the things they clarified for me. So that totally makes sense. So who's gonna put the time into like list those things? Is it your working group that's gonna do that? And then is that extended to other types of entities? As of right now, the artifact hub folks are going to do the best we can to list those and to scrape them to make them discoverable. And we point people back to the root source on that. Because we want them to be discoverable and as they make changes, we will have to adapt. Okay, awesome. Yeah, I'd love to see that process written down just so that we have it so that the next folks that wanna do the same thing can reference it. Yeah. Yeah, I mean, and some minor issues, even if you want to be pre-alpha and early stage, there is not a single release right now of artifact hub. I mean, you claim to be alpha but there isn't even an alpha release right now. So this might also be something you want to look into. Yeah, and with this, this is one of the things that maybe I'll have a question on. So websites will often, and web apps will often work in a little bit different manner than something like shipped software. And so we are in pre-alpha, not alpha, which would be tagged releases at that point. And I expect we'll tag it when we go to what we would consider alpha. But when you're deploying something like websites, like if you go to most of the project websites, you're not gonna see things like tagged releases on their websites or their web apps that they run for their things. And so how does this work differently than the standard shipped software MO in this case as we go through the different steps? And I don't know the right answer to it. It's one of those things that is slated for our calls. But that's one of the things that we'll need to work out. Like when do we tag and say releases and then because then you get into install instructions when our primary is a web app. And how is that different here? Yeah, because when I look at the documentation on GitHub, it mentions that I should install my own version of the hub. I'll have to go take a look at that. That's probably for development purposes and on-prem, but our primary target at the moment is getting a work in web app up. Because the goal is to enable discovery of things on a large scale that are distributed. And we know people will also run it on-prem. The software that powers the Helmhub started as on-prem software that was repurposed for the public. And it's just had great success. So we know there's both cases, but instead of the Helmhub software which started on-prem, this is starting more of a public. Which is actually letting us build out certain features like organization and user management and things like that. Because those cases can be a little different when you're on-prem versus at least the on-prem scale that we had in Helmhub. So. And I mean one of us point here is also as we move forward on the, the UC MOOCs for what are the due diligence of the operator framework and operator hub, how the two relate, we see each other that will be also part of the discussion. Oh yes, absolutely. I'm actually waiting to see what happens with the operator framework and the operator hub as far as the TOC and vote goes. There've been a couple of different suggestions on the last TOC call. And I have no idea where it stands since then. And so I've been kind of in a wait in C mode to address that until whatever happens falls out. And I'm just not privy and haven't read those conversations. And I don't want to assume anything. Yeah, I mean, it might also be worse for you still to practically reach out to these communities. I mean, no, it's not part of the sandbox requirements, but you know that this project has already some history and some very strong emotions to it. So I think it's in your very own interest to you. Absolutely, absolutely. And because the TOC has been working with the operator framework folks, at least I hope working because the TOC member took the goal of figuring this out and pushing it through. Since they took that on, I'm hoping they do it. And I really didn't want to step into that middle of that conversation until things were ironed out. And I saw the TOC moving forward with whatever they're gonna do. And I'm just trying to let them work out between the two of them instead of stand in. Diane may be able to give some update on that. But at the moment, I'm just trying to let them work out whatever has to happen there. And then stick my nose in and start asking questions because they didn't want to interrupt. Katie from the TOC is on and she was doing the due diligence. And then Brendan also was going to look at it. So I don't know, Katie, if you're on and you can glean some. So I think Brendan is actually the TOC responsible for operator framework. But at the moment, there is a strategy to, well, to kind of separate the operator hub from the operator framework. And we'll try to push that forward. This is, I think they should be communicated last week towards the end and they should be updated already. But we've not received that. So we'd love to get that officially from you guys. As well, Matt, you've been invited multiple times to join any of the operator framework SIG meetings. So anytime you wanna come and reach out, we have regular cadence of meetings. Yeah, certainly, certainly. And I plan on it, especially around these topics, quite frankly, my time has been my problem lately with everything going on and kids home and just everything going on. My time has been one of those things that has been a little bit stretched the last several weeks. So I'm gonna work out to figure out how to come over there and chat about it. And hopefully sometime soon to kind of start figuring some of this out. As well, I'll actually follow up and make sure that the TOC come with full update on this. Yeah, and also like really prepare like in the next calls like for a presentation like some of those concerns because if I would really like, if I would really be playing the devil's advocate here, I would say you don't have software, you don't have CNTF member organizations and the hub for all the end points you might integrate, you haven't talked to many of them or some of them don't agree yet. If this project wasn't coming from the CNTF, we wouldn't even be talking about it. So just keep this in mind when you by addressing these concerns. I very much do. And I also know. Go ahead. I just want to pitch in from a medium sized small company. We're very familiar with Helm and we do all most of the things with Helm. And that I think that having one place that combine all the artifacts and be easy to search will really help us as a small and very limited resources company to install more objects. So Falco is great object or OPR is a great project but come in and understand how to install it and how to find rules and how to find all the artifacts for every project itself is very hard and very time-consuming. And the initiative of creating one place and that will help and possibly take questions from like the Falco community to this place will be great. Yeah. And I think nobody's debating that centralizing making things easier to discover for the end user point of make sense. I just want to make sure that this project gets treated like every other sandbox project out there and we're wasting the same concerns. I'm not saying we're not taking it in there with the question, is it mature enough and has it done enough of its homework or might it take a bit longer? But I think Matt, you've got my points. We'll have another discussion where you can go into more details there and then take it from there. And maybe one of my asks about sandbox projects is they are for experiments. They're not for mature software. And the sandbox documentation talks quite a bit about the different reasons for sandbox projects as far as these kind of experimental things. And so just keep that in mind as we look at sandbox projects that they're not expected to be like incubation projects. They are expected to be a lot less mature and all of that. And there's a whole document that talks just about this that's been updated recently in the TOC repo. And so that's the only thing that I ask is when we look at this and any sandbox project that we keep it to the sandbox criteria for those things because sometimes I know incubation level criteria start to creep in as far as expectation and asks that may just be premature for the projects. And that's okay under a sandbox level. All right, that's my two cents. Yeah, of course. But it does not mean that it means that you can be an experimental project. It does not mean that if it's an experimental project it's okay because there is a lot of criteria over there to say, okay, it can be experimental but it should add value to things that mission and it should be a foundation for a successful incubation level project. So I think that is a whole sentence of the sandbox project. Yeah, I'm looking at it from a distance because I don't have a horse in this race at all. Is that I don't think Matt that the objections are around a maturity. My sense is that the objections are around potentially. Are around some of the other elements not maturity project itself, but are around, do we have, have we thought about how this will come together how it impacts some of these other projects and so on? So that's just my feeling on this. Right, it's not saying it's the experimental playground for the project. I think that may be some misunderstanding on that part. Yes, absolutely. And I agree with those things. But like for example, I know some of the sandbox projects have been asked to do things like the incubation work over time and start getting into the incubation due diligence to go for sandbox. And in this case, I'm not even really asked talking about this project, which isn't a requirement. And that's a lot of paperwork for somebody to end up doing to go for sandbox because I know we quite often jump to those. So I know we're two minutes over so I should probably shut up now. Thank you all for listening and I'll have hopefully a well-prepared presentation for you in either the next meeting or the one afterwards, trying to address some of the feedback here. And I'm gonna try and document it on the poll request as well. So it's documented for the future. If I miss something on there, which I'll be doing after this call, please feel free to jump in and add the points that I missed so I can attempt to address them. Thank you. Yeah, thanks a lot. And I think this puts us to the end of today's meeting rightly. Okay, then thanks everybody. See all of you in two weeks from now, hopefully. And I'll keep in mind that next week, we also have the operator working group meeting. Let's get on as well. Thanks everyone. Take care. Thank you.