 All right, let's see how many people we got 7 people here. Let's wait like 2 more minutes before we get started. Christian is here. Looks like there's a network issues. Yeah, let's wait like 2 more minutes before we get started. And if you notice, I have a hack and D. Link in the discussion. And so that's. Um, an attempt to create sort of a linear documents of an agenda and that I think will. Um, be helpful folks to have that on hand. Could could we add in attendees to that as well? If you want, absolutely. All right, so that would be good. That's really all I have been tracking in in actual notes. For each each event everybody. Hey, sorry, I haven't been I couldn't make it the last couple of times, but now I finally got my OKT T-shirt. And I haven't gotten one yet. It still hasn't been to Canada. It got to Germany and it hasn't come to Canada. I'm going to arrive today actually. Yeah, my guy here is sweet. I also got mine fits perfectly. Yeah, it's awesome and we will get more of these. So, if someone's coming on and they didn't get 1, don't worry. We'll put them in the. In a work, a LinkedIn store that you can a linkable store where you can self service and get them. So, there you go. Some day we'll have a meeting where everybody has an OKT T-shirt on. All right, well, looks like we've got enough folks here to at least. Get rolling here. So, again, there's a link in the. Then I'll post it again. For anyone new that joined, please put your attendance at the very top of that. And note, or what you represent. And you don't have to represent anyone you might represent yourself. So, let's get started with some quick introductions. I'm Jamie and a member of the working group for over a year now, a year and a half. And using OKD in University of Michigan various environments in the University of Michigan. We'll be spending up probably later today a cluster that's going to be used for a couple dozen developers doing data. Heavy applications in the political and social sciences. And anyone else want to introduce themselves? Diane, maybe we'll go next to Diane. I'll go next. I'm Diane Neeler, the director of community development over at Red Hat in the cloud platform BU and 1 of the instigators and chairs of this working group along with everybody. So, I haven't been here in a bit. So, I'm Christian Glombeck and I am an engineer. In the open shift arc in within Red Hat. And I've also been one of the co-chairs of the over the. You want to introduce yourself. Hey, so I'm Timothee Arvier and I work at Red Hat on the Federaq Chorus, well Chorus team, which among other things, does a lot of the work for Federaq Chorus. Bruce, you want to introduce yourself? Sure, you know, I was just trying to sign or put my name in the document unsuccessfully, even though I logged in, but I'm Bruce Link and I'm just a user. I teach at BCIT and managed to put several students through the experience successfully doing projects and things like that. So that's been a lot of fun. Joseph. Yeah, I'm Joseph Meyer from Germany. I'm working for Odeon Schwartz as a cloud architect and I'm an OKD user and support is since more than three years now. And the man who needs no introduction, Vadim. I'm Vadim Blukowski and my webcom is apparently broken. I work Red Hat, focusing on upgrades and release activities for OCD. Excellent. Neil, do you want to introduce yourself? Yeah, hey, my name is Neil Gampa. I work at Datto as a senior DevOps engineer, focusing on software delivery systems, including source code, package management, container stuff and things like that. And, you know, I'm here in the OCD working group, working as both a person in Fedora and to a lesser extent a person from Datto to do awesome things with OCD 4. Excellent. Anyone else want to chime in that we didn't get, yeah. Tree, you want to say hi? Sure, I can say hi. Yep. Hi, everyone. My name is Shreer Manajam. I work with Neil at Datto as a senior software engineer. Working on various products and services that are, you know, built on top of our in-house Kubernetes and open chip clusters. So. And I'm also here as an interested hobbyist, especially in like the home lab states and looking to expand OCD's presence there and sort of bring up its cache and that community. Oh, yeah. And Shreer is a master of disaster recovery. I'm led to believe. Did you get it back up yet or no? Well, the cert thing that that other person mentioned, I don't have his name right now. It didn't work for me. So I just blew it away earlier this morning. I'll re-spin it probably after a week. Oh, you haven't responded yet. I was, I was wondering if you'd actually brought it back online after everything fell apart. No, not yet. After work probably. All right. All right. Well, let's jump into the agenda items. I do like to have the intros because there's always going to be people listening or watching that aren't familiar with who we are and what we're about. And again, OCD is the communities, Kubernetes community supported Kubernetes technology that is supported by a very. Interesting and lively group of individuals from a diverse with diverse backgrounds and it's a real fun project to be involved with. So let's get into release updates with Vadim. Sure. So we didn't release for a release candidate this week because the code freeze is planned to be happening this week or next week. Once it happens, we'll release a new release candidate that it shouldn't have can changes, just a bunch of bug fixes. So if you could give an OCD for a try, that would be very appreciated. Meanwhile, on for seven, we released a new stable release. It the main highlights of it is that machine OS moves to the door 34. And we might have an upgrade issue number 668 affecting for seven to to the latest stable upgrade. I was still looking into that seems like we missed including one package. And the most concerning part is that it was not called by CI. We'll do our best to fix it quickly, see if the workaround is feasible. If it's not, we'll move to a new way of building machine OS content for a release patch release. The issues that also we're seeing quite a lot of table clusters of greatest release version, something about 16 telemetry. So we'll need to figure out more information about this issue. So if you could give an upgrade a try on your test environment and reply to this bug, I would be very appreciated. I think that's all we have from the technical standpoint. Okay, great. And we always like to bring our, our friends from fedora core OS on to give an update on that so Timothy, Timothy, you want to give us an update. Sure. So, right now we have two items on the agenda. The first one is about system D, which is a new part of a new demon, I think from system D that is being introduced in federal 34 if I'm correct. And that is not yet enabled in federal chorus by default. And we're looking at whether it makes sense for container workloads to have that part of the system. Just to give a short of you, I think the system view on D essentially is is a is a demon that is using the new secrets be to and PSI interfaces from the common to figure out which process it should kill in the case where the kernel of the system lacks memory is under pressure and so she essentially on okay D. Well, this might have this consequences. Maybe we don't. Well, we don't we don't actually know if what would be the consequences of using that that in okay D. So yeah, the idea is to bring that out to your attention and trying to figure out if we should enable that you should remember that by default. Of course, it could be enabled in federal course but disabled in okay D to so, but well if, if it doesn't generally makes sense for container workloads and we just probably won't enable it at all. And well, this is like the right time to gather feedback if you have any on this issue. That feature seems to be very useful but now it won't affect us because it requires the group. And it's not clear if it would be default and for nine even. Another problem is that it's probably undesirable in various world because the few blood cannot read system D events to find out if your pod has. Oh, and that reads kernel events. If the system on D would kill a process, it would look as if some random restart to communities who would just confuse all things. Again, we would need to work upstream in in communities to reconcile this two approaches until we can enable this by default. So what we can do now is to to stop depending on on Fedora course decision on this really and just disable it in our custom payload. But that's probably the input from the okay D on this. All right, well that's that's great. I'll pass us forward to the records teams. Right. And in the chat James is asking teach KS to talk to omd or vice versa. So there is a when you Google this cubelet. Oh, and there's a talk coming up by a redhead employee that is mostly about secrets. So maybe this is Giuseppe. And so maybe we should just be getting his opinion on this because he probably knows a lot more than we do about this whole complex. Okay, does someone want to reach out and. And gather some information from that person or at least maybe invite them to. Come here and talk with us. I'll reach out and ask whether he wants to join next, next time. Otherwise, I'll just ask him to give me a few words about sure. Awesome. Thank you. Right to see what's next. Yes, the single nighting is a little bit more like forward thinking thing, because it's about 35 so we've just we based for the 34. So it's not coming right away. It's coming in approximately six months. And it's the right time I would say to look at what's going to change. And see how it might impact. So the, yeah, we essentially the changes that are going to be certified and so far we haven't identified anything. So that would be strong. I'm just going to mute other people and unmute yourself. You need to. Okay, go ahead. All right, so federal certified sentries mostly nothing stands out so far, but we're tracking that and the federal change process window is not closed yet if I'm great sir. So yeah, this is this is ongoing. And that's mostly it for me for federal careers. There are any questions. Any questions. Let's write that Fedora. Of course, 34 is coming in half a year but is used now in okay D. No, no, we've. So as the team said, federal careers based on federal 34 is coming right now in okay D just right now is federal 34 has been released couple of weeks. Okay, thank you. And so yeah, we finally finished all the rebates for federal careers. And right now we're starting to look at Fedora 35, which is coming in approximately six months. Okay, thank you to make sure that we catch up things before they happen before we can provide feedbacks for everything is in fixed. So the looks of the changes that doesn't look anything would break us but I think there was a good practice which we applied for for eight release we our machine OS content has been using Fedora's next development stream to fetch the latest changes which would only land and stable in a couple of weeks so we can catch them and the installer for for eight is also currently using testing. Requires rather recommends you to use testing ice. The initial Fedora cross images. So that we would change check that both of those are perfectly valid once they land and stable. I think we'll, we'll do the same for okay you for nine or for 10 until it becomes stable. So that we could verify the changes I had that has in pretty valuable as we caught quite a few regressions were able to report them before it lands in for seven or in for the across table. Anything else. All right, let's move on now to issues. Let's take a look at our issues and one of those is that I wanted to highlight actually before we get into sort of the general overview of issues is. The operator wish list so this came up in conversation in an email thread. Do you want to summarize that the email that that was sent to the group and sort of explain your response to that and maybe also Christians response to that. About the operator wish list or. Yeah, you know that we received basically asking for clarity and for documents change. In regards to what was actually available. And what was supported and whatnot and there was actually a okay D document change because of it. Right, that's because, for instance, we had to repel some parts of the documentation because those are logging operator is not directly available and no kitty. And while we are in for folks to create a new kitty. A catalog for the operators to start pushing the upstream versions of that we would have to remove some parts of the documentation. I don't think we have any estimate on this yet but will be it's because effectively out of our hands for we. What we need is the collaboration between various teams to commit to supporting those in no kitty isn't. Supporting by community nevertheless not redhead support but nevertheless it's still some level of commitments required. And once it happens we will be able to bring those parts of the documentation back. But until then we effectively have to remove them. And tell folks that they unfortunately have to build those operators manually or look for alternatives and community. A catalog we have and that's basically that's the current state. Good day are like a few probably months by now back. We talked about having an OKD specific catalog just for OKD has there been my question is, has there been any development on on that side. I haven't heard any. It's mostly the talks between the teams. They want to ensure that we don't plan additional work on them. But still this catalog gives them benefit of well community support. It appears that technical part of this should be trivial. It's just a matter of ensuring that the teams actually commit to supporting those versions of the operators before they land in the official redhead operators or. Or they want to develop entirely different community version. It's just a matter of how they would structure their work. Creating a catalog itself is fairly trivial. It's just a matter of making teams commit to that. I wonder whether we should be setting up or just helping the people that would do that set up this catalog. So we have something the respective teams could then release to not worrying about, you know, this kind of like it doesn't even exist yet. And also I think, well, while this is probably more internal, the management has now given them more clear. I think mandate to the teams to release to the community catalog or release a community version of their operator. So maybe if we kind of make it as easy as possible for them to actually release the operator that will help with that process. One thing that I was thinking about is when we talked about this at the time and I put a link in the chat to the particular issue that Christian created. We've got the wish list, but we don't actually have an explanation of what needs to happen. We've got them categorized currently unavailable available in community, etc. Is it possible to maybe put a little explanatory text in that issue as a comment or we create a separate page that's like, hey, this is actually what needs to happen for these various components to come together so people can understand what needs to happen. And then also we can look at timelines and also for the people who in this group or who are interested in OKD development for them to get started on this, maybe some tips to provide them some guidance as to hey, you know, someone's like, I would really like to see this operator in OKD. Well, it needs to be rebuilt. There's some general place to look about how to do that or something like each repository for each repository for each operator is going to have specifics but it might be nice if we inspired people who are interested in OKD to take this on by giving them a little lift. Yeah, well, probably we should regroup them into two major groups as an additional order of attacks like maintained by Red Hat and something like others. The problem is that why we can submit logging operator, for instance, into the community operator because is that OCP users would see them duplicated. They would see official Red Hat's logging operator and one coming from community and they would be very confused by which one is actually being supported. I think that was the main reason. Engine separator. Have your KD catalog, right? Yeah, exactly. But there is an engine separator, which is totally fine to submit to stream operators and community can start working on this right now. And it's already listed in the wishlist. So what we need to do is to review the list, find a list of things folks can start submitting right now like engines. And I think a video operator or maybe I'm wrong. And after careful review, we can start. We can find a documentation on how to submit, who wants to take care of it, how to hear the responsibility. Should we include these kind of new wishlist items into these meetings or who would maintain them? And so on and so forth. The other internal Red Hat operators, they would need a bit more work because there is a whole team behind each of those. And we need their support and they would be maintaining it without OCDs or group kind of requirements and such. Okay, well, let's put this on the agenda for the next meeting and in between now and then if folks could think about how we could organize this. And should it be a subgroup, you know, like a subcommittee or something like that. It'd be the main group and we'll talk about in the main meeting, but how we can move forward on this because it's been lingering like Christian, I think, published this in January. Like so we have a list that we can start working on. We can be adding stuff to it as well. If we start moving on it, I think it makes OCD more attractive to have because some of the ones in there are pretty significant, right? And it's things that people are really looking for. So I think one thing that. Oh, go ahead, Christian. Yeah, sorry. So one thing I think that the community can definitely already get started on is looking at the currently unavailable operators and all of those which aren't in the open shift organization. Or even the open shift K native organization. So all non redhead operators. Those won't be released by us anyways. So, and those would be going into the upstream catalog, I guess, or if they're, if they're really made just for open shift, then they would go into the community catalog. But any of those all of those operators that aren't owned by redhead that are currently are unavailable. Those would definitely be good candidates for the community to look at them and add them to the respective catalog on operator hub. There's also that there have been some changes recently to the operator hub so people can more release new versions by themselves without having an admin from the operator hub repository. Have to acknowledge those changes so that there's going to be, I think, owner files for each operator. So when you submit an operator, you'll become the owner of it. And then you can also update it without anybody else having to acknowledge that from a third party. So maybe if there's interest within the community to get one of those operators released right now. And all the non-rated operators would definitely be good candidates for you to look at for us internally all the. Operates that haven't been released yet. We obviously want to get them released to okay or okay by the respective teams. Yeah, we can also take some. Excellent. All right, so we'll put that on the agenda for, for our meeting in two weeks. I'm going to talk about this more and have fleshed it out a little bit more and probably put in a separate page as opposed to this issue. Actually, maybe put an okay D page either on the website or something like that. That we can actually edit in line as opposed to just adding comments to etc that that we can improve upon and update the list and whatnot. Moving on, are there, there's a new issue that was submitted. Vadim, do you want to talk about this? A little bit deploy your installer provision clusters on bare metal. Looks like it was submitted an hour ago. Is this the documentation one? Yeah. Yeah, so I was going to talk to that just quickly. We just spent the prior hour to this meeting with Bruce and Mustafa Mustafa from elderberry from red hat and Bruce from BC it. And this is I'm just bringing it up here to give sort of an example of. Of how we're working through. The docs.okd.io to find defects in the documentation and report them back. And so we've we've done our 1st pair pair, not programming, but pair review. And we're trying to document the process and there is a recording that will I'll put up as soon as I figure out what the YouTube issues. But this example and I'm just going to share my screen. I'm just going to grab 1 of them here and I'm just going to share the troubleshooting 1. Is the process if you find a defect or an issue in the documentation that we're we're using right now. And we'll we I will document it in a brief blog post on the okd website. And as well so basically just finding the section and we're reviewing it with Michael Burke who's I don't think on this call. The documentation team for open shift. And so this isn't about actually fixing the issue so in some examples there are code examples that need to be reviewed and retested but this is a good way of make sure you put the bracket okd in the the subject line. Put the link to the section that the issue you're finding in and then potential resolutions. And if you don't have privileges like most of us don't to assign this to somebody that slash assign at the bottom of my screen there for Michael Burke and myself will allow us to track it. And at the moment I don't have privileges to add a label to it. So I'm going to work on that I'm going to double check with Michael he may have privileges. But there are two labels that we're using one is okd dash only and the other one is that it's documentation. So there's another label in there for that. So what once we figure out I don't think you can assign like you can do the assign a person to that I don't think there's a slash label function and GitHub to do it without privileges. So this is we're going to start working through as many of the issues I think Bruce we found like there's 20 references to our cause in the okd documentation and so we're going to use that to flush out all the issues and then move towards doing that. So what the ask is for this group is if you find something especially right now we're focusing on the docs.okd.io. If you could use this approach to tagging them and I out for them and we will do this and try and work with the docs team to make sure that with each release there's a process in place for these things these patches to be applied correctly. I'll stop sharing if anyone has any questions, but that's that's what that issue is. So you'll see a bunch of them pop up on the issues list. And right now they aren't properly labeled. And that's that's my issue to figure out this week. Many issues. All right, it's that the the okd repository. Because I seem to be able to edit labels on that repo. You have more privilege. Yeah, I don't know why that's repo right. Yeah, I don't I can add stuff, but I can't edit that so I'll figure it out and maybe in the interim if you can take those ones and just add okd only label and the documentation label to all of them that would be helpful. But Mustafa is going to keep motoring through and working with Bruce. And if other people want to get paired up with someone, Mustafa, if you recall, is one of the newbies to the the red hat open shift team. And what we're trying to do is pair people, the newbies up with external folks who have used and deployed okd so that there's some life experience lived experience going through this. And then once we figure out this process and get a few of them through there, what I want to do is set up a hack the docs. See, you don't have privileges either. See, it's not just me. Christian does can add them. So what I'd like to do is sometime this summer when everybody's feeling fine is to do a hack the docs day. And hopefully we'll catch everything in the docs.okd.io and then move to like the guides that that everybody's created and the actual read me files and take on each of those using the hop in platform. Because that's what I want to do on my summer vacation. Excellent. All right, I put a little note there. Mentioning that Diane is going to organize the hack the docs day. So we can look forward to that. The next thing I want to move to is if you could give a quick couple sentence explanation of the. Good first issues label and what that means and what your hope is. Right, so we've been. Looking for easy bugs for community to get started for quite a long time and when we wrote. A log bundle issue of notice that. Paying some missing there, for instance, we're using additional services to update from Fedora Chorus to OCD specific. To get a specific payload. Normally, those are not a problem, but when things break, we would like to get logs from them as well. So. A few issues to fix that have been packed and these are mostly touching the installer and our fork of it. So it would be very useful for community to get started with building their own installer. That would effectively spin up a new guide how to build your own OCD installer until it merges in upstream. And we would add. Some more services to collect using log bundle and. Well, it picks up this item to verify meaning break their cluster collect log bundle and ensure that all the logs are in place. So this kind of a small things would help us write better guides and explain how all things are interacting with each other. Hopefully this would affect the troubleshooting the bootstrap. And log bundle analysis documentation and so on so forth. I think that would be a great starting point for folks to understand the complexity of how we build the system and how we analyze the problems meaning log bundles and math gives us are essential for us to collect all the information we need to find out all the details about the bug. This might be something that the group could take on as a regular section of our meeting or a subgroup could meet to basically like go through these and sort of bootstrap each other into, you know, because a lot of these involved little bits of knowledge that maybe one person has a little bit here one person has a little bit there. And maybe someone needs a jumpstart just to be able to dig a little deeper and help out. So it might be worth us thinking about how we could as a group sort of approach these and share a little bit of information to get people bootstrapped into being able to help as sort of group developers or group support people or whatever. And this sort of runs into that concept of, we talked about at the last meeting of having basically people who have who commit themselves to being supporters, basically like supporting, you know, questions and whatnot and that specifically make themselves available, or say that they will specifically be active, right to do that. So any thoughts about. Yeah, perhaps we could suggest. We could have an open floor ish style of suggest your own favorite paper cut or an issue. So there we could file it. I could help with if it touches some OCP part that could help with filing a proper bugzilla ticket and driving it to the team. So that we could see how it gets fixed in master or release for a van gets every fixed for seven and explain how how soon do we get it and how to how to interact with other teams. Probably that should help us fix a bunch of things which are left behind but very very easy to fix actually. I would also suggest that what we're doing with the docs, the pair programming or pair reviewing process might be a good way to flush out the workflow around these, what we need. And they may all be different because they may be, you know, something may be a fedora corals but I think if we do, if we have those tagged now. We could use the same team of group of folks that must have us coming from the newbie Red Hatters to pair them with external resources who are willing to help mentor them to do some of these first. First paper cuts. Maybe motor through it that way to get the process flushed out. And I'd be happy to do facilitate that. So do we have a bunch of first cuts listed or first I'm calling them paper cuts, but because you refer to them that but as a label. Yeah, there's a label. There's like five of them right now. Yeah, or five. Maybe what the thing is is to reach back out to forget who the team lead is for Mustafa and see if we can get a couple of those five looked at by that team. One on one and pair them with whomever is appropriate externally and then see who's missing because that's what that's where like Michael Burke came in with the docs he understood the workflow for docs. Wow. Some of these are pretty like, like so for example I'm looking at the one that's that's ownership of the authorized key. Like that's something that we should be able to look at pretty quickly, you know, and just figure out, well, okay, how is this how could this happen but you know, I don't know. All right, so let's put this on that we've got 18 minutes left and I do want to make sure we have time to get to all of the other things without rushing the other folks that are reporting in. So let's put this on the agenda for the next meeting and sort of flesh out ideas and sort of be prepared to to move forward on that at the next meeting. I admit folks can chip in on those. And again, these are, these are issues that are tagged in the okd repository with a good first issue label. All right. Is there anything else in terms of issues that anyone wanted to bring up the team or Christian or anyone else that you want to bring our attention to in the in the submitted issues. No. Okay, and what about discussion items so we talked before about subgroups. And do do we want to start documenting the proposed we've got these ideas for you know people that would be supporter like dedicated to doing support and what not should we create a spreadsheet of some kind and start having people. And basically submit their names and what it is that they'd specifically like to help with. Does that sound like a good way to start. Just as people log in each time put who you're affiliated with and then maybe underneath that put what your interests are and contributing in the community. Or is that too much do you think for people to put into into the document thoughts. Now, okay, I guess no one has any particular opinion about it. So, let's do that at the next meeting we'll ask folks to put not just who they're affiliated with but also what part of okd they might be interested in. So maybe at the top of that document, we can have a list of ways of like some labels that would be, you know, ways to participate and then people can just sort of list those under their name and ways in which they might be interested in participating. So give it a shot. We'll see how it goes. It just seems like a good way to start forming groups and knowing who wants to do what and keep track of that right. We already talked about system and any other discussion items that folks want to bring to our attention anything else that was submitted that was submitted in the discussion section of the repo that you think we should pay attention to in particular. Actually, Jamie, I just have a comment on kind of the whole subgroup plan, which I think is absolutely great. I do think that that's going to help focus people on a specific task and get that task done more quickly. So, in our charter which we wrote at the very beginning of this working group, we already kind of had the idea of sub working groups. And there's a little section in the chat about that. Just to link I linked it here in the chat. So, yeah, I'll put it in the dark as well. So, yeah, just, I just wanted to voice my support for the idea in general and there already is kind of a process, although we haven't flashed it out, I think, of how to create one of these groups or get it started. I definitely appreciate this. Absolutely. And so I'll reference back to that and then build on it and sort of weave that into the next meeting starting with the next meeting. Excellent. And if folks want to chip in ideas and hit me up between now and then have discussion about it, please do. This is a group effort by all means. Any other discussion items that folks want to bring to our attention anything that was submitted in the discussion section doesn't look like there was that many handful. Okay. Just a short question the inside feature that shows up in OKD is overview on the web console is this. Yeah, does this feature do something or is this just a remainder of OCP feature. It's an inside separator which if you have red heads full secret would collect data from your cluster periodically and save it in red heads servers. Just a small subset of data, which is very useful for us to identify problems early. Again, if you don't have a valid full secret, there is nothing to upload rather you cannot authenticate with the red head server. If there's been some data uploaded it can also give you your recommendation. There's R8 GB which is too small and things like that. It kind of does not apply to OCD, but that gives us a valuable stats on how people are using the OCD. And that's the only stuff we have meaning we are very tempted to use it to make valuable decisions. For instance, there is a bunch of four or five clusters. And barely any for eight clusters live. That means we need to push for a advertisement on every single meeting like that so that people would give it a try. Is it representative of what people without the full secret are using. I don't know we don't have any data for them. So that's that's basically what we've got. Is that thanks providing the telemetry you talk about when we do upgrades, or is that something else. It complements telemetry because telemetry is actively sending things rapidly but insights makes a snapshot every couple of hours do or maybe four hours. And telemetry is able to send metrics while insights is actually making a snapshot of control plane objects and anonymizes them and sends us here. So we get some information based on metrics for instance we can kind of find out your operator state based on metrics. But it's a bit tricky. And if we want some more details, we look into insights archives because those are actual snapshots of the project. Okay, and well, but it doesn't work if you don't have a full secret. Yeah, again, everything. The insights operate is essentially just the client side of this. Then send all that data collect to go back and that redhead has. But I'm not sure I'm not even sure there's a an open source repository for that. I'm not sure how you would use this. If not for the only use case it has sending the data back to redhead. And obviously that only works if you have the right full secret, the official redhead full secret. I mean, I'm not sure. I mean, it's definitely helpful for our SRE team. I think that's a big data source for them. But yeah, I was, I've always been wondering whether we could kind of make that warning of that noted notification that you could connect the or install the insights operate inside more data that we kind of don't have that show up on OKD. But on the other hand, you could also use a redhead full secret and install it on the OKD cluster and then send the data to redhead. Although probably nobody has done that so far. Yeah, Christian, I think and Vadim, it actually would be helpful. I think if somewhere it was written down the precise boundary of where you could use the redhead full secret and not. Because I've heard many things informally. And certainly, like, you know, anybody that has developed redhead developer account, which is anybody can get one that's valid for 60 days. And then seems seems to continue to be valid after that. And there are some maybe mysterious way where you can say that you're self supporting or not. Anyway, the like that. That touches the topic which I don't really know a lot about which is subscriptions. So all of that is outside of our reach. There is a service in in front of all the redheads. Which we maintain internally called do both. And what it does is it effectively validates the full secret and tells us to this data proceed further or it needs to be thrown off. Right. It might be ready a Diane issue. Yes. Well, there was a nice talk about subscriptions recently an open shift to be. And it's slightly different from engineering standpoint like. Are not set in stone. They can if you're a educational for instance facility, you can ask for a subscription which enables you the sale of supported stuff. Good luck with that. Well, yeah. Actually put in a request a year ago. Hold on. Let's let's we have seven more minutes and we do want to get report from the docs folks. We will investigate. I think subscriptions and that boundary for pole secrets. We'll see what we can find out. Let's add that to the list of to dues. Okay, so we have Joseph on the call and I don't see Mike, but I know Joseph and Diane both have things related to docs and outward communications to bring to our attention. So take it away folks. Joseph, you want to go first and what you have so go for it. I have to admit that I was not was not in the docs meeting at the last time. So no news from my side. Okay, not to worry. And I think I pontificated a little bit earlier in the issues section about what we're doing around docs and and trying to tag things and create a flow around the docs. Okay, the dot IO. The other thing and I will create use Joseph your blog on the site to create a little documentation around that and awareness for that. The other thing I think I added it in the lower section. Let me just popping between things. We did update. I'm not sure anyone noticed in Slack. The community support texts at the very top of the open ship dev and open ship users to point people to the OKD working group for community support. So that's key. And I mentioned in the chat on the side on June 25 post red hat summit. I'm gathering we're going to take a number of the end user stories that people that were pretty popular, including Joseph's talk on OKD to Azure and restream them live on open ship TV with sort of a mystery science theater approach. So we may pause them and put in new references and things like that and updates. And if you're if you're around and you want to join us, the link is embedded into the notes here. And we'll be dreaming. I think it's about four hours long. But there were some awesome talks. Interest identification of members is the other thing here. Not quite sure what you meant by that Jamie, but I'm the OKD working groups doc subgroup meets every other Tuesday at the same time as this one. So if you are interested in joining that group, same time, same place one week later. Sorry, that was connected to what we were talking about earlier with people basically denoting their interests somewhere within the documentation. Yeah. Okay, cool. Thank you. Yeah. So, and that's, that's that and if anyone has a talk that they want to give. I have podium via OpenShift Commons and OpenShift TV to do that. So, I'm looking for other OKD related talks over the summer that if someone has one, I would love to hint hint John Forton to do an interview style or whatever style you like. Get your story out there and get more people coming to the OKD working group. I will try, I'm going to have a very busy summer. We will try to convert some of that work into something I may be able to present. Yeah, no worries. Yeah, and I think there was one other thing that I was trying to think of. Yeah, and I know the summer is going to be busy for everybody and people are going to start taking vacations. But, you know, coming up with a date for the hack the docs once we're there, I can see Jamie's got his hands full. But yeah, with a good kind of hands full. Yes, I'll put something out with maybe a doodle or something on the working group list to see if we can come up with a date for that. And now I can see for my next meeting a few people popping in because this is my channel. And maybe what we'll do is we'll get a separate channel for the OKD working group Jamie at some point so that they don't overlap. Yes, and that is definitely the OKD's working groups youngest member ever. And he has not yet gotten a panda thing. So we're going to have to figure out how to get panda diapers. I think our panda t-shirt. This is Leo. All right. Any last minute we have three more minutes left any last minute items that folks want to talk about before we sign off. And Shri, I just wanted to mention I saw your post in the working group about the messaging around OKD and we'll have a I'll have a conversation with you about that and see how we can move that whole conversation forward. So look for me in Slack sometime when I'm I'm hanging out and you think I'm I don't look busy and you don't busy. You're on European time or are you on the West Coast? No, I'm on Eastern Eastern. Okay, I'll look for you and we can we can move that forward. We can if you go to the Slack channel and post your question there, lots of people can pop on. There's lots of people doing homelab setups. And we do actually have a couple of documents that we can point you to that are on the website. Joseph, if you have that link, maybe throw down the the homelab link that we have up on the documentation. But yeah, if you go in the Slack channel and ask your question, we can definitely help you out. Yeah, I mean, this is just for like value ads for OKD for, you know, eventually we'll put a section of the read me try to flush that out, make it more clear what you get. Yeah, I know it is tiny bit unclear. But yeah, I can definitely drop a line in there. I don't remember if I did before, but I'll put another one in now that it's. It also might be fodder for a good talk as well. But think about that like, you know, the way that like yourself and Neil or and myself talking through what the what the value proposition is for you guys. I think that might be a good Monday open shift. I do upstream stuff so I could do an open shift OKD, you know what the value prop is for OKD from data point of view. And have you what event would we be doing this in or is this a dedicated event or something like, I guess I missed a little bit because I'm juggling like 3 meetings at the moment. That's okay. So I host I have on OpenShift TV a channel called OpenShift Commons in which on Mondays I do upstream talks and OKD qualifies as an upstream project so or sibling stream or whatever. Oh, that sounds like fun. Yeah, sure. There's this next meeting coming up and there's already people joining. Yeah, so let's let's move it to the channel and say thanks to Diane and Christian and Vadim and Timothy and everyone else for contributing and Bruce say goodbye.