 Get started with our November 23rd meeting. First folks, if you could put your name in the attendees section, I'll put a link in the chat if you don't have the document handy. There you go. And also, if you could take a quick look at the agenda and see if there's anything that I've missed any sections there. And we'll wait about a minute or so for folks to get that squared away and then we'll jump into our our items. And while you're doing that, this is just a reminder for you and for anyone that might be watching this that we won't have meetings. Let's see, we have 1 more meeting after this and then we're breaking for the holiday season. We'll have our next meeting on the 7th and then we'll be done until the new year and starting back up on the 4th, I believe. All right, and if we're good with the agenda, let's go ahead and get rolling on this release updates. Vadim is not here, but I can share with you what he shared with us, although Christian, you're on the call. Why don't you go ahead? You've read the same thing that I did. So. Oh, have I I'm not sure I have. Oh, okay. Well, I was thinking of that he chatted some stuff, but. Yeah. So, in short, there's an issue with going from 4, 8 to 4, 9. The upgrade tests are failing. And there's a pull request here. I can link to it that. Is an attempt to work through these issues. And it's basically causing a reboot of an odd thing, but he is working at that. And so his efforts are very much appreciated. Christian, do you have anything? Yeah, you want to add to that? Yeah. Yeah, we're essentially only missing the conformance mark here with those 2 reboots that are currently incurred. We haven't quite figured out why that is. We do have a hunch though, and Vadim's following through that. So hopefully that's going to be fixed. If it's not, if it can't be fixed, we will just. Not conform here to the conformance test and just make it really twice. It's not like anything else would be broken. It's just we obviously lose the availability twice and should. The conformance has only happened once, but after those 2 reboots, everything still works. So it's not like there's any serious issues. Just we don't want the 2nd reboot obviously. So, if there's no solution to it, we will still go ahead and release 4.9. That is, although obviously we. Does anyone have any comments or questions about that or anything else in terms of the 4.8 to 4.9 transition? Right. Let's see. Moving on now to F cost updates with Timothy, go ahead. Hey, so the major point for federal Chris is that we ship today the. Rebase to federal certified and stable. So. It's rockers is no fully on federal certified right now. I don't know the exact status in okay D. But hopefully that should come soon. There's a PR open for that as well. And yeah, that's awesome. So we'll definitely switch over to 35 students. Currently, we're still obviously rebuilding okay D on the Fedora core OS. Into the okay D based OS. Eventually, and I've been kind of talking with Jonathan Limon from the core team. Eventually, we don't want to do the rebuild anymore and just a kind of layer on top of Fedora core OS. We'll need some additional tooling for this that is however on its way. There's some interesting enhancements going on on the core OS site that I've just been following from afar. But yeah, that's awesome awesome work on the core OS site. So thank you very much. Timothy and yeah looking forward to all those changes that are coming soon. Yep. Hopefully that should at least the federal certified really we base should help with network manager and everything. And so yeah, and apart from that we've got. Something about merging the MCO that related to all the interaction in interaction with SSH key. Longstanding issues which is now we should not be fixed and hopefully will be fixed. Okay, if I find the PR again. Right yeah that jar merged yesterday and we do have some similar functionality in our machine conflict operator fork that we're still carrying right now for okay the. But yeah eventually that that is one of the last few remaining comments that had to go in. And I think there's only really two minor things that still have to be fixed in the mainline code until we can move back to using that mine item not requiring the fork. So yeah, I do hope we will add that and that's kind of the agreement with the machine conflict operator team that we get all that in into mainline in the 4.10 release cycle which is the current cycle we're working in. So yeah hopefully with 4.10 we won't be needing that fork anymore and that is on its way I think there's only a few minor issues now remaining. I think we're pretty good there. And I think that's about it. I don't remember if anything. Big impact in federal crisis right now so be hit. Excellent. Okay, and. Now we're going to move on to the docs update with Brian and is on the ball or. No, so Brian go ahead and take it away from our update from the docs meeting. Okay, so the docs is sort of live into normal running now from the mk docs update. So everything's done. We've got a code of conduct coming and Michael is sort of worse nipping that at the moment and one area of discussion that came up in the docs work group that we sort of defer to this group is what is the use of the okd repo going to be moving forward because at the moment we've got a lot of documentation split between the repo and the okd community documentation as well as the product documentation. So it's just thought it's probably worth having a conversation as to should we. Move the documentation out of the okd repo and use that for as an issue tracking mechanism and have the document the community documentation in a single place. There's a useful documentation within that get repo. So that's a conversation really for this group to make it make a decision on and get people's views. So what do people think where did the and sorry that I don't know this off the top of my head where did the open shift docs reside are they in the open shift repo on github Christian. Are they in a separate repo what's the structure there. This separate repo just for the box for member correctly. Okay, but are they underneath the main open shift ones. Yeah, we could ask if if people think so I could ask or we could ask the docs team if it would be okay to put okd dash docs there as well if that's what people are thinking would be more appropriate. Is that the gist of what you're asking Brian. Well it was really that if you look at the okd main repo the open shift slash okd repo. We've got some documentation in there there's some old guides in there and there's some how to information in there and it's really should we move that out of the repo and focus it on the. And the okd.io website and make that the single place for community documentation, or is there a use for documentation in the okd repo. And yeah, so that was really the issue. Yeah, and one of the things that that this points to is that again I saw updates actually to the guides, the old guides in the okd repo a couple days ago. I need to mention something to the team because I think the team approved it. We don't want any changes to those anymore. We need to actually delete those because those all got moved. Mike, I think has all of those now. When he moved those over to the okd.io site so. I think what we need to do is decide. Just make sure we have everything updated. I'm not sure how we're going to do that. Like, because people added updates to those recently. Make sure that everything is updated on the website and then delete all of that stuff. And then ask Vadim if he's comfortable with that okd repo. Just being for issues on the software. And discussion on the software and everything else be in the okd.io repo, which I think we agree is going to move eventually to get lab if we can get everything working correctly. Right and take it out completely from OpenShift because the problem is is then we have no. We have a little bit of control, but not a lot. Right. And if we move it, then we can exercise more control and be a little. Or creative with how we do access. That was my thought. So, I think putting it under the OpenShift would actually. Take us in the other direction, right from where. That's what is trying to tease out here. It wasn't quite clear in the chat. Where we wanted to land and someone's put in github slash OpenShift dash CS slash okd and move all the docs over there is what. I think we're suggesting here. Yeah, I think, I think, I think if they put it in a nutshell, move out of the OpenShift. We want to move everything on it. I have a question here. So, like, we, you know, we have like docs.okd.io, which is like generated from the actual OCP, like fork of the product docs or whatever. And then we're talking about the OpenShift kind of more community oriented docs here. And my question is like, if we intend that. Community oriented, you know, repo to be a place where the community can actually come and contribute guides and stuff like that. Then, you know, if that's kind of the ultimate intention, then we definitely need to have that in a place where everybody, you know, the governance can be more community oriented and everyone can feel comfortable kind of coming and contributing stuff there. So like, I think it's awesome to see the guides and all that other stuff move somewhere closer to the community as opposed to being under the official OpenShift umbrella or whatever. Yeah, and Diane, actually, I did open an issue and assigned you to it to investigate the legal ramifications of that. Alright. Basically, we want to know is this is this going to cause any problems with Red Hat or are they okay if we move the document. So one thing we have to ask though is moving this out, it is, it will mean going even further or an even greater separation between the generated OKD docs that Michael is in charge of and the repo that we'll have in presumably GitLab. Bruce was doing some testing to see if we can get the MK docs and whatnot working GitLab. We will be going like even across repository servers as the case. Just something to keep in mind. We already are. We already are because don't forget okd.io the website is served now from GitHub. Whereas the docs.okd.io is served from Red Hat infrastructure because that is the doc server. So we already serve those two from two different servers. Yeah. Yeah. Docs are pretty separate from the code base. So I just, and there's a little chat going on here too that the GitHub slash okd repo has been taken by somebody's who's, you know, sitting on the real estate. But I think it looks like I could reach out and ask and sometimes legal can reach out and ask and get that back for us. Yeah. It's ancient. It's been around since like mid 2000s. Yeah. 2009. Yeah. Yeah. So I'll see what I can do about that. But we'll add that in. Yeah. Reserve Timothy, if you could the okd dash project at just in case and GitHub. And I'll see I'll work on that. Because it's nice and quiet this week while everyone in the States eats turkey. Just picking up from the mics post in the chat. And are we going GitHub or get lab. I think we're trying to have a presence on both and then we'll figure out where we're going to go in the end later. Okay. What why. What is the what is the reason for having a presence on those. Mostly so you don't get like name hijacking. Ah, okay. And I just remember the get lab and come up in discussion the last time we talked about this is like another. Another community oriented location for us. Was it get lab or get hub that changed their policy on. Project names that conflicted with other people's projects. One of them recently changed their policy. Like in the past year about that. I don't remember which one, but. Something to consider, but if you reach out to the individual, it doesn't look like they're doing any commits on the get lab. One, so. They might trade a swag for their GitHub repo or something. There you go. And Christian says plus 1 to mirror and get lab, but linking back to GitHub. Yeah, definitely. Yeah, I would prefer if we could keep all of the collaboration mostly on GitHub just because all of the code. It'll do us no good to have the collab. Once we're in a separate organization, most of the benefits of being on GitHub versus get lab. You can't go all the way because you can't do things like migrate issues across orgs. You can't, you can't actually make for pull request stuff like that. The only main value of doing it on GitHub versus get lab is if you wanted to have like a code fork in okay these project versus on the open shift toward. I'm not sure that's something we actually want to do. But if that is an option that people are actually comfortable with us ever actually exploring them. Otherwise. Well, so Christian, why don't you explain your thoughts behind this because I, I guess I would see it as get lab would. Should be the single source of truth because of the functionality, but you're saying close to the code. What are the benefits of being close to the code for. I think that's just personal. Yeah, for me that's just personal preference because I sent most of my time on GitHub. I don't want to block any. Yeah, I'd be the same way. And it's probably just a little curmudgeoning. I'm just like, oh, GitHub's been good enough for the last 20 years. So it's wrong with it now. I like VI dam you and your Emacs. Yeah, because get lab get lab aligns better with our open source ideologies. That's why more. Yeah, more so. It just aligns more not not completely. It just aligns more. Yeah. Give me until the December 7th meeting that do a little research and background on that that topic and grabbing back the one and I'll see if I can. If there's anything the Ospo team or governance team has to say about that either. I don't know. I don't have an opinion. I just have a GitHub account, not a get lab account. So to answer Mike's question, he said, does get lab have a have or plan to have a discussions alternative? And does that matter here? So, one of the things that we can do is issues. So their thing of discussions, I think is pretty. Much similar, but the other thing that we talked about before was. Tags for issues being for website or code or whatever and breaking things down by the tags for issues or whatever. So. That would cover things that are like issues on the site and whatnot. And then in terms of general discussion, I, I don't know how we would do that. Yeah, because we just moved the support to discussions and getting everyone used to. Right, using the discussion feature. So, if we're going to get lab may don't have that feature and we need to make sure that we. Discussions are a GitHub only feature. Yeah, but I thought we were. The GitHub account for. You know, bug reports and discussions and, you know, like, basically all the stuff that is currently on. The GitHub account. We're still going to keep there that we were just moving all the docs over. Well, I mean, that was, I thought that was a discussion. Yeah, so I obviously I missed something while I was away in the get lab conversation. So I'm going to go back and watch the recordings. And so I, I don't have a preference either way. I just think there might be a cultural thing out in the Kubernetes world where people are using. GitHub more frequently in that I'm concerned a little bit about what the other 300 or so people who'd never come to this meeting might think. That are on the mailing list and the people who are using okay D in production about switching. So, but I think as long as we're mirroring. Doesn't matter. So, I'll just say that out loud on the recording and then do some research. All right. Well, yeah, go ahead. Right. Yeah, I was just going to say, so it sounds like for phase one or step one, we can look at shutting down the documentation content on open shift slash okay D. Get a repo. And then a stage two is where it's all going to live eventually. So, yeah, I'll take a task on trying to get rid of the guides and that put a pull request into delete all that sort of stuff. We probably need a Vadim to look at some of his contribution because he's got things like some step. Partial instructions like to build a release within the repo so we need to work out where that should go and if that is actually worth porting needs updating valid or so I'll reach out to Vadim on that. And just to finish off the docs and 3D has created a draft survey I don't have a link to it and I've just been but we didn't put one in the in the agenda and the meeting notes from the last Docs meeting. So I think we're getting ready to release that it's sort of getting finalized. If we can get a link put into the minutes of this meeting people can go and have a look. Here, I'll bring it up. What did you use? Yeah, what did you use for the survey to survey monkey hasn't done the survey. She hasn't done it. She was doing Google forms, but she hasn't completed all of the things that we talked about at the last meeting. So here I'll put it in the meeting notes as well here. Okay. So she also, I'm sure you guys talked about this while I was way to she also created the OKD Twitter handle. And so what I'm hoping to do with that is push out this survey as well as each time we put a new release out put a notice in that OKD one that that's going on. And then whenever we do a talk or maybe even the meeting reminder to add that in. So it just starts getting some a little bit of content going there. That's very specific to these meetings and talks and events not sort of fluff unless someone writes a wonderful OKD swimming upstream blog post those kinds of things and retweet them there. So, yeah, so that's where I would push out that as well as the mailing list for the survey and maybe even LinkedIn posts there so we can do some socializing and get some real feedback there. I'm just finishing up the task Brian's task. All right. Jamie, could I just throw in one more thing on the on the docs thing. If you look at the way most get repositories are organized. The documentation for that specific code that's in the repository is documented in that repository. Right. You know, so like they'll be a read me and maybe an install and all of that stuff. In our case it's a bit different because we're basically a delta to the official site. And that makes it hard to find if you were going to try and build the code. It's hard to find everything as we talked about many times. So what I'm wondering is if rather than pulling all of the documentation to a separate site. If we distinguish which documentation is relevant to the actual code and pull requests and things like that and leave that on its local get repository, wherever that is, get hub presumably. And the overarching documentation on building okay D. That sort of spans all of the sites is the stuff that we pull over. So that's a clear criteria on that like sort of. That's sort of in a way that's that's a theme question. Or maybe a Christian question. What makes. Like we sort of talk to them off and on about pulling stuff. Over I don't know that we've ever asked them what makes sense to stay there. In terms of the read me. You know document and so on. Well, we have Christian here Christian. What do you what do you think. Well, yeah, I think since we're since the main docs is generated from essentially a shared documentation that is also used by OCP. I think we don't want to lose that because otherwise we'd have to replicate everything somewhere else. And I think it might be easier to come at the what I would prefer is still to have a single source of truth here. And maybe we can convince the the redhead docs team to allow for those guides that we have these community guides. We also pulled into the main main repository but then only be generated for the OKD docs. I think you can just exclude stuff there for the OCP product line and have essentially files that will only be included in the in the OKD docs. Maybe we could add those community guides to the main documentation as something that then only shows up in the OKD docs. That would be my preferred way of doing things just to have all of those things centralized somewhere. I think the fewer repositories the better. I think the issue with that though is it then can be community contributed. I think the whole idea of what we're trying to do is facilitate the community being able to contribute. If we're moving everything back into the official Red Hat repos, we're then limiting it to Red Hat only contribution or Red Hat is having to do the transformation and the work. And so what would I think what we're trying to do is go the exact of the opposite direction. Keep the official stuff that's built as it is now on docs.okd.io but have a community site where eventually we don't have the Red Hat barrier to contribution because it's within that organization. So I think that's the whole idea between okd.io is having that community capability and in terms of adding technical documentation. That's what we're really missing from the project. It's the low level stuff and the stuff that's in Vadim's installer repo. I think that is the primary source for creating a build image, but then that does then link into the upstream OCP repos and pull a lot of stuff in. It's the magic that goes on there as we get into. I mean, I'd like to pick up the whole thing about the missing operators, things like pipelines, GitOps. And so again, how do we build those from a community point of view? I think all that documentation should be okd.io. One of the challenges I think that I certainly have when when going across these projects is just where do I go look. I mean, I've tried to look at building the pipelines and I think I'm on to about six repos of stuff and having it all in the central place describing the relationships. I think it's going to be a lot easier than trying to pick out the repo specific documentation and then me having to try and link them all together. So that'd be my point of view of having a central place rather than distributing it within the individual repos. Yeah, that's essentially the same reasoning as I had in moving stuff into the main OpenShift docs, but I do see the point. I mean, everybody can create a pull request and even for those OpenShift docs, the official ones, but yeah, you're right. It still needs a peer review by some Red Hat employee for that to be able to merge in there. So yeah, it might be better to then split that out indeed. We don't want to lose the main OpenShift generated docs though because that is still very much bespoke and our technical writers to do that and we can get that for free with OKD. And for me, it's just a little bit difficult. Well, I mean, if we can find a way to kind of get both into onto one website, that would be ideal. So you as a user, you'd have you just have one site to see to find the guides, the community docs and the official generated docs. And then that would be generated from two separate repositories, one that the community owns with all the guides and the all that stuff that is currently in the OKD repository also the official repository. But as a user, I wouldn't want to want to have to deal with those differences where does the stuff come from. So yeah, if we could just have one second repository for all those guides and kind of plug that into the into the docs website, make it show up on the docs website as well in addition to the generated stuff from the OpenShift docs. That would be ideal, but yeah, I have, I don't have, I'm not very familiar with with how that is actually generated. Yeah, well, you know what we need is an OKD cluster that we can run a task, a pipeline on that pulls down from one repo and then commits to the other on a regular basis and then you'd be able to incorporate the docs into, you know, the the external repo, you know, just by cloning it down and then putting it into into the docs repository into the community docs repository. So are we good on this I feel like we still need to talk to Vadim, because he doesn't really know he's incidentally. He's sort of missed every meeting where we've had detailed discussions about this just through chance. And so I feel like we should definitely include him in this. Well, it's maybe what what I can do is in the interim between because we're only going to have one more meeting between now and December 7th is. If I can get Char, not Char, Jamie, myself, Vadim and Christian on a quick call in between. And we can maybe suss out what the implications are and pull in Michael Burke as well. I think we have, we have one docs meeting there to between now and the 7th. So let's see if we can do a little quick sprint and figure out what the logistics are. I just don't want to lose the docs teams as resources for generating the okd.io stuff. Do something that would would lose lose those resources. They are very key for us. And I think my gut says that there is a way when they generate those docs okd.docs.io or docs.okd.io, they can add a subgroup of links out in the menu on the side to the guides in some way. And so that would pull from the stuff that Brian Innis has been working on with the make docs and make links there in one canonical docs.okd.io. And the community could still be working on the the guides and all of that and then put pull requests in on docs.io. And that's after listening to everything today. That's kind of where I think we're going ahead, but I'd like to talk to Vadim as well to make sure it doesn't screw up anything he's thinking about. So, right, anything else on docs before we move on. All right, let's now move on to virtualization. Hi everyone. Just a quick update on the virtualization side. We are now implementing automated tests for running okd virtualization with Rook IO. So it's currently still under development, but we already reproduced it manually and it seems to work fine. That's a good news for us. And on the communication side, we are redirecting the existing website for okd virtualization to the subgroup within the okd IO. So once it's ready, we will have everything from okd virtualization to the okd IO website. That's mostly it for okd virtualization side. Thank you, Sandra. Any questions or comments on the virtualization side? All right, then let's move on to any issues. Are there any issues in the repo that folks want to bring to our attention that point to anything that maybe the group can take some action on or improve documentation or anything of that nature? Just like one issue in the chat here, issue 963. I didn't have a lot of time to look into it, but I will continue to do so. I just wanted to know if anybody else has hit this issue and this is essentially the machine config operator is degraded after installation and doesn't come up properly. The logs show that it can't find the rendered machine config that is set as initial node config. It apparently sets that field to a config that does not exist. It's at least not the one that is rendered by the machine config controller. I have internally messaged the MCO and the machine operator team to also take a look. It might be a few days, but if there's anybody who has hit the same issue or has any any input to that, I would be very. Of. Yeah, of a comment or just any input or feedback here. I can do a UPI on these here and see if I can duplicate it. That is because he was is post something to the email list. And something in the chat asking if anyone else has had that. So, I'll take that as an action item just to see randomly if there's anyone else out there that can do that. When you do, I think leverage that a little bit. A little bit more. Any other issues that stand out that that folks think we should discuss or should reach out to the community for. I don't, I don't see anything in particular that stands out. There's only a handful of issues actually that are recent. All right, let's actually there's, yeah, I just, I saw that Sandra opened an issue that is issue 898. I was wondering, have you have you hit that issue again is that still is that still an issue you're hitting because. Really, the Zincati service should be disabled and you are referring to a tumble file. Here that we used to have in in OKD to disable it but we've since removed that file and disabled Zincati a different way. So I was just wondering if that's still an issue I haven't heard back there. I saw it when installing on 4.7 and I didn't really deploy from scratch for the date. So I'm not sure if the issue is still there. I just upgraded from for seven to four eight. So I didn't notice any special case for this, but I can try to reproduce her installing from scratch for it. I can't report. That would be great because yeah, really that shouldn't be happening. I don't know when when we introduced that system D drop into is able Zincati. I think it was before 4.7. So I was really, yeah, it seems strange to me that this was that this would pop up. But if it doesn't happen on for eight and nobody sees it on for eight, I would like to close all those old issues. I really don't want people to or I don't want to encourage people to install old versions. Now we're on 4.8 and people should be installing that if they have a new install. They should be installing 4.6 or 4.7. Obviously, I think back then 4.7 was the latest release. But that seems to be a recurring thing here that people try old versions and come up with problems. And then I don't really want to spend time on that if we've already moved on from that. I totally agree. I opened it in 4.7 because at that time for the tape wasn't yet related so. Oh yeah, absolutely. And that's why it would be great if you could double check it still happens with 4.8 if it's not fixed there obviously that's been issue. And there is a whole bunch of other issues though, our people install older versions. I think it's worth, we might want to consider something along the lines of what happens with Fedora in Red Hat, Godzilla, where when a new release goes out, you know, throw a warning, tag it as like Decade or whatever. And like if nobody confirms that it is actually for valid for the new release, close it after like a couple of weeks. Some sort of general surgeons warning message politely saying, you know, this is that we can put into the comment and then say, you know, if they don't respond back with, you know, they are stuck on, you know, using 4.7 or something like that. Close it. There's some there's some etiquette around this. I think that would be that would be immensely helpful just to keep to keep us focused on the things that are actually that actually still are an issue. And it's kind of similar with more discussions I've been seeing people following some guide from some third party site. You know, we should and I am very appreciative of the docs effort just for that alone, that we should have all those guides in OKD proper and not have people follow guides from some blog they read somewhere, which might be version 4.5 or something. And it just, you know, if they install the current version with that blog, obviously, things might go wrong that nobody's thought of. And it's not really productive to spend a lot of time on those. Yeah, if we could kind of have official installation guides and I think this is essentially what Brian and all the docs subgroup is working on and if we make could make it easier to link that out. I think that would happen less and less but I also don't want to just shut those discussions down with you installed the wrong way and nobody does it like that. It's not fair, but just, yeah, just as an additional comment here. Yeah, the less we see off of those, the better. You're in that. Oh, sorry. Go ahead. You're hitting my one of my mantras of I hate documentation by blogging. We're doing the work around having the Twitter handle starting to raise the visibility of OKD dot IO and the OKD Twitter handle and just trying to pump up people and direct them to the right places is really good. Go ahead, Jamie. Sorry about that. That's fine. Always feel free to go ahead. We did see one come in recently. It was like an issue. I think our discussion item where someone like had four different links to like external guides and they were asking for our help. And it was like all of these random places that they got the info from and it's like, well, where do we start with that? We'd like to help but it's kind of hard if we can't point them directly. Yeah, for sure. Anything else on that before we move on? All right. So, now we're into discussions. Sandra, you want to go ahead? Yeah, you have the question here. Yeah, I was asking if we have some press plan or some common messaging for the coming for dot nine release. We do have something like that in overt. We use it to have it. We are not really following it anymore. But we use it to send out to press when we were releasing a new major. Yeah, the documentation group talked about this a little bit, but we don't really have anyone that's that's volunteered to start putting that all together yet. I don't think. I don't think anyone volunteered at the last meeting. But yeah, that's definitely something that we want to do. And I think basically what we talked about was, and we talked about a little bit in this meeting as well is create a document and start putting together like bullet points of what are some of the. So, for nine is coming. What are some of the benefits like we can riff on the open shift official documentation and release stuff. And then, you know, create our own. That's, you know, makes the case for upgrading to for nine basically, you know, the benefits and we're going to make Christian right it. Yeah, I'll just add on that. I'm on the open shift four dot nine marketing thread. So they're building a blog posts, you know, and each of the releases there's a thread and a group meeting about what we're going to publicize and four dot nine. So I kind of have an early warning system for what is going to be the official open shift stuff. So, sharing that and then shape shifting that with the docs team into some sort of a missive blog post or whatever we're going to do or just, yeah, we can do that easily if I if I remember and then if I'm not the person. I can find someone on this Kim from red hat drives that effort. So we can ask her also to give us the draft release before it gets published and then do a version of it. And add any fedora core oasis. Yes, that we should. And we'll add that as a task item for the next docs meeting is to actually start that official effort for 4.9. Okay, and just to add to that, and based on the previous conversations, and do we need to go and update the guides for four dot nine. So they don't know how to date out of date information. Yeah, so I think that's big. That's going to be bigger than just the docs group. So I think we need to reach out and ask for volunteers across all the various platforms. I think we probably do need to plan and do we have Christian do we have a sort of an ETA I know we can't give, but are we looking in terms of days weeks months, your best estimate. It's definitely days now if we don't get this to work. Let's say by Friday, then we will just skip this one conformance test that we're not attiring to right now. And the next release, which I think buddy always cuts them on Sundays will then be. Okay, so anybody want to Thanksgiving project or a Christmas project. I could chip away at this over Christmas a little bit with the help of someone else wants to join me, but not Thanksgiving. Yeah, not Thanksgiving for you guys. Yeah. I'm, let's let's talk about it at the docs meeting next Tuesday to and see, you know, who are the original authors of some of those guides and reach out to them. As opposed to you taking it all on. Maybe it's a simple thing to collaborate with them. And I will dig up the. Sorry, I just I also think we need the, the variety of platforms because not everybody has access to all of the underlying platforms. I can certainly do the overt and play around with that one but I don't have the sphere. Access. I've got these fears so I can do that and there was there's someone else who has, and we can actually reach out to people who we know are using these, but maybe haven't written docs before. And we can say, hey, we've got this doc that needs updating the original author is MIA or doesn't have the time. You know, would you be interested in taking a look at this and see, I'm thinking in particular of Kai, for example, so if I didn't have time for UPI v sphere. So Kai is on it in terms of UPI v sphere, okay D so that would be someone we could reach out to. I could spend a little time doing, doing an open stack deployment. That would be awesome. I mean, I think I kind of have it figured out now so yeah. If anybody has access to bare metal machines, we have now included all the bare metal parts in the payload. We haven't been, we haven't found the time to set up and to test from our side. But theoretically, this should work now. I don't think anybody has tested it yet. Anybody has access to at least, I think you need at least four machines, three masters and a bootstrap node. That will be super awesome if somebody could test this. Unfortunately, I don't have access to those machines either. And also use over to VMS as bare metals. It won't be really distinguishable. So do we do want to get together a list of people per platform. Yeah, we talked about doing this before, but we just didn't have anyone to back and we talked about this like months ago of like, basically generating a list of who has access to what platform. But we just didn't have enough people to support that and if someone wants to take that on like you. Good sir, that would be fantastic. Sure. Okay. So, so right now, we have, we have me on open stack. Who else just just gave their names. I'll write it down right now. So Brian on over it. Okay. Jamie on vSphere. Sorry, Jamie you on vSphere. Yeah. Okay. Anyone else. I don't want to volunteer myself right now, but I did want to put a link down somewhere maybe this is the right place here. We do have a PR open to add and to and test for open stack and that's this PR has been open for a long time just never it just never worked unfortunately so far. So if any, if you get open stack to work, and you could also have a look at this PR. Maybe you see what's wrong with the PR currently, but he has been doing an awesome job rebasing that from time to time. I think the last three basis a month ago now already again. So, yeah, just if you see anything if it works for you and you could also have a look at the PR. That would be super awesome. I mean it is our release repository job config stuff that's in the PR. So it might not be super clear, but did I link the right one. So, yeah, just just in case if you have the time that might make sense, I can it. It's not super clear because it doesn't it just adds another job config and links out to an existing workflow so you you'll actually have to look at the workflow is not at the code that is added in the PR. If you're diving into that I can definitely give you a link to to where that workflow lives. Well, thanks Christian Diane said something here I wanted to touch on real quick. They said we can create an issue and tag them with a note to ask if they need help. One of the things is Mike I don't think we had an account for every single guy did like like basically the guides got copied over but it's not like the users are there in the system to be able to tag them on there. I mean it looks like the metadata got room. There was some metadata some header information we had in the old format that was preserving kind of like who wrote it and when the last time it was updated but it looks like some of that stuff probably got removed, probably because it doesn't fit, you know, the frameworks we went through. Yeah, I just think if we can, you know, give credit where credit is due, first of all, and then we can add them in, and some of them may have disappeared off the planet, you know, and doing other things so that happens all the time. But as long as we have that information in the make docs version or the right places, we could create an issue tag them with it with a note. You know, if they that 4.9 is coming, do you need help updating your guide, blah, blah, blah. And yeah, finding the time is always going to be the hard thing. And then if they say yes, they need help, or they don't respond at all. Then we can go in and tag a few other volunteers from maybe from Daniel's list. Yeah, I can see what we're doing out. But that that that's that way we would have an ongoing thread with the author and credit them and I can find more swag to hand out for every every time we do an update or something. I think, I think that's my view. I mean, yeah, that was kind of the idea of being able to use like a metadata block at the beginning of these documents is we can say like, you know, who's worked on this. When was the last time it was updated? What is the known version that it works for? You know, just to help it bake a little provenance into these documents. Yeah, we can actually put we can actually put metadata blocks and comments mk.com and knock down comments. Sorry. If you want to put that back in and that doesn't get rendered then. Yeah, that would be great or even render it and then that people get credit where credit is due. We could talk about that next week in the docs meeting after you all eat turkey. But I think that might be an excellent way of doing it. And then any additional volunteers can pile on to the issue that's created for the next release and that can be part of the release tasks each time a new release comes out. So for any of us attending this who are not familiar with the docs meeting, what happens in the box meeting? What's the scope? It's basically discussing everything documentation oriented the website specifically. Yes, yes. Okay, okay. Yes, just to be there actually if you're interested in sort of heading up this list and stuff like that. I hope you were there. How do I get it? It's the same. It's the same date time link and everything. It's just next week. Yeah, exactly. Yeah. If you go to okd.io and look there there's a link to the Google calendar. Yeah, well actually just posted the Fedora calendar, which you can just add. Which I'll say the Fedora calendar. Yeah, sorry. Actually, something. Oh, something broke in that calendar when I don't know. I think Jamie when I added to you and I don't see I used to import that calendar into Google. And it doesn't work for me anymore. I don't know if anybody else has the problem. It's just that it doesn't show up. The calendar, the Fedo Cal was redeployed onto an OpenShift cluster and somebody goofed up the data when it was done and so the data and the configuration. It should be straightened out now. You will just have to configure it again or re-import your subscriptions or whatever. It was related to how they, when they tried to migrate it from a VM to a container, they goofed it up the first time and then they fixed it later. Yeah, I tried to invite this morning and it didn't work. I had to go through importing Thunderbird and exporting it in order to be able to import it in Google. All right, let's take this as a task item to take a look at. We've got 3 minutes and I want to make sure we get everything. And so what task item is that we will look into the. And make sure that it is addressed. Diane, you had some something about DevConf. Go ahead. DevConf. CZ is coming up. We have a working group meeting and a talk that were accepted. I know Christian's going so I'm not, I'm not going to be able to go because of COVID and travel restrictions. But so if anyone's going and listening to this video and you're going to DevConf and Bruno, let us know so that we can, you know, coalesce and figure out the speaking gig and attendee stuff and do promos for that. The other thing that I wanted to mention today is the KubeCon call for papers closes on December 17. I was, and I'll nudge you separately Christian around the arm stuff and other things. If anyone has something that they want to submit, get it in now. If you need help, let me know. I'm happy. I'm not, I'm in Canada now so I'm not eating turkey this week. I'd love to help you with that. But I would love, I'd love to have some OKD being, even if it's not talking about OKD, but you do using OKD as the Kubernetes distro that you're demoing on. That would be bloody awesome. So some of the ends, and we can figure out how to get it, tweak it so that it gets there. I'm also going to be hosting an OKD, not an OKD, an OpenShift Commons, this one, this hat gathering at KubeCon EU. So I am once again looking for a OKD end user story. So if anybody knows of one, and one of the things that I'm going to try and do on my Thanksgiving and holiday break is create a list of everybody I know who has OKD in production. And so that we have sort of a real end users working group for that. So that's, that's my quick and dirty on that. So anyone needs help shape shifting for that. Anyone going to Bruno and anyone using OKD in production has a customer or end user story with a cool workload. Let me know because I'm looking again. Alrighty, any last minute thoughts were right at time. Christian, did you find out what field that is that's quality on the calendar? Yeah, I found it out. I'm just looking at the source file here. And it was the recurring, I have to find the name. The field that actually sets that it's a recurring thing, and that is, that doesn't work. The R rule frequent, maybe that is different now. I think. Well, so we'll put it in the channel once we figure out what it is. Yeah, yeah. I'll probably just file an issue with the Fedocale book. Okay, sounds like a plan. Thank you folks. We have 1 more meeting before we break for the end of the year. And if you can show up for the docs meeting. Perfect. Take care.