 Well, let's get started. Welcome, folks, to the first meeting of the OCD Working Group general group. This is our meeting for January 18th of 2022. And we have an attendees section. So if you're an attendee, please in the meeting notes put your name. And if you so choose your affiliation and we'll put that in the chat again in case anyone has joined since that was posted. Let's do a quick agenda review. Let me know if there's anything that you think we missed, but folks have been adding a lot of stuff as we go. We'll take about 30 seconds and take a look and let me know if there's anything you'd like to add to the agenda or remove for that matter. Any suggested changes? If not, then we'll move on. All right, great. Well, let's jump into the first items. As I mentioned, Vadim is not here, but he did put some notes in there. The new 4.9 stable release is out with no significant changes. The 123 and 122.5 rebases are landing soon, which would unblock the Fedora 35 rebase. And Christian landed the final OCD specific bits in the machine config operator master on 4.10. And we are about to be 100% upstream soon. That is awesome. And there's some progress on the OCD assisted installer working on the installer slash AI changes. And are there any questions on that? I don't think Christian is here as well, so we don't really have anyone from that side of the house here that can answer questions. But if you want, we can put them in the notes. Any questions you'd like to put in the notes for the next meeting to be answered on these things that Vadim provided? Okay, not seeing anything. Let's move on. Next up is Timothy with Fedora Core OS updates. Yes, hi everyone and happy new year. So on the Fedora Core OS side of the house, we're working on all core OS layering work. So I think there are two, there's documentation, experimental documentation and the tracker for the work there, which is like the big thing happening right now in Fedora Core OS, which will hopefully enable fully layering based images for OCD. So everything we do in sync and much easier to think with Fedora Core OS changes, involving lakes, forestry builds and infrastructure around. So that's the biggest one right now. And apart from that, I don't think we have anything major changes. So Fedora Core OS side since the last time. So that would be it for me. We're still working on bringing communities testing more in line. That should help us. Excellent. Any questions for him on the Fedora Core OS stuff. Great forward. Up next, Brian, do you want to discuss updates from the DOTS or something group? Yep, and we might as well start with that. So we had our first meeting of the last week for what's the documentation workgroup. And one of the things that came up is should we rename the workgroup because the scope has expanded. We're no longer just looking at documentation. We're looking at things like the social media platform. We've looked at the community interaction model, how we can actually do that. And we're talking about the new gate organization. So there's been a couple of thoughts. Should we be the comms workgroup? Or should we be community liaison or community outreach workgroup? Because we are sort of doing that role. So any feedback on that would be, have a discussion, a couple of other points that we talked about while I'm on. We are still looking at moving into a new gate organization for OKD, so out of the open shift. So community members have more access to the community. And with that in mind, we did have a discussion around, do we have too many contact points? There have been some comments that we've got too many touch points. We've got the Google mail on this. We've got the two Slack channels. We have tried to move everyone to the discussions group within the OKD gate repo. And then there are various social media. And from us who are in the community, the comment is there's too many places to track and to follow what's going on. And it must also be confusing to new members as to where do they ask questions? And are the people looking at the channel that they've chosen to ask the question and are they getting a response in a timely manner? So I think that's the second issue. And it will be a good opportunity to sort that out. So as we move to the new git org, we can put everything in place so we don't actually cause confusion. There were no new issues and there were no real changes. I did tweak the colors. So we now pass the accessibility checks from the Google developer tooling. And we had a couple of contrast issues. So that's all been insulted now. So really those two discussion items, I don't know whether you want to have a discussion in this group or whether people just want to ping and add to discussions around the naming and also community outreach channels. The only thing that I would say is that documentation and getting good documentation for OKD is still a really high priority. And so having visibility of a working group working on documentation is pretty key. And that communication, I know it's a priority, but from my perspective, getting the documentation up to snuff is still something we really need to focus on as an entire community, not just the working group folks. I wouldn't want to lose visibility of that because I think from my perspective, the thing that I get the most feedback on personally is the documentation still needs improvement. So I think I shared with Jamie. I didn't share it with a group, but one of my ex-Red Hat colleagues from VMware. I don't know if you shared it with the docs meeting Jamie, John Holly's review of trying to install on VMware or something. Yeah, so I was going to, you know, for me, my concern is getting out of the business of focusing on documentation, whereas that's personally the thing that I think we need the most work on. Communications is still pretty big. So, yeah. So that's, that's my two cents. What about anyone else in terms of the naming part of it? All right. Well, the docs group is going to be talking about it next week and we'll take this feedback or take the feedback that we got and work on that and see where we land and we'll definitely let folks know. Any thoughts on the narrowing down the scope of our communications? Right. And actually, so Timothy points out that we do have reserved OKD project on GitHub and GitLab. Diane, has there been any movement on trying to get OKD, just OKD project wrestled from the hands of the random person? No, the random person and the random people in at GitHub that approve that stuff haven't responded at all. So I think we probably just move with the OKD project org and be happy with that. Okay. I think we waited long enough. Sure. So we'll take that to the docs group. One other thing to come out of the docs group is that Brian and I are setting up a meeting with Vadim. Actually, I just got done talking to Vadim a little bit ago about this. Brian and I are going to meet with him and talk about the current main OKD repo and like what needs to stay and what needs to go and like reworking that because it's sort of like a long screed right now of differing ideas. We'll meet with Vadim and see from an engineering perspective what he thinks needs to stay sort of at the top level read me in the repo versus other places. The other thing, was there anything else? No, I think that's about it. Brian, is there anything else? Or are we good? We're good. We're good. Oh, we haven't heard from Doriti. We got to get those credentials actually. We don't actually have those credentials yet. We talked to her again last night or her last night my last my last night her morning. She's in India, I believe. And so I haven't heard back from her. I will ping her again today and see if I can get those back here. I'm sure it is. She's a red hat employee. So she'll respond eventually. Excellent. Let's see. So next up is Issues, there were no new issues submitted to the repo, the main repo in January yet. Discussions note that the discussion section is meant to be like covering the discussions items in there. And if you have like new items, that's where you would put like new items. So like, Sandra, that would, your item would actually go under new items since it's a new topic as opposed to something that was submitted to the discussions section, which is actually sort of a self referential thing. So, well, Sandra, why don't, since we're sort of skating into that, there was no discussions in the repo of note. So, Sandra, why don't you go ahead and you had some thoughts. Yeah, well, Brian already introduced the topic in his section. I kind of, maybe it's just my personal opinion, but I kind of find difficult to find a single place where the point user to ask questions and get answers. I come from the overt experience and there we have a mailing list and several social media, but whenever a question arise, we, everyone direct to the user mailing list. So we have all the question and answer in a single place. I wonder if it makes sense to have a main contact point where we can direct people asking question and looking for answer before asking, instead of having to search multiple channel, if there is already someone who asked the question or if someone already provided the needed answer. I think the thought that came out of the docs group was that we use the discussion section for that, because it can be tagged with different items if it's a work group specific thing it can be tagged with work group. We did verify that we can add tags and labels and whatnot to those discussion items as it currently is in the in the okd.io repo. So that the thought was that we would be heading in that direction Brian you want to speak a little bit more to that. Yeah, so just a very quick recap. So we've got the Google mailing list, which was initially meant to be for the contributors that want to discuss sort of technical issues that started getting taken over by users asking for help. We've got the two Slack channels. One is a developer and one is a user. Again, the working group were meant to look at the developer and the end users that want support that won't help with things like install. They were meant to use the user channel. We got people asking anything everywhere. We then had issues within the open shift okd repo. And again, that was a place where people were asking for help when they run into difficulty. And recently we started using the new discussion feature of GitHub. And what we've done is we changed the header in the Slack channels. And we put messages in the mailing list to say that if you're looking for help or connecting with users using okd, the place to start is the discussion. If you're having problems and you're not sure whether it's actually a bug, start with a discussion. If you have identified a bug that is repeatable, raise an issue. So we try to give that advice and that is actually in the community documentation. We did document that approach. And we are trying to push people to say, if in doubt, go to the discussion sections of open shift slash okd. And one of the things was, okay, do we start shifting to the discussion section on okd.io as opposed to the okd repo? And the idea was, well, if we're going to be using the new repo sometime in the next couple of weeks, it doesn't make sense to spread things out across that. We would ideally, when the new repo is populated, start managing conversations and directing people to the discussions there. One thing I don't know if folks noticed this or not, but Vadim actually left the dev channel the other day in frustration because people have been asking user questions there. And there's not really any dev discussion. So one thing we might ask ourselves, and this will be discussed at the documentation subgroup is, are we actually utilizing the dev slack channel? Does it confuse things? Is it helpful as we start doing more development ideally as things align with upstream downstream? And there's more community contributions. Like, will we use that? Or do we anticipate that that's just going to be an empty channel from now on? Do folks have anything they want to chime in on it that we can take back to the documents group? Yeah, I mean, I totally agree. We could easily archive that channel and not miss it. And also the light and calling it like OpenShiftDev kind of implies that there'd be actual OpenShift development happening in there, and there isn't. So it makes even less sense to keep it around. If we need to, we can probably make a separate OKD channel. I would think maybe we would even want that on the Kubernetes slack. I don't know. But if we do ever get around to doing our own dev work. Is there somewhere a roster of the developers actually working on OKD? No. There isn't, because there's really Vadim and Christian. And Christian occasionally, yeah. Okay. The Federicois folks don't really hang out in the Kubernetes slack as far as I know. We have our own IRC Matrix channel and we hang out there and we don't really follow the OKD decisions from this channel. If we were going to have a thing that where developer-ish type stuff were happening, probably it would wind up being. I would probably put forth that we'd do a matrix room, and then if we wanted to have it also accessible as a touch point in the Kubernetes slack being able to bridge it there. But the vast majority of the people that in here that are doing stuff like myself, Timothy, and others, we just don't use slack for that at all. Like, I mostly look in matrix and I barely look at the Kubernetes slack to begin with, or the OpenShift common slack even less so. Like, I mostly am living in matrix, talking to the other developers in matrix rooms over there. And it's just the gravitation for developers is just not in slack. I may be a bit of a curmudgeon, but I don't even know what matrix is. Yeah, neither do I, so sorry. It's basically replacing IRC is more or less. Yeah, and it's bridged actually. Fedora actually has a bridge, but there were some issues a couple of weeks ago with slowness in the bridging. I don't know if that's been resolved or not. It seems to be fine now. Okay, the servers are maintained by element matrix services and we have a support agreement with them and they're, they basically prioritize whenever we say something is wrong to go and to go whack it with a hammer and go fix it. Diane, what do you got? Do you have links to the Fedora matrix server? Hold on, let's let Diane, Diane had her hand up. So let's go Diane Christian. I would like to ask a couple of questions. OpenShift Dev versus OpenShift user. So if, if I'm hearing you right and I may not be, you're saying that OpenShift dash dev on the Kubernetes channel isn't getting a lot of usage. Like I haven't looked at the traffic or anything like no usage. It's only like users posting user questions or cross posting user questions between channels. I hear you and OpenShift user is where Vadim would like us to have point people to, if we're going to at the moment, unless we set up something else so that OKD users and OpenShift users go there and ask questions. I'm just trying to figure out what Vadim's preference is. Was it just get everybody in users? What is Vadim's expectation that OpenShift dash dev would be is kind of my question is what should that be? For people that are actually working on developing OKD that are bug fixing or whatever else. There's very, very, very, very little, like almost zero of that going on. It's basically a worthless channel. It's not like the Red Hatters are using it, you know, for internal OpenShift development. Yeah, so if we squeeze this, I'm just trying to think of a first pragmatic step we can take if we squeeze those two into one. Is that Vadim's preference so that he's not getting duplicate questions placed in two different places? Is that the issue? No, the issue is so I can, him and I actually had a conversation about this when he left because I mess, I was like, what are you leaving for? Like, what's going on? And basically he was like, it's useless. People keep repeating questions from the user channel, which is true. And he's thinking that we should just use users dash users instead. And then, like for short lived personal chats, you know, for particular problems or something like that. You think Slack is only good when it comes to community options really, right? So yeah. So we do need, in my humble opinion, to maintain a presence in the Kubernetes Slack. And this is for visibility of OKD as one of the many distributions of Kubernetes from an optics perspective. I'm totally cool with combining the two of them into one, you know, just call or maybe just call OpenShift, just have one called OpenShift, period, rather than users and dev and we can make that request of the Kubernetes folks. You know, Commons isn't used very much, but if at some point, there's no real reason to make something up in OpenShift Commons like an OKD channel. There's some OKD rooms there and chats that happen every once in a while and I get pinged and I send them over to OpenShift user in the Kubernetes Slack if it's technical and beyond me. So I think the very first step that we probably should be doing is rectifying the duplication issue that Vadim is frustrated with. I don't know Matrix. I know Discord and not that people want another thing to log into. I certainly don't. But if we wanted to set up some sort of whatever this Matrix thing is, Matrix 4 is terrible. Don't go watch it. It's just stream at home and watch it with popcorn that you don't have to pay 10 bucks for. But if this Matrix thing is better than Matrix 4, then, you know, and it's what the community wants, we could probably set up a Matrix server for ourselves to use. Yeah. So, you know, and I'm happy to do something like that, especially if it bridges to everything. I think that that might be a solution for us. But I do think we need that public space in Kubernetes and even if in the header for the OpenShift combined Kubernetes Slack, we have a pointer to the Matrix. That's going to blow my mind here. I think I'll keep saying that. Or to Discord, that would be, I think, the solution for watching it. This duplication is terrible for me. I'm in like 20 different Slack things. So if you wonder why I can't find Geetree's thread on the username password, that's because I can't find which one she gave it to me in. So I would say the first thing is to go ahead, Christian, is to ask the Kubernetes folks to combine those 2 slacks for us or kill 1. I would agree with that entirely. I don't think we want to lose the Kubernetes Slack. Altogether because just there's an audience there and people might find it and even though it's not very active and I'm certainly not looking there every day. I think it's good to have that presence. Matrix is somewhat of a ritual successor to IRC maybe. It's a federated thing. Fedora has an instance. We now have an internal RATAT instance on the VPN as well. And that is certainly used a lot by the Fedora community. So I'm already on there and I know other people like Neil and Timothy are as well. So I think that might also make sense. Obviously it's another channel on top of what we already have and if we want to reduce things. But I do think that makes sense as a presence because that's only going to grow in the future, the usage of matrix. So yeah, and having just one channel, it's mostly going to be user usage related questions anyways. And if we need space to discuss some development in the future, then it's definitely easier to just create a matrix channel for that. We could ask Fedora to host us there. I think that's a good idea. And you can actually join the Fedora hosted matrix channel with the matrix account you have anywhere. So Neil, can you take that as a task to ask them to create one for you? Yeah, I can do that. I've already had to do that for a couple of other things already. So I might as well, I can do it for this too. Okay, thank you. So is the general consensus then droppings dash dev from the I agree we should say in the Cooper said Kubernetes slack and keep dash users and then just drop dash dev. Yeah, let's keep open shift users. And you know if we can have it renamed to just open shift. Yeah, I think there's there's a number of existing links out there in the universe and blog posts and everything like that. So if it's renamed, those old links will still work. They will redirect. Okay, well, let's see if we can do that. I would almost say open shift dash okay D. Yeah, that works too. I was going to say saying dash users when there's only one channel. Yeah, I also think adding the okay D name is good because a lot of the community when I say open shift, they think of product licensed, rather than the community supported. But the only thing that I think it might be, I agree with totally with that statement, but I also think there are a lot of customers who go to that from looking. And so it might be that we just need to get the redirect statement or whatever it is at the top of the box description to point to like if you're looking for okay D conversations go to the matrix. I'm going to love saying that. And if you're looking for open shift go to the red hat open shift support line, because I think there's there is occasionally there are open shift people engineers and folks who go there and peak and look and especially during conferences and events. People tend to to hang out there more. So, yeah, but I like having okay D visible. And one thing we might want to do is talk to Chris short. So Chris short has been someone who's been contributing a lot in the dash users on the kubernetes slack and see if we can get him to join the new matrix, because he's an incredibly helpful person and. And he's now he's now at Amazon. So, um, Oh, sorry, I say Chris short what I meant was my brain is not Chris short. Andrew, sorry, Andrew is someone who's really helpful Andrew Andrew block. No. What's this last name Mike I forget. Andrew Sullivan. Yeah, Andrew Sullivan. But Andrew black is also very helpful too. Yeah. Okay. Take care of Christian. So yeah, Andrew Sullivan it would be good to let him know he's really helpful and. And actually Chris short did leave I saw the open shift channels on kubernetes as he was transitioning. I know. So we're sad. He's still around and if you go to kubernetes contributor sake stuff he's in that all those channels very active. So he's I work with him in the open get ups stuff actually he's a participant. So, um, so the one ask I have of Neil I put it in the chat is, if you get that room at fedora is if you could do a little write up blurb for us. And how to, you know, how to get a matrix account from fedora. What the name is, and maybe give it to the docs group so we can put it someplace front and center. Absolutely, I can do that. Yeah, huge. Cool. Thank you very much. Okay, the next item is operators. Yeah, so yeah, I mean, we had this conversation a little bit in the documentation group, but I think it belongs here. And it's really is anything that we can do. And I know that Jamie you're going to talk to the, the red hat. And is it offering managers or product managers to see if they can actually create community supported versions and put them somewhere that's accessible. And, but I'm just thinking, is there anything that we can do or is it anybody would be interested in saying, can we get these operators running because I know there's quite a few of us that are looking for some of the red hat operators. So actually make okay the development platform things like serverless get ops pipelines and taking the upstream isn't trivial. And we run into security context things. They're not in the operator hub that they don't behave the same ways that you are an open shift. So getting that nice usability, even if it's documentation, how do I build my own operator hub catalog with the pipeline name, or is there someone we can actually release as a community. I mean we say we don't do any development in this group, maybe we could, even if it's temporary. So just open up the discussion because this has been around for ever since I joined the community. It don't seem to have gotten anywhere. So, so we did get a little play, I did have a conversation with Christian Hernandez. The Christian Hernandez is the product manager, or I forget what it is but he's basically for the get ops operator. So that would be it falls under. Siamic set it far. You see that right, right. So, that would be the person to get the get ops operator into the community. It does Christian says it does install Christian Hernandez says it does install on OKD. He's like, are you looking to get it into the community catalog? And it's like, yeah, that's really ultimately what we're looking for is not just getting it so that it installs but getting it listed in the community catalog. So there's someone that we can approach. I mean, don't go mob this person, but you know, it's someone that we can we can send someone forward to go and initiate a conversation on at least get ops operator. We could and see back at the moment is he's he migrated to Toronto and then during COVID migrated back to Sweden. Just because they had a baby and then he was long story, but he's definitely open to having that conversation. And so we could have a side conversation Jamie and maybe Brian and Christian. Or whomever is the appropriate person tech side about that issue again, if he's and I'd be open to brokering that call easily. It would be nice to have some movement on that. Now with that, is he just the point of contact do you think for getting the get ops operator or the other operators as well. I think see max probably just the get ops one Daniel messier messer is still the PM for operators and all things operators. And Austin McDonald is the community lead for the operator framework, which is now a CNC F project and he's a red hatter, and he's keen to do whatever we, you know, whatever he can to raise visibility so and get more usage and feedback. So he's another person that we could do so if we wanted to kick off a discussion thread on that and we could maybe just tag a few of them and pull them into a special meeting of the working group on operators. That might be a way to move this move the needle on this a bit more Brian. Yeah, can I comment to the. Okay, so, so I guess I've been, you know, running a version of OKD with students as guinea pigs for, you know, since the. I guess the late pre release versions. So like 4.4 I think. And I'm currently running 4.9. And the biggest benefit in that shift is that in the policy view. The positioning of the little bubbles is sticky. Okay. And I guess in the counter balancing that is that you can no longer delete pods from the console. You have to do it from the command line. So the I don't see operationally a whole lot of benefit from what we're spending all of our time on. And the things that are being mainly flogged in the sales channels, which is, you know, all these operators that Brian mentioned. We've been talking about it for 20 months and there's been zero movement. So like I think that actually getting. Treating those some of the main operators as part of OKD. Rather than optional add-ons that you can go and try and build yourself if you can find all the pieces, which is as Brian was saying difficult. I think that that's actually more important than we have been giving time to. So anyway, I'm just sort of piling on Brian's comment. But it's been a long time. And there's been zero movement. So let's see what we can do. I think this is a point of collaboration with the operator framework group. More so even to get to get some more resources. I mean, this is just some of those operators don't use the operator framework group. Like last I looked at the. Tecton pipelines thing. It was using an older version and I haven't looked recently. Okay, so they might have changed, but it wasn't using the latest version. And so when I tried to build it with the latest version, it was going to be a lot of work. So it seemed, you know, I mean, like the operator framework group is sort of independently moving. So existing operators aren't necessarily going to convert unless they see a benefit. I mean, it would be nice if they all did. Maybe it would make life easier to keep them up to date and who knows what. Okay, I would assume so certainly a new operator would be easier. I mean, I think there are kind of like two issues here, right? One, one issue is like the work that needs to be done to release want something that's currently only on the Red Hat OLM and put it into like operator hub.io so that everyone can. That's one part of it. But then the second part of it too is like the continued maintenance of keeping the operator hub.io thing up to date. And I think this is probably where things, you know, where we get into friction with Red Hat internal teams is that, you know, someone, unless there's an engineer inside Red Hat who is excited and motivated to keep those things up to date for the so-called community versions, because we deal with this in the components I work with a lot too. Unless someone is really watching out for that, it's very easy for those pieces to like slip away under the mountain of like, you know, Jira cards and Bugsillo as we have. And I'm kind of curious if there's a way that, you know, like, I would love what I think would be awesome to see would be like people from the OKD community being able to propose a patch that says, OK, we want this operator in operator hub.io and we're willing to maintain whatever artifact we need to put in your repo to keep that up to date because I think that's ultimately the best way to solve this. And I have a feeling that it's just a matter of getting in touch with let's just take the GitOps operator, for example, like getting in touch with that GitOps team, figuring out what they want to see proposed to their repo to make it be able to be pulled into operator hub.io. And if someone from the community shows up and does that, that's probably like our best pathway to getting these things also in operator hub. I mean, that's just my two cents. Anyone else have any thoughts on this? Well, I just wanted to comment. One short one, James, that in going from 4749, 55 operators disappeared. So it's not like we're going forward. I think it was about half the operators disappeared. I think in general operator hub.io needs more love. And I put the PM who owns it because the focus has been on the customers and the marketplaces and certified operators and all of that things that people pay money for. And operator hub.io doesn't get a lot of love. So, you know, maybe using the GitOps operator to start up a conversation, but also to pull in Daniel Messier who owns operator hub under his domain of things that he PMs amongst other things might be the way to go with Daniel and pull C. Mac in as well to get that and just have one meeting. And so I threw his email and address in there. And maybe Jamie and we can kick something off a thread there about how do we get this moving. Are you going to follow that one up Jamie? Yeah, I will. Since I already started also the conversation on the other side with the GitOps one so we'll sort of collect them all together. Do you want to divvy these up? Well, let's talk offline. We'll figure it out and figure out who's going to do what. Okay, let's keep moving because I do want to go through the. We go year up next. Yeah, so I know Brian just said we don't do development here but I'm going to push back on that notion. Our team and I work on the cloud infrastructure team internally at Red Hat. Our team has been for a long time had requests and been thinking about how to add machines of the control plane into some sort of machine set of their own. And this would be like a big kind of topology change for OpenShift. But what we've come up with because there are a lot of special needs for those control plane machines. What we've come up with is a proposal to create a new type of custom resource called a control plane set that is in some ways akin to a stateful set but for the machines of a control plane. And, you know, we've created an enhancement to describe what we're doing. And during our team discussions today, you know, we thought it would be cool to reach out to the OKD community as another source of kind of expertise in this area just to see if maybe people would review the enhancement. You know, if anybody had comments, that'd be awesome to see as well. And, you know, just to try to help build this bridge between the development of Ocean Shift that's happening and the community that we have growing as well. So really, I just wanted to kind of bring it here for to share the link. And if anybody has questions or wants to discuss stuff, I'm happy to answer. It seems like folks are sort of quiet about that. So if you have any further comments or questions, please feel free to reach out to him for more info. And we'll track, you know, the progress of things as time goes on and have conversations about this moving forward, these types of changes. All right, next up, task list, going through the tax list. Docs group to create a security. I do have a security posting ready to go now that the holidays are over. I can post that basically we want to find someone that can sort of keep an eye on security security stuff and sort of be a liaison for OKD. So keeping track of those things. So I've got a little posting that I'll put out as a discussion and also in the working group for the people that happen to be in the working group currently that are interested, might be interested. Charo, you had something for download stats. Any update on that? I think you have to leave. Okay, we'll check in with them on that. Contact Daniel Daniel in the chat. Or in the meeting at all. Since I think the holidays. So we'll reach out to him. I think he got everything he needed. Brian cleanup of OKD repos and old guides. And that's something I got to do. I'll have to do a pull request. I don't have right permissions within repo. So someone also have to accept the pull request to actually do that. But also that feeds into a conversation that we're going to do with Vadim in terms of what content needs to be moved out of that into elsewhere or vice versa. Right. So Diane research transfer of GitHub, OKD repo to working group and you said that that's sort of been a dead end. Should we take that off the task list or. Yeah, we should just change the tax to move the repo from once you've had the conversation with Vadim move the salient things into the OKD projects repo. Or reboot that so you can. You can say we tried we did our best effort to get people to respond to us, but didn't happen. So, but I think the new task is review with the as you are doing with Vadim what should be in there and then use the one that we reserved and move it forward. Let's see what else do we have here. GitHub user names Daniel's not here to discuss that. So update these notes here. Brian, there was some overt stuff. What was that related to. Um, that's his list of names. So these are the people. Right, right, right. Over. You did. Christian. Yep. Okay, and. Neil did his task already, which is fantastic. Upcoming events. Let's see here, Sandra, you're still here. Sandra, do you want to comment a little bit on a foster. Yeah, we got accepted presenting the OKD virtualization initiative and showing how to install and use OKD virtualization there. Recording have been done and submitted. So we're ready to go. And after, after it's done, after you've given the talk is the talk available online for us to socialize and maybe link into a blog post or something along that. Yes, the video will be made available. Okay, cool. I added a couple of things in there as well. Osdum, they're Jamie is very nicely going to be speaking at an open shift commons gathering on get ops on February 9th. And then we have 2 things coming up sooner than later. Next week at dev conf. And there's a 3rd one that I just noticed when I searched there on career CNI and Octavia. I think that's 1 of your cohorts. Sandra, Sandra. Rohit. Sorry. Is that somebody that you know where if I thought he was no, maybe he's he's an open staff person. Let me just see. But I hadn't career and Octavia to manage OKD services is the thing. It's a plug in that uses it's an open stack a thing, but they're using OKD clusters to do it. Just an interesting thing. If anybody's interested in open stack. Yeah, those are the things that are coming up. Yeah, just for what it's worth Octavia is to load balance their service and career is that container network. Yeah, presumably that's what they're talking about. All right, any last minute of things before we end the meeting. All right, folks, well, let's hope for a successful. And safe and happy 2022. Thanks for showing up and we'll talk to you next time. All right, talk to you next week. Thank you. Yeah.