 Folks, welcome to the OKD working group meeting for February 15th of the year 2022. And take a quick look at the agenda and let me know if there's anything that you want to add or add your own items in there. Move one thing around that there's. Right. Let's jump right into it with OKD release updates. Now, there we go. Yeah. Perfect. So some of the updates. As for the releases. For nine is proceedings hopefully we're just rebuilding and fetching the latest changes in from door 34. I think few CVS I think picks up which is full kids. And probably one relates to the canal. These are definitely should be in but they don't affect open shift. In general, this very low. So we're pretty safe on this. For 10 is approaching release in the state. So we have switched to the door at 35 there. And we're building it based on the latest yours was stable. In 411, we started experimenting with a feature called cross layering. That's an improvement in the RPM is three, which allows us to use an existing container already contained into the request layer our opinions on top and proceed with the release. That would help us pin to exact the request releases without rebuilding and distribute all of our dates in in the images. There is an enhancement for the open shift to extend this so that folks would be able to add their own custom configuration on every upgrade on top. I'm using build complete discontinued rebuild. So that would help us bringing things like drivers on every single upgrade more easily and have a better controlled way of distributing one single image into the multiple. We're so far using this in 411 master not yet merged. But once we'll have it will probably date for 10. The rest interesting thing happens also in the installer. Notably, we have adjusted the existing tech preview assistant installer to make it work with equity. That sort of now system solar is a web service which allows you to basically install a cluster using a classic wizard style. It generates a so-called discovery ISO. So once you boot from it, the machine will be registered at the service and you will be able to tweak its hostname to see. Network settings to see how the disks are being laid out and prepare for the installation that's happening. It also ensures that machine has valid DNS records, all things necessary before being installed so you are able to fix them. We're not with IPXE. You're also would be able to boot this on the machines which don't have access to virtual media like AWS for instance. It also uses bootstrap in place mechanisms so you don't need an additional machine for bootstrap. One of the masters would be used as a bootstrap seamlessly. And it also works with single auto. Yeah, that's pretty much all I have from the release point. Any questions for Vadim on anything that he was talking about there. All right, thank you for all your work Vadim. Up next is docs updates Brian. Okay. So we had our meeting last week and number of things come out of it. I think the first one is that the code of conduct and the deadline for comments is today. So there is a discussion item there so if you haven't gone and read it and had a look at it and you want a chance to comment. The clock is ticking. I was just going to say one of the outstanding questions on it that I'm trying to get resolved is the email to whom the any questions or issues are addressed. And at this point, legal has not given I put a couple of requests into them and they have not given me feedback. What I was going to suggest is that we just have put an alias in the website and have it come to me. And I will and I will address it with the chair, whoever the current chairs are of the of the working group and bring it to legal. I don't think there's an issue with that at all. I'm just trying to get them to give me something in writing saying that's the correct thing to do. We've been setting up an email server for okd.io. We just in the web link call it that so we can we can work that out that way, but they didn't have any objection, but they also had no response to so that's never a good thing. But I think we just need to move if there are no objections in the next just in the next iteration close it and and make it happen. Okay, sounds good. On a similar note, we're doing some work to actually tidy up the existing github repositories to actually get ready to move. We are setting up an OKD organization on github where everything's going to be located so we're going to move out of the open shift. That will allow greater community involvement in those github repos because there are some right restrictions where we are at the minute. So I'll just make our life easier. So we are doing some cleanup. So one of the items that we discussed was the community repo. There is a community repo in the open shift org with five markdown documents in it. We're going to roll them into the OKD.io. So they'll come into the community documentation site and they'll be surfaced the content of the documents will be surfaced on that site. Also, we're looking at the content of the main open shift repo. So that's where we do all our discussion and issues and reporting, but it currently has some documentation in there as well. So the idea is that we're going to go through that. We're going to pull out what documentation we want to preserve. And the decision has been that the official product docs are on docs.okd.io. That is run by Red Hat. It's a version of the official open shift OCP documentation customized for OKD. And then we've got the community documentation site, which is OKD.io. And that's where all documents should live, technical and non-technical. So that would be the single source that we send everybody to. So that said that we want to move the documentation out of the main OKD repo. And that sparked a conversation, which I don't think we actually got to a conclusion is what technical documentation do we need? How deep should it be? What should it enable the community to do? So that is a conversation that's ongoing. To start with, we're doing some research. So before we actually start bugging some of the Red Hatters and asking for their time, we're going to do some research. And what's in the repositories and what can we figure out? Should we allow somebody to actually pick up and be able to do a custom build of OKD? If you're on the technical docs, should we allow them to go and create things like customize the operators are installed or maybe customize the operator catalogs that are installed? So all these sort of conversations are happening. And as I say, we haven't yet come to a resolution. So if you want to chip in on that conversation, either come to the docs group or put comments in the discussion in the OKD repo and we'll be moving on. We also talked about the operator, but I see that is on the agenda. So I'm going to leave that one for the later item. And today Daniel created some issues to actually kick off the initiative to start the guides for 4.9. So I think we'll pick that up at the next docs group. And I also noticed there's a discussion item being added to today's agenda. I think we need a little bit of coordination just so there's some commonality across the guides and there's a similar structure and they don't look like they've been written by six independent people with totally different ideas of what should be in the guide. So we'll coordinate that. We now have access to the Twitter account, but I don't think we've decided what to do with it yet. I think Jamie and Diane have the ability to tweet on our behalf, but we haven't really decided what we want to do with that. And I'm just looking through the agenda. I just have a quick question since we have Vadim here and I haven't seen his face. One of the things that I have done a couple of tweets and I did a tweet on a release. And I was thinking to add into the release process very standard template to, and if I give you privileges to the Twitter account. If you can just grab basically what you put in the email, a slight variation on that, and just tweet that out each time you do a stable release. If you don't have the bandwidth to do that, I'm happy to do that myself, but I thought that might be an easy, easy thing to do. And the other thing is on social media, I am now told there needs to be three people who have access to the keys to the kingdom for security reasons. Not true. I passed the quiz today and you have to have just two. But yeah, using it for release notifications is that would be useful hopefully to get some notifications from from the community because mailing list is mostly failed. So I think Twitter would be the video. So if I, if we are the two Red Hatters and I also give it to Jamie, then I think we are recovered by for our social media standard. I took that quiz too. And but prior to that quiz, I got reprimanded for not be using bit warden. So we will do that. And it's all fun. And I'm not sure Jamie, I can give bit warden to you. So there's that whole thing. So anyways, we'll get you on it. You will be my second and then, and Jamie, we will figure out how to get you access. So if those three and then, Ryan, you're kind of the acting head of docs right now. So if I can figure out how to get external people into bit warden, I may ask for an exemption from bit warden, because this is an external thing. But I would think that the people who are basically sharing the different roles are the ones and then the overt, the virtualization folks and if the micro shift people come in, get them into the cadence of that too. So but I really do think each of the releases as you do it and I, I wake up and I see your note and then I forget to log in. So I think it's better if you did it. So Vadim, you're able to do that. I just want confirmation that you want to do that yourself. Yeah. Okay. Excellent. Well, just want to be sure because it, you know, it was pointed out by other people in the community like, Hey, you've got, you know, these releases coming out and no one's promoting them. We definitely want. Yeah. And we can almost automate it too. We figured this out right. So when you post it, we could probably strip it, but that's another stage. So there you go. Is it too much to do blog posts for it? Do you think, Brian, what's your thought. And given the number of releases that we have. I mean, I think the Twitter for me would be the most useful just to know that it's there. I mean, obviously, if you are using OCD regularly, you're going to get the notification through the, the update manager that there's an update available. I think having a Twitter was a tweet. I think a blog post, if there's anything that needs to be explained or anything. Yeah, if there's any new features or if there's any gotchas or if there's a beware of this, if you take this one, you may have to go and twiddle something manually because there's some change. I think things like that warrant a blog, but just for a, an incremental release, a tweet linking in maybe the release notes for that release is probably good. We should do a blog. If there's any sort of gotchas or any, anything we want to specifically point out on a new feature or new capability that we want to add. Okay, and there's one more thing on the docs. And that is that we now have a presentation template in the chat. I actually did post the link to it. So if you're ever speaking anywhere and you want to know KD template for a presentation, it lives in Google Docs. The link is also in the HackMD for the docs. Docs meeting, the agenda meeting there. I'm not sure whether we have any way. I'll also add it into the, if we think it's a good idea, add it into the documentation or is that something we want to keep just for this community or should we make it more generally available for people. We can take that in the docs meeting next week. Don't make that decision. And that's it. I don't think I've forgotten anything. Okay, great. Any questions for Brian in regards to documentation stuff. We never actually, sorry, we never actually did resolve what we're going to change the name. That was the other thing that we talked about changing the name from the docs to community or communication. Yeah, we haven't really tackled that one. Does anyone in this group have a sense of if docs working group subgroup still captures what it is that that group does, or should we, you know, I've weighed in, Diane's weighed in, Brian has weighed in a little bit, but anyone else here in the general group have a thought about should that subgroup have a different name since it does more than documentation. So does everything it does fall under documentation, communications, Twitter. Communication seems to me a little smaller than our mandate, like it's a sub part of documentation, but that's just me. And on the other hand, when I hear docs group, I'm thinking docs.okdi.io, nothing else. So we would need a very encompassing word which includes all the things you guys do. I'm at a loss to come up with a better word. So anyone else have any thoughts. Mind share. Minecraft. We could do Minecraft. Devrel. Is that close enough? Yeah, that's probably close enough to what's actually happening here. I don't particularly object to documentation also including. We know one person things, but I understand how that's confusing. I like, I like Devrel actually I was thinking something like outreach, but that's probably. Well, that's where I got the idea of mind share because that's typically where that that typically comes from but like, I like Devrel. All right, well put your put your suggestions in the meeting notes, and then we'll take them back to the docs or currently docs subgroup and talk about them some more. Let's see. Next up are the platform guides. Take it away. Okay, so Brian brought up a really good point when I filed issues against people who had interest in writing guides. I think we need to. spend a little bit of time figuring out what these guides should be. So that, like, they shouldn't be a copy paste of the standard install docs, right? There's there's not any value in having a copy of those. So, my conception was as simple as it's more of a story of here's the decisions I made when I did this particular install on this particular platform. But if we want to talk about it more, should we do that here? Should we do that in the in the in the docs meeting? What do people want to do? Well, I think we're missing two of the contributors in this meeting. So we probably need to arrange a time when the contributors have volunteered are all going to show up somewhere. Gotcha. Okay, I do that. Well, we do it offline as a discussion forum. And that people contribute within a discussion topic on the repo. Okay, get it face to face. Do it. See what happens. Sorry, go ahead. No, go ahead. Yeah, I like the idea of trying it async and seeing what happens. Okay, then I'll start a topic in the in the discussion group and and we can come to consensus on what those guys should be. The I guess I'll close those issues for now since I'm not sure it's worth having issues for work that we haven't decided what the shape of the work should be. The other question is, are we close enough to 4.10 that these we should be preparing guides for 4.10 rather than 4.9 at this point? Vadim, what is your sense of timeline? I really hope that we won't have to rewrite any guys for 4.10. We literally have zero changes, notable changes to zero. We would have bare metal IPI since 4.10. That requires quite some hardware. I don't think Charo's nukes can boot from IPI and things, so we probably won't be able to ask you to produce them. In any case, that requires a totally separate guide. We won't have to update them. From what I've seen, quite a lot of folks are still using Charo's guide, but we're still using guides from OPD for the five times and they are apparently successful. We are just like adults in month, but we definitely won't have to rewrite guides for 4.10. When do you think the dailies will be stable that we can test that? They are stable. We can release any time. The problem is upgrade jobs and feelings. That's an OVN bug that would manifest itself as an API breakdown. We can work this around any day and go with the stable. Okay, so maybe as we write the guides, we test them on the 4.10. Daily just to double check. Okay. Thank you. And good call out there, Brian. All right, I think we're ready now for our Fedora Core OS updates. Is that right? Okay, take it away. All right, can you hear me correctly? Okay, great. For Fedora Core OS, it's rather calm those weeks, but we've started working and looking at the changes for Fedora Statistics. So Fedora Statistics is coming later. The beta is coming something like in two or three months. I don't have the timeline at hand, but as always, we start looking before the release happens, before the beta, we start looking at the changes. And I've added the links into the Hackindy for the tracker we've made for all the Fedora Statistics changes. And I don't think we have any changes really impacting OKD. They will be some DNS over here that support ID2 system D resolve D, hopefully that won't impact OKD, but that to just be tested for sure. And yes, apart from that, there are any other changes. Yes, there is still one of the changes that will be coming with Fedora Statistics is that the move from Podman 3 to Podman 4, P3 before. But as OKD only uses that for bootstrap, I think that should be also mostly fine. Yes, all the containers run with credit. On the Fedora, more Fedora credit side things. So we finally trying to move away from IP tables legacy backend to the new NF table based backend. And that should happen sometime shortly. I remember if we have scheduled it for the same time as the Fedora Statistics release, but that should be closed or happening soon. I don't think that either will create any issue for OKD, but just mainly that. And yeah, I think that's the main items right now. The one for the IP tables change, it might impact third party operators. So someone from the Typhoon distribution said that CDM, for example, needs some special configuration. So, folks that are running and things like that should take a look at the application for CDM to make sure that they match the type of IP tables backend that we're using. I'll try and link the exact comment. Excellent. Any questions or comments? Thank you so much. Let's move on now to the rest of our current items list. So shut down the dev slack. So we've all agreed to do this. Diane, what do we need to do? I just need to go in and kill it. That's it. If everybody's on board with that, the DM seems to be on board with that. We'll just go kill it today. Today is the official end date of that channel, and I will go in and retire it. Archive it, is that correct? Archive it, yeah. Retire it. Archive, yes. Is the dev slack a channel within OpenShift Commons, a different Slack workspace? What even is it? It's in the Kubernetes Slack. Yeah. Oh, okay. Yeah, there's like three slacks involved here somewhere. So I'm just going to retire it. It's had a message in it for a week or so. Wow. And yeah, we'll just archive it. Cool. All right. Next up is, should we create a Google group for announcements? The docs team was sort of talking about this in the general sense was, no, we can put announcements in like Twitter or other places. But do we want to, the flip side of that is do we want to encourage people to look for announcements in the working group? Because some things get sent to the working group, like, so Vadim posts updates in the working group. And some folks have said, well, you can go look at the working group for this update on OKD and stuff like that. And I think if we're going to say that, I think it might be helpful if we just not discourage, but we avoid directing non-working group people to the working group list, lest people start asking user questions again. And I think we got one this morning that was a user question in the working group. In other words, it would be nice to keep the working group Google group just for working group business. I think any thoughts on that? Yes, no, maybe so. I think it's a good idea. I found that GitHub discussions are very useful things to help users. And they're terrible at coordinating the work group at the start. I like this idea. I think it's fine as a mechanism that we can offer user assistance and whatever, because aside from it being asynchronous, it's also directly linkable. And one of the problems I've had with... All right, I actually'll say the biggest problem I have with people asking for support in the Kubernetes Slack is that it's invite only and on top of that not indexed anywhere. So the knowledge just kind of floats away into the ether. The new OKD matrix room, if people want real-time chat, all the messages are there. We can always export it and turn it into documentation, whatever the heck we want. When it comes to the stuff that's on GitHub discussions, it is always there forever. And we can just, again, incorporate that into documentation or links or references. It'll be Googleable. Same goes for the mailing list. But it seems like the mailing list isn't terribly helpful for people. So I'm okay with Vadim's idea here. Any other thoughts? So is that... we're going to move to matrix? Sorry, I got distracted for a minute. Well, I think we're going to see how it goes. We haven't even started promoting it yet. So I think we have to see how people deal with it. I do like the idea of technical discussions being in the discussion section of the repo because then people can look right at it and follow it. And solutions can be listed as solutions and stuff like that. Oh, so next up is security liaison posting. I didn't know what else to call it. This is the thing that I've been working on. I did it a long time ago, but just didn't dig it out until recently because now we have Twitter. Basically, we talked about this in the docs group and in the main group a little bit. The idea is that we need someone to post about security stuff, at least so that we have some security posture that's visible so that people know that we're thinking about it as opposed to just being like, oh, yeah, we have red hats talking about this. So here's what I came up with. Docs group didn't really have any much feedback on it. The idea is that we'll put this on the blog and then Twitter it out and see if we can get a volunteer and also put something in the working group posted there. So we can get someone to volunteer to do security stuff, like just track down current bugs and stuff like that, vulnerabilities, things that are security oriented and then just be able to formulate a response in terms of OKD so that people know that we're cognizant of the fact that these are on the radar. One of the reasons is because we get a lot of questions in the chat in particular about does this impact OKD? Are you aware of this? Et cetera, et cetera. So it'd be nice for us to have a concise response to yes along the lines of, concise response along the lines of yes, we're aware of this. It's on our list or no, it's not on our list. We will add it to our list or something. Does anyone have any feedback or thoughts on this? We just go ahead and post it and send it out. Any comments on the language? No, I'm good with it. I'm fine. Anyone else going once? Going twice? All right, we'll put it out. We'll see if we can get a volunteer. If there's anyone in this group that wants to volunteer to do that, just let us know. I mean, it doesn't involve a lot of time just combing through, you know, open shift security vulnerabilities and maybe F cost security vulnerabilities and just sort of putting it all together and in one little place and sort of being up to date. Timothy, can I just ask Timothy how they do it for F cost? Do you do any security vulnerability postings for the F cost project? Oops, you're on mute. Sorry. There you go. You're on muted now. Oh, no, it's it's unmuted here, but we still can't hear you. Okay, is it better now? Yeah, it's better now. Okay, sorry. Yes, we don't have a posting or release notes yet on this front. So we essentially rely on the federal ones. Because they are already some federal security or something. I don't remember the details. But what we're trying to do is improve at least when we do specific release for security vulnerabilities that we mentioned that into the release notes on the download page. If you take a look at that here on the main page here with the release notes, which are right now mostly about package updates, we're working on trying to add short links to issues we fix into a given release. But that won't really, that will not really be a tool and compete accurate list of all the cities that will be fixed in a given release. To do is that we would need another worker that we another. So we have support in the system to display the vulnerabilities that we would need something to post that somewhere, which we don't have already. When we do a release that is there, it has a security thing. Is there any flagging in the release notes that it's there's a security fix in there. Now the release notes are being created automatically from full request titles. So if CV number is mentioned there, which is very likely, we will have it. If not, it would be a link to a bug, which we probably could refactor later on and collect which ones are related to security. That's global. I can see. Thank you, Mohammed for volunteering. I can see you in the chat volunteering to take this on. So we'll, we'll, we'll see you in a bit, but anytime we can automate something, like if we can grab a metadata tag on in the release and just put a note. I think that's probably step one, but also, yeah, whatever you guys come up with that would be wonderful Mohammed. So thanks. Excellent. So it looks like we don't even have to post anything. Mohammed has volunteered. This is great. It's. I really appreciate that, particularly over the past like year, lots of people in the group have been stepping forward, take little bits and pieces of stuff that's really propelling us forward quite a bit. All right, so moving on to the next. So just a quick, quick, quick note. I think if OKD is publishing also the version that are included in the US content for the version of packages, like we do in OCP. I would probably make a script which will like pull a given release of OKD, list all the packages, look at the federal database of all the CVS for which versions and then correct the two and then post that somewhere. So, you don't need to spawn up a full cluster and that to do just that. Yeah, that's good. Excellent. I'll add that to the pipeline of things to do to assemble the security release. Thank you. Moving now to operators. So it was discussed at the docs meeting that the place to have the continued discussion on operators is that same ticket that Christian opened. We have the names of folks to bug. So we're going to start those conversations and put our results of those conversations in that same ticket in terms of trying to first finding out the viability of getting an OKD specific catalog. And then from that discussion, depending on how that goes, the idea of getting some of these community operators, some of these things released as true community operators. And we've all reached out to various operator point people. And so let's start putting all of that info in one place so that we can track and see who's talking to who and what the responses were on these comments or questions on the operator sort of subject. Again, this is to provide operators that are OKD specific and ideally get some of the red hat operators that should be community operators we think available as true community operators and possibly an OKD catalog in and of itself. Let's see, then we're up to tasks. Let me get 410 411 update info. I don't know if anyone noticed, but there is. I think scheduled for Thursday, a video presentation from red hat. It's tomorrow at 10 Eastern, I think. Oh, tomorrow. Okay. 10 Eastern. Alright, so this is the, you know, usual, like. Three hour video presentation on all of the things that are coming. And so I'll be gathering stuff from that and I'll be gathering stuff from docs. And we'll like basically assemble a list so that, you know, as we talked about before, thanks for the ideas to get ahead of the ball on a release so that we can be like, OKD 410 coming soon with all these great awesome features. You know, gotta hype it. Right. And let's see what else. Charo is not here. We don't need something. Charo is not here. I can touch base with him. Micro shift invite. Has anyone approached the micro shift folks about inviting them to the meeting? I will reach out to them for the next meeting to see if we can get them on the agenda. If no one else was, unless Vadim, you have a close contact there. Yeah, I could ask them to ensure. Vadim, I'll put your name next to that item. And then a bookity repo of old guides. That's you, Brian. Yeah, I've sort of, I've sort of combined this one with the work that we're doing to consolidate and clean out the repos ready for the new org. Right. And that's actually the next item. So, Brian and I talked with Vadim. And Vadim was suggesting that we put in PRs for changes to the current okay repo. Because there's who else did you want Vadim to take a look at that to those changes. There was someone else. Christian wasn't it was a Christian. No, it was. Who else was it Vadim that you wanted to take a look at the any proposed changes to the okay D repo before we like clean up. Was Clayton Clayton that was it Clayton, right? Yeah, yeah. Yeah. Don't expect so much attention from Clayton, but yes, I could ask. I mean, yeah. Okay. He's the only one that if anybody would pay attention to I've asked Chris Alfonso in the past as well. Vadim and he's he's pushed. I think we want Clayton or somebody high ranking just from no overall view to give us an impression. First of all, what we're missing. We know we're missing measure, for instance, and they would be interested in that. But to cover some use cases which we don't have guides for. And maybe some guides are just. First of all, we need to be created second, just insufficient quality and maybe we should stop them and ask some dogs folks instead. So we want Clayton somebody high ranking from the very, very high level. I could, I could try finding someone sure. Okay, and we can put PRs against the repo for folks to look at for things we want. Let's see, please get hub usernames for guides. Okay, we got that one. That's I think done basically. But for the guides across that one out. That's all of our to do is any last minute items anything else folks want to talk about before we. Yeah, sorry. My name is Lev. Nice to meet with meeting as a guest. I discussed today. Following his excellent work on adding the okd support for assistant installer. And he proposed to basically discuss it in this forum. Because right now on the downstream on open shift whereas a console open shift.com which actually allows to use the system installer. Actually without any effort on the user side. And my suggestion on you know, question if if it will be possible to actually have the same system for okd because I think it will greatly of simplified for anyone who will want to try the okd. Because he will not need to create his own assistant installer infrastructure basically to run it himself but he will be able for example to go and not to console that okd.io. And have a this familiar interface and you know just type in the data into the UI and get his system installed. My understanding is that all of that infrastructure is tied into Red Hat SSO. That would be tricky. No, not necessarily as in we can have different authentication methods but if first of all the question it brings how do we authenticate. We probably could be GitHub or Google but still there are a lot of questions around this idea. So if we would host our own assistant installer service. We would also have to be responsible for user data. And it's not just domain names we collect agents ascending quite a lot of important information like network data. We could have probably a TOS that people would accept. And then assistant installer would require all hosts to be connected so that the agents could connect to our instance. Meaning disconnected install would be very very complicated. And this is where a question begs why would we want to have this instance if there is already an open shift provided one. And it has the same features and it already gives you the very same OCP not OCD but people also don't care. What they want is a disconnected cluster so that they would have to report to Red Hat or anybody associated around that. It's a very interesting problem to solve really but user data handling and maintenance and authentication are serious problems which we just don't want to jump in on to those. We could find infra, we could find hosting, we could host to the Fedora and things but these are the questions we need to have answered before we start approaching. So far you can house assistant installer on anything which can run Podman. You would need maybe two or three gigabytes to store a discovery ISO and some database. So it's not, it requires you to have some info but it's not a crazy requirement. You can also host it on some other cluster and that's one of the ways we would be approaching is have a bootstrap assistant installer type of cluster which very simplified probably Microsoft based or something like that. And that one service is used to spin up actual OCD clusters. So we are aiming towards slimming down requirements instead of having a centralized OCD specific. But if anybody wants to solve this problem sort of please start discussing them. We are very open to it. It's just we're not yet ready to start hosting our own OCD provided service. So would this service work in an anonymous way? If we just want to use it as an installer where I fill in a form and then ships them back the ISO or whatever I need, and then forgets everything I ever told you, would that model work because I'm guessing within the OCP, you then link it into your central management console. So you do want to capture all that information, but for an OCD for an open source user as a mechanism of just providing an easy install where nothing is then stalled or maintained. It's a fire and forget function where you just get effective the install and then none of the data is actually stored anywhere. It's just forgotten once that transactions finished with that model work in this case, or is there more complexity where you need to actually keep that data around. And I want to say actually hold on one second, you want to say that Mohammed said the exact same thing in the chat. Mohammed, did you have anything you wanted to add to that? So Mohammed said, what if it was a simple installer UI for local installation, no SSO or just a web UI engine for kind of GUI installation. Mohammed, did you have anything else you wanted to add? What you typed? It's just like a web application. You can actually think of it as a simple Docker image for installing an open shift and connecting to the vSphere engine or API for just scheduling things up and guided running. That's basically the state of, that's exactly, basically the state of a system installer now. If you deploy it locally it has no authentication or nothing, but if somebody creates a cluster meanwhile you will still be able to see all the details. Before the hosts, between the moment that the host is, the cluster is created, the hosts are being discovered, registered, everybody can see each other, hosts can see all the information like network details, disk details, things like that. Because of the nature of bootstrap in place installer, assistant installer has to be running during the installation, during the bootstrap phase at least. So you are, for at least an hour, you are quite exposed publicly. It can be solved by authentication and assistant installer has some authentication, but nevertheless storing this data, passing it around and having a connected installation are very, very, let's say, they are as far as possible from what the PD wants to actually, we want to give people their own disconnected environment, they want, we want to give them options not to report to and have this. And if we would host the centralized service, that would be the accept-office interface. So I think we should start, we should keep this idea in the backlog. And the time to fix it on both ends, first try to resolve the data storage issue, which is probably the largest one. And meanwhile, we would be working on slimming down this installer so that almost anybody could run it on that work. So that would fix quite a lot of issues from our page. I mean, I could see like slapping an interface on my vSphere UPIs work that I did that automates vSphere UPI. And I'd imagine other folks have similar things. So we could do something local. Lev, do you want to, we're running low on time. Lev, did you want to open a discussion item in our repo? And then that way folks can chime in on this and we can have this as an ongoing discussion and see what we can come up with. I'm not sure how I do this on your environment. I'll give you the link right now and then just go ahead and post a discussion item explaining what your thoughts are and what you'd like to see. And here I'll put it in the chat right now. That's the discussion section for the project. So just go ahead there, open up a discussion item, and then folks will chime in with their ideas and we'll see if we can make something out of this. You know, it's longer term. This is a mid to long term request, I think, as opposed to short term, but at least we can start some discussion on it. Okay, sounds good. Thanks. Awesome. Thank you for attending the meeting and thank you for participating. Anything else? Great. Well, thanks so much, folks. Have yourselves a great rest of your week and. Dots working group meeting, same bad time, same bad channel next week, and then we'll meet back here two weeks for the main group meeting. Bye bye. Bye. Bye.