 Welcome to the working group documentation subgroup meeting for June 28th of the year 2022 and the agenda has been shared in the chat and now we can look at the agenda and see if there's anything folks want to change your ad real quick. I'll give you 30 seconds to do that scan it over and see if there's. Folks good, then let's get started with technical documentation. Just for my part, I did reach out to Jack. Sent an email and waiting to hear back on CERN. See if they'll, if Jack will write like a little write up force, either blog post or something we can put. Somewhere and I also in chat reached out to Glenn Marcy, who's an OK to user who's doing single node. And so that I think could yield some fruit. He said he was interested and I just said, yeah, it just needs to be a blog post or something. Just anything because we didn't have anything for us. I know up right now. So that's where I'm at. Brian, what do you got? And so I'm working through a number of threads. I actually had quite a good discussion with Christian and Dublin about. How to improve the documentation. I mean, one of the biggest challenges we've got is the prow. And the work that it does sort of under the covers when it does build. And for me, one of the biggest challenges is. And the image replacing, as I said, I looked at every single repo that makes up OKD. And there are about 50 different images that are in the Red Hat CI registry. And obviously there's about four different versions of Golang and there's all sorts of different versions. And one thing I'd be interested in is can we get the source, the Docker file or the container file that makes up the runtime, but also more importantly, the build image that is substituted in prow. It must be in a repo somewhere. I don't know whether it's in public domain or whether it's sort of within the Red Hat firewall. But I had a chat with Christian and wanted to try and see if we can do that because if we have the source of truth for the images, then it helps people understand what's going on because at the minute that's a bit of a sort of a close box area. So that's one area I'm looking at. I also had a chat about, and obviously we've got in the to-dos, the operators. And that seems to have stalled within Red Hat. There's other priorities. So I'm just wanting to try and say, can we actually make that a community project? And once you've cracked the build, then there's no reason why we couldn't actually create an OKD community catalog that we can install that actually then puts all the missing operator pieces back into the operator hub catalogs. So that's something else I've been researching and looking at. But I think that'd be a great project for us to take on as a community. Once we get our own Git repo, once we understand what the build and the runtime containers need to look like, there's no reason why we can't go and create an OKD community catalog building from. And that means I think that unlocks then OKD as a useful tool in a lot of other scenarios. Because at the minute, you can't follow the same steps for OCP to set OKD up because there's so much missing from that catalog. Everyone, everything says, I'll go and put the storage operator on, go put the GitOps or the pipelines operator on. And they're just not there for us. So I think having that catalog would bring us much closer to parity. So anybody who sees OCP instructions should be able to follow them on OKD to try and get that. So I've also been looking at what does that involve and how complex would it be? So again, I think a good idea would be if we can create a workshop day. Let's break the back of it in a workshop day for those that are interested. Maybe get some of the Red Haters in as well. Put a skeleton catalogue there and just see how many operators we can actually populate. We could also reach out to the operator framework community and ask them to participate in that hackathon day. Because they're trying to do more outreach as well. They're now the CNCF incubated project, but most of them are Red Haters. Austin McDonald is the community lead for that sort of the Christian Lombeck of their side. He might be someone if you really want to do this. And I think it's time. We've been waiting very long time for Red Hat engineers to free up some resources and it just doesn't feel like it's moving. So yeah, it's not a bad sub project to take on. So we had also talked about doing the hackathon on the CentOS stream project as well. So, you know, we can do a series of them. I'm happy to host them. Yeah, I mean, I think it would be quite a good idea because I mean, it'll also help us build up the community. Because I think some people are a bit wary on taking on a role, a responsibility by themselves. But we'll be quite happy to join a community effort. Yep. So I think having a quarterly hack day or something like that would be a good way just to move the community forward or something. Just something to I think that's Jamie, what do you think? I mean, you're nodding, but that's yeah, I think so. I think that that's a great idea. I think let's schedule that we have 2 ideas here in terms of hackathons. And sort of figuring out in terms of scheduling what's going to work best so that we can get. I got to jump to answer the door. I'll be right back. So, Brian, have you figured out an operator hub? What flags allow OKD to pull something in? Well, it's it's actually not what it pulls in. It's it's during the build of the catalog. Because OKD only has a single catalog installed, which is the community catalog. At the minute, we actually don't they're disabled. So we need to actually go and build a new and install a new catalog, which I suggest we call the OKD community catalog, which would then contain what's in the Red Hat catalog. But I also know that when Red Hat builds the community catalog. It's built for OCP. It's not built for OKD. And some of the links go back to Red Hat marketplace and the links go into the Red Hat catalog. And I think that's that I think that's what you're talking about why some things suddenly disappear from that catalog. So I haven't yet found the source of that. I don't know how they build that where the source of that catalog is. OK, but it seems to it seems to it's not related to an update. You know, if you keep your system stable, the catalog will change from time to time. So it looks like it's periodically updated. Yeah, but don't forget the catalog updates at a different time to OKD. There's an operator that updates the catalog source from a from a wherever. And I think the default is every day. So go to the internet every day and see there's new operators or updated operators available. I think that's how it works. So I think it's at the catalog. I think the catalog changes rather than OKD filtering it and saying, I'm not going to let you install these ones. I think we get to see everything that's in the catalog. But what's in the catalog changes. Yeah, because sometimes even if it's an operator that you recognize, it's a very old version of it. Yeah, because I mean, basically a catalog is just a container with a YAML filing or JSON filing, which is actually the content not then links out to the operator images, which is what then gets installed. And so I don't think there's anything magical about why the operator hub would hide a catalog that's an operator that's in the catalog. But again, I'm learning this and trying to pick up all the sort of subtleties. I know the basics, but I'm trying to work out. But I've yet to find out which repo builds the community catalog. And fully understand that. So I think it's probably something we want to take to the main meeting. And just get people's feeling. But I got the feeling from Christian that the operators are sort of being put on hold by the scheduling people as a low priority. So they're not likely to be delivered anytime soon. So if we want them, we're going to have to be proactive about it. Okay, so it sounds like what we're saying is then let's schedule. Let's pick a date. We can do that async. We'll pick a date. Well, one, well, what we'll probably have to do is. First of all, decide a guest list, right? Who do we want to invite from the respective. Teams. Then do a poll to find out the date that will work best to get those people in the room. Because we want to make sure that we don't have an event where a lot of members of the public show up, but we don't actually have the people who are knowledgeable. At that event. Well, what I'm so that's a good next. Yeah, go ahead, Brian. So what I'm hoping is, I'm hoping that I can get the basics, basic mechanic mechanisms working and have an OCD community operator running on my cluster with a couple of operators in there. So I've actually tested out the, on the beginning of the workshop, we can do a quick tutorial explaining how all and works and and demonstrate it with a couple of examples to actually kick off. Because I'm not sure if we say it's a three hour workshop, I'm not sure how much will get done. But I'm hoping that will be an event where someone will say, oh, I'm going to go and try do the dev work workspace or the, I want to go and try and do the. So we'll get people that we kick them off with the activity, and then we're going to see an onwards momentum, and maybe create a slash on or some way of actually continuing the work and the discussion after the event. Because I say with a three hour, if you've never done any operator stuff within three hours, you're not really going to get much done. I'm hoping these are going to be sort of seeding activities where we sort of educate spend the first hour educating people, give them a few examples in a repo that we can walk through and explain, and then maybe we can do a partial one on the day. Or maybe get two or three people to host a one on a on a specific operator and then continue. So I'm almost think we've got a seed, as you say, seed event with two or three people that can that have actually done it worked out how it all works. And then help anybody also turns up. If we can get the red have people that are doing this on OCP to be part of the hack, even better, because that means they may be able to take their operator and do it on the day in three hours. And we get stuff for free, but if it's just a public event. I think we have to make sure that there's one or two of us that have actually gone through the pain of working out how LM works, how you create a catalog, how you create the operator bundles to populate the catalog and then how you can actually test it all works out. Sounds like we have a plan moving forward. So let's put this in the to do. And Diane, did you catch some of that? No, I did not. I apologize. That's okay. That's all right. The just is Brian's going to do everything. And get this all set up. All right, so that does sound like a good plan though. Yep, we will get this together. The hackathon is the operator hackathon is still a viable thing. Yeah, so so basically what I said is that I think we need to see the hackathon with two or three knowledgeable people. So I'm actually going through over the next week or two I want to create a catalog, install it on my thing and just work out how to get an operator in there. So, I don't think it's a we have a three hour event. If someone's not familiar with operators and operator hub and OLM. I don't think they're going to be very productive in three hours. So I'm hoping that we can use the event almost like as an education session to get them started to seed some work going on. And then we need to maybe look at a social media channel where we can actually try and encourage the group to keep working after the event and use it as like a seeding event to get some work done. Yeah, the operator framework people just came to me Austin, I talked to him every Friday. They were trying, they were thinking about doing an operator con at Kubecon North America in Detroit. Yeah, but they are looking to do more, much more outreach so we may be able to get someone to do a short talk on OLM. That's why I was thinking throwing Austin asking maybe Austin to come to the next docs meeting. And once you've done your exploration, hook you up with him and we can figure out how to make it an operator framework slash OKD joint hackathon thing. Yeah. Yeah. Bring the two communities together and work on something. Yeah. Yeah. And I know you do project key. And again, I know that they are in the community hub, but the dependencies aren't. I don't know if there's anyone there that particularly knows like new bar. Because I think, I think that needs object store as a dependency to get that working. Okay. So again, if there's anybody that knows new bar, and I don't, I think you can do new bar without Rook and Seth. Yeah, that's new. And OBA. Yeah. Yeah, but that's the object store piece. That gives you like S3 object storage on a cluster. Yeah. So I'm just thinking if we can, if we can actually target because I mean, I think the people we want we want. I'm being selfish. I want to develop an environment. I want get T. I want object store. I want get ups. I want pipelines and I want to registry, which is key quite. Yeah. So figure out by the next doc some team meeting or whatever you want and which ones you can be. You can curate which ones we work on. If you're going to move this forward, move the needle forward, you curate the ones that we hack on and I will try and find the owners of those guys for you to work with and maybe deal. If we do something a little bit longer, like we introduce it with, yeah, anyways, do your research. Yeah. No, we can move on. But yes, thank you. And I apologize for having to step away there. No worries. Okay, so I think that's that's really it. Okay, great. Let's move on to our next topic, which is repository move in timeline. And Brian, do you have any updates on that? I think it's actually the listening image. Do I thought there was something somewhere that we, it's really how do we go there is the MX record chains. It's really how do we line up the. The DNS folks within red hat. Okay, to do the move. And I'm just also thinking, I'm not an owner. I don't think I can do. So I might need somebody within the open shift organization that has the authority to do the transfer of the repos and also the open shift CS organization to do the transfer of the other repo. Yeah, so will Gordon is the person and I'm going to send an email and CC. Well, I'm going to him and Brian and Jamie, Brian and it's and I'll do that right now. And give him the link. And if it's not will Gordon, there will be somebody else. He will know who could do it. So keep talking everybody now just send me. Diane that is so that's for actually for C names. That you're thinking of Brian or a records the MX records is a separate issue. The MX records is the email question. Oh, sorry. That was yes. That was. Yeah. So MX records, which maybe if that's the same person, Diane, we could. He would know just find out where to go. Right. Yeah. Get an email server set up. So, so once we actually coordinate that. And then the other thing is, how do we coordinate the community. So when they go to that well known place. We bounce some. I think GitHub automatically will redirect for a period unless somebody reclaims that that name. But I actually think we need to socialize and make sure that people don't get lost. And obviously, all of the. Any documentation I can I can do the. The main doc sites and push all the changes to there. But again, we probably need to be in the Google groups. And then the slack and then maybe the Twitter, we need to arrange that. And probably do a heads up like not just mention it. When we do it, but actually mention it ahead of time. Hey, we are going to be doing. Yeah, because I'm guessing we may be down for half a day. The site will go away for a certain amount of time. As we're doing everything and getting everything sorted out so it may be that. On whatever day it is. Okay, the. I will not be available. And the open shift repo. I mean, again, it'd be worth just checking with Christian. Is that going to break. I don't think that's used for anything in terms of the install releases or anything like that. That's all that's all elsewhere. So I think it's just going to be the, the to get repose and the, okay. That's all it'll really impact. But as soon as we got the red hat is lined up. I think we're ready to go. So I would say Brian put a note. In that. Red saying that Diane is, is reaching out. So will Gordon. Well, Gordon and the other gentleman is Jerry, Jerry fall off and I'm just sending up Jerry's in. The Czech Republic. So. Okay. And I'm sending him the link. So. Ah, all right, moving on to the next item. Cause this one's pretty. Straightforward is depersonizing the homelab documentation. I reached out to Vadim and he is totally on board. And actually. She just responded to me a few minutes ago. And he is on board so we can move both of these. To blog posts and maybe put a tag like. You know, homelab examples or just homelabs or something. And this will give people an opportunity to share their. Home lab setups and not get it confused with a guide, which is an actual step by step. So let's just move those over as time permits. And we're good to go. And then we can promote. These items as homelab examples or something. On the Twitter. In the chat and stuff, I could just say, Hey, look, there's some homelab examples. Okay. And. Then are we going to look to replace them with guides or are we just going to remove the guide section. They are in a guide section. Right, I would say until we get some actual guides written that actually are follow this step by step. Thing, I mean, there is the 1. I mean, but you mentioned I needed to revisit this is my OCT. Guide, you know, doing these here UPI. Someone would have a merge request to actually are an issue on the repo the other day. So someone people are actually using my repo. I don't know if they're following the instructions or not. That would, if I can clean that up a little bit and test it again, then I would say that would be 1 guide so installing UPI on vSphere. I thought we had more. Don't we have more of those written someplace. I mean, because I did 1 and I know that there were and Daniel was going to look at this I thought was look at. Well, nothing really happened. It sort of fizzled out, but there are more than just 3 and Vadim's up there. But again, I think we need to work out what we what we mean by a guide and actually have some form of standardization of what a guide is. Because there are some which are like. I would actually call it a step by step instructions, but there's like general, you have to think about this, then think about that, then think about that. But they're not exactly step by step. So, okay, so I'm writing a. But to do for myself to create a discussion item on guide guidelines. Let's actually do a template. We're going to create a template. We can do that if we want it. If we want to. We can. Yeah, for sure. I just don't know if that might limit people in some sense, but it. Yeah, if it's a very general template, I think it would. Yeah, you might want to separate the stuff that doesn't change that often. From the stuff that's version specific. Because I mean, I think one of the problems with the guides that we have. Is that they're all tagged to some version. And so if you're going to use them, you need to change certain things from 4.6 to 4.10. And one of the things we talked about was having Daniel reach out to people or someone reach out to people regularly to update their stuff once a year. But I think we might have to select or find someone. A lot of it doesn't have to actually have a lot of the parts of it don't have to be updated. Well, oh yeah, but I mean, like the sort of. Open shift part presumes that you already have DNS set up and things like that. And that your nodes have a way of getting a name. And once you have that set up, then that will work for many versions of okay D. And you don't have to change that sort of services part. And the, on the other hand, every version will give me have certain works. But for the most part, it is a generic, you know, you know, run the cluster install command. And then, you know, hustles to get your thing up within a day before all the search expire. And I guess the other thing that could vary is the what version of operating systems you have to start with before the pivot. That will allow the pivot to succeed. Because there have been versions where if you pick the wrong F costs, then it would all break. Even though that shouldn't really matter that much because the version of F costs that you boot your bootstrap note up in is not the one that's going to wind up using. Right. And this is where we want folks to test their guides, like actually run through their own guides, or have someone run through their guides. And if it doesn't, you know, if it doesn't work, then the person needs to update it or when we pull it offline. Or even better, create an Ansible of Terraform that implements the guide that we can automatically test and then. Exactly. Yeah. Yep. My vote would be for using tecton pipelines to do it. So that's why I'll create it. Yeah, I'll create a ticket on guides. And we'll start out with defining our template and basically just like 5 to 10 sections that it needs to have. And then we'll go from there. And then what we'll do is second step after we define the template, we can apply that template or compare against the current guides. See if they adhere to that. And if not, then ask the authors to update. Sound like a plan. All right. Let's see. Next up is at that. So the sent us stream core OS initiative. I don't know how many folks caught the last meeting, but it was it's taken up discussion. The last two main meeting. The topic has. And we actually had a member of the community step away because they're sort of frustrated with. The proposed change. So. Do we want to. Do we want to communicate this question to the larger community. And get their thoughts, or do we want to just leave this to the main group to say yay or nay. We want this thing that that they're offering. So I think where we kind of left it at the last meeting and I'll listen to the recording again is they're going to build it whether we want it or not. Right. So that's so that and what we offered or what I offered to facilitate was once they have it built. To reach out to the our community and other communities to test it and to do a deployment hackathon and see if it sticks. If it's anything that's sticky and it will be members of the working groups. You know, whether they participate in testing it or not will kind of be the litmus test, I think, or whether it gets any traction, whether we do. Whether we the OKD working group take it on as a sub project. I think is still out there in the ether as a conversation, you know, whether people will actually use it or not. But it's coming. Basically, it's getting built. So I personally, because I'm a red hatter and they employ me, I'm going to have to do the work around publicizing it. But the working group does not have to take it up as a piece of resistance or whatever cause, whatever the word is. Well, so here's here's my understanding of the situation though is that so it is given that it's going to be used internally. It's not a given that it's going to be provide that a release of OKD will be provided. That's what they're asking the working group or the community to decide is if there will be an OKD release. Yeah, an actual release with that. So there will be with note that I just going to clarify there will be a release. It will be the MVP release of this thing called OKD for ESCA. So there will be a whether they do it repeatedly and keep pushing it out in a in a landing page of our choice somewhere that we publicize as OKD working group is another is the question of. Is this something people want and I think it's kind of at this point it's early to ask people. Is this something they want when there is no thing there is the thing. Okay, so maybe we missteps by putting as much time in the discussion as we did because now I feel like maybe we need to. Do a little bit of messaging at least to say what you just said and what I think we're sort of agreeing on is that this is going to happen anyway internally. There will be a version a release for the community to try. I think we should at least say that to clarify because anyone watching the videos or having participated in conversations. You may not really know where this stands and be that clear and concise on it. Yeah, Brian. I was a little taken aback by last meeting. And some people I thought would support the idea were vehemently against it. And I think we need to we need to understand what that is. And I don't know whether some of this is coming from the centos withdrawal, whether there's still some acrimony around that. There's no sense that that might be it. But I also part of me thinks it's because the community doesn't feel empowered at the minute. So if Red Hat decides that S cost is the thing that they're interested in, they can just pull that cost and we're going to be left hanging. So I think part of the solution of this is really potentially to do with can we actually get this first cloud initiative going. And if the community can do a build in a release of S cost of S costs or S costs. If we were not be holding to Red Hat, then a lot of what was discussed last week goes away. And I think that might be the issue that I think there's worry that if we go down this route, because I think, strategically, S cost is the most it's the upstream version of rail Coro S the S cost Coro S is going to be the upstream version of rail Coro S. So that's a product commercial point of view that is probably going to be the more valuable exercise for Red Hat to spend their engineering time on. I don't think that's, as you said, they're going to do it they needed to actually test the driver for rail Coro S, and that's why they're doing it. Yeah, so let me let me just add one thing and then Diane so one of the things that I did pick up on in conversations with at least one person was that if F cost gets pulled. There's a sense that the sent us upstream. It doesn't have that same sort of oh I know where to file this bug in fedora to get this addressed I know. You know that this is a fedora issue or this is a fedora Coro S issue, and it's clear. They're where you would file a bug and and some of the people have been very concerned I've been very active and in sort of being point people with oh this is a fedora Coro S bug this is a fedora bug etc. Once that along with this if we sort of elucidate how people can file bugs and work within the sent us and sent us course stream Coro S community to get bugs addressed and to have that same channel channels of communication that same process that might alleviate some of the pain. You nailed it. Thank you for for describing it is that I think that that that one of the primary issues for me is is is the sent us stream or as costs as people are calling it sent us stream Coro S. Is it an open project is it something that's going to be that we could have give feedback to engineering and what are those processes and Timothy was Timothy revier who was on the call. Is working through that and is going to just you know figure out what those processes are for us because he's basically the person doing the work on as costs. And and there are mechanisms for doing that but to me what my big my bigger concern about that is that it's not being run like an open source project it is an internal thing that you know we may not like just like Brian we described you trying to hack through trying to figure out these internal bits. And pieces for the operator stuff will have the same issue with the sent us stream one and as an open source community which is what OK D is will be still you know handcuffed to. Not really having a great feedback mechanism for the testing and deployment results even you know if it turns out and and people have over the past. You were three years gotten really comfortable engaging with the Fedora Coro S. community and they have a lovely set of processes and guidelines and release things that are very public and very transparent. So that to me is a bit of a red flag I have to say which is why I'm not putting a lot of I don't not putting a lot of blog posty stuff out there and like promoting the center was stream Coro S. OK D. Yep I just want to get them to release the MVP so that we can test it and then try giving feedback through whatever Timothy sets up for us and if it's sufficient and we feel like we can do it and at the same time keep raising these issues about it not being a true open source. Just throw of Coro S. I'm just going to say it I don't care if they fire me it's like it bugs me that it's not going to have its own landing page and that maybe will there was a little innuendo that maybe we would put up a landing page under OK D. For this thing there was even a suggestion that we call it OK DOS not sent OS stream Coro S which I really will object to then vehemently as much as I like OK D. I don't think there's any yeah there's no reason for it but they so there's this this thing that talk took me off guard last week to around the lack of a true open source project around or processes around sent OS stream. And I could be wrong I could have had you know got ears and not been listening to it and Timothy we could have had English as a second language issues to so I'm giving people the benefit of the doubt that with this MVP there will be some processes and we can improve them. And I had a conversation as well with Neil from data right after the call and the interesting thing to me is and he's got he has a long standing relationship with the sent OS community as many OK D working people working group people do as well. But he knows all the history and even in spite of all that what he said to me the use case for data was they probably would deploy this in production because he can't he cannot get his it team to allow him to deploy OK D using Fedora Coro S because they are required by compliance to run some security package that they pay for and it doesn't run on Fedora Coro S and I think there is a use case out there or OK D on S cost for people like that. And I don't call them and I think I had this conversation with you Jamie so I'm recording this I'm just saying I they are not the same kind of people that are currently in the OK D working group right now in the OK D working group. We have people are willing to hack on Fedora Coro S hack on OK D hack through prow logs do all that. I think there's another group of end users let's call them who will just use it you know and so we will get this adoption and there will be some feedback and on both OCP and on well you know whatever so the feedback mechanism is a good thing. But I don't think they're other than workload and use cases and maybe issues with deployments we're going to get them to be as active as you guys in the working group because they're going to be the like the go daddy hosting kind of folks they're going to people just use it. And with there are lots of people who do that with open source projects. We haven't been attracting those people because it's too bloody complicated right now. And we need people we need to retain both of those communities or and gain back I think we lost those end user ish people who just wanted to run it so I think this is an opportunity for the working group to grow. I don't think it's going to grow technical resources in the community. I think it's going to and we have to be aware of that because it's going to be a resource hub. This is people will ask questions and want tech support or this and if there is no feedback mechanism to Timothy that is effective or to the team that's doing the releases that's effective. They're going to come to us and we're going to waste opious amounts of goodwill and time from this team on those efforts. So I'm very cognizant of this is an MVP. We're going to see if people are interested in it and which kinds of people are and what the feedback mechanisms are and that's my feel. And I think everybody's in semi violent agreement with me. Bruce, you had something. Yeah, no the. I guess. The use cases for why this is useful haven't quite been presented. Okay, so the security tool issue is a good use case. So that's compelling. But the way it's been presented so far is just a shiny new toy here. You know, play with it. Isn't it fun. And it did sort of threaten the F cost people, I would say. Because it told them, Hey, you're, you know, you may not have a job in a few months. And so there was a little bit of reaction to that. I don't know that that's, I don't know that that's true because F cost is what one thing and I tried to highlight this in the, in the last main meeting is the F cost folks are trying to orient F cost as being a sort of neutral container operating system. You can run it on its own. You can run it in other cluster technologies, etc. So I don't, it doesn't, I don't, because that's a volunteer effort as well. I think I don't think it threatens their job so much. I think. The security thing, it probably would be Phipps, right. So Phipps, you can't do Phipps on F cost. Sentos, you can do Phipps. So if, if that means that Sentos stream core OS means that OKD can finally do Phipps. That's pretty big because even I haven't been able to use OKD in all the situations I'd like to because of its inability to support Phipps. Yeah, I agree. I mean, but, but my concern though is that the, or one of my concerns about the whole Sentos thing is that it seems to have fallen flat on the upgradable issue. OK, like when I started with Linux, every time there was an update, you had to completely reinstall from scratch with Slackware. And Red Hat introduced, you know, RPM updates. This is like, you know, decades ago. And that was a huge, huge improvement. You didn't have to plug in 70 floppies anymore to upgrade your machine. OK, so I dropped Slackware and switched to Red Hat instantaneously. And since then the, you know, it's sort of changed its labeling several times, but it's always had pretty good update history. And I recently updated, you know, Fedora desktop system from 34 to 36. No problems. Now going from CentOS to stream, that is just seemed to be no longer the case. OK, you could update from CentOS 7 to CentOS 8. And for a while you could update from CentOS 8 to stream. But at the moment it seems that if you're, if you have a CentOS 8 system, you can not update it or convert it to stream. You have to reinstall from scratch. But I thought Timothy said that the SCOS is going to be like REL CoreOS. It's only going to be targeted at OKD as the underlying operating. So it's not something that you should potentially go out and use for generic projects. That's right. That's today, yes. But I mean the, but I guess it's based on the CentOS stream, which is now version nine. Yeah, but I think they say that very much as the upstream version of REL CoreOS. SCOS is the upstream version of REL CoreOS. So it has the same use cases that REL CoreOS has, which is OCP only today. But obviously SCOS will be OKD only. So that's what my understanding. And Christine actually did this on the Dublin. He actually talked about this on the Dublin gathering. And he, the way he put it is, FCOS is where we get all the latest Linux features. It reacts very quickly to new features. So that's the first place you're going to see new kernel features, new network manager features, new C group features, and all the great things. So that's the first place you see them. And OKD on FCOS is the first place you get to play with that stuff. If you want a more stable version, then SCOS will be that more stable. Whereas had time to be hardened and it is going to be the upstream of REL CoreOS. So if you want a more stable platform, OKD on SCOS will give you that more stable where new features have had time to be embedded, be checked out before they get released into that. That's what Christine said on the gathering. I'll grab that video as soon as it's available and share it with everybody. But I want to go back to something that Bruce said, because I just want to have some clarity on it, that one of the issues I think if I heard you right is the upgrade process. So say you install OKD on SCOS and it's using a REL 9 or whatever the latest version is, and you want it in REL 9.2 came out and you wanted to upgrade. There is no tooling to do that. Well, it would be more of a REL 10 one. OK, REL 10, whatever. SCOS 10 comes out. SCOS 10 comes out. There is no tooling like there is for OKD on FCOS to do that upgrade. You just have to reinstall everything. Is that a correct interpretation of what you think is going to happen? Well, OK, I agree with the comments that the OKD usage of it and the machine operator and so on changes things considerably, because you are essentially with a machine config operator, you are installing a new version rather than upgrading an old one. So I guess that my CentOS experience is mainly running it as an operating system, where you have to upgrade the operating system. And I agree that that may not be applicable in SCOS. Yeah, it's not, because if we're talking about a core OS, a core OS has a different version, multiple versions of the operating system, essentially lined up that you can select from to boot into. And essentially, you're not updating the OS. You're booting into a new, right? Yeah. So from an OKD perspective, the upgrades with SCOS shouldn't be painful. Right. And some concern actually is more fundamental, which is the lack of these upgrade facilities on the CentOS side leads me to have a feeling, which of course feelings can be totally incorrect. That CentOS is a step backwards in maturity from everything that we've had so far. And if it's an immature operating system framework, then it would give me concern to base a production system on it. But doesn't it stand to reason that if it's going to become the upstream of our costs, that they're going to address issues pretty quickly? Not necessarily. You think? Okay. Because everybody's busy. And priorities change. And it does take a while to get a community up to speed. So like, I can believe the Fedora community now is relatively mature. I think what I would say is it's a trust issue, right? What we have here is a classic open source trust issue. And that's kind of why having, to me, having the MVP available, trying to do the testing and deployment with it, building some trust that there are feedback mechanisms and processes, finding out whether it is FIPS compliant. You know, if we get that gain with the MVP. And what it means is both sides, the Red Hat engineering team that wants our feedback and wants our participation in this has to come to the table with some decent processes and communication skills if we're going to spend our time and energy doing testing of the MVP first and foremost. And I think Timothy and the team and Stephen are totally okay with that. And we'll do that. And if nobody shows up at this hackathon and nobody tests it, then I don't believe, you know, I think they will have an internal release of OKD and SCOS going on, but they are not going to, like if we don't do a little bit, come the other 20 steps towards, you know, it's like square dancing or something. We, you know, if we don't come a little way in and do some of this on the MVP, they're going to just go, okay, there is an interest in the community. So I think there is some interest in the community. I'll ask the question, Jamie, and maybe you can ask it of Christian as well about the FIPS compliant. I think that's a good solid use case. If this gets us to compliance, that's kind of huge. And so that, yeah, but this is a classic trust. And we have built up a great relationship with the Fedora community around Fedora Core OS, and we trust them to hear us, to do what's, you know, what we need, and they trust us to test their stuff and give them good feedback and collaborate. We need the same thing, but there is no real community there in the CentOS Stream community. There are no bodies other than engineering resources from Red Hat. And this is my concern, and I'll keep saying this until we get two minutes left, is if that's not going to be run as an open source community, there will never be a bunch of people managing the infrastructure and the release process for it like the Fedora Core OS. And I think, and nobody from Fedora Core OS is going to lose their job, trust me on that, because most of them are Red Hatters that are doing this work. They're both doing both, like Timothy. So that's not, I don't think, because I think it's, I just think we're in this flux moment where we don't have the trust and we have the past experience with CentOS that, you know, it wasn't great. It burned a lot of people. It burned a lot of people, you know, and so, you know, we're asking to take this steps towards each other and start this dance again, and everybody's been burned once. So, you know, I think that's it. The other thing, Jamie, that I wanted to say, Brian Cook is the agenda item for next week for the main meeting. I just wanted to mention it here. Brian Cook is in my business unit, and he is running and building tectonic-based build pipelines as a service for Red Hat products and projects. He's got an initiative inside, and I think he's got a few things that he's working on as pilot projects for this, and he's hoping to come next week and talk about it, and he has been talking about the next thing that they might build as a service using these non-prow-based tectonic, more modern, shall we say, pipelines, could be OKD. And that's separate from the Operate First Cloud, because that would be on something else. So, I wanted to have him come next week and describe what he's doing to see if there's interest in us being, you know, the guinea pigs for that, and that would probably be OKD with FCOS, but I don't have clarity on that. So, there's another way to get OKD with FCOS built that we could also participate in. We would have access to the files and the logs, and so it'd be a little bit more public, but still run as a service with these pipelines on, I think, on AWS. I was going to say, I think the importance is that at some point we get to the point where a community member can build OKD and produce a binary equivalent to what Red Hat releases, because at the minute we can't. There's no way that we know what happens in prow to the extent that we can go and repeat that within the community outside Red Hat Firewall. I think to me that's an important thing. We end up with a process. So, if for some reason Red Hat decides that resource constraints, they can't put the same amount of resource into something that we rely on, we're not killed. I think that's the danger. That's what we feel that we are so beholden to Red Hat giving engineers time to work with us and produce things for us that if that stops, we die. And I think that's some of the frustration that also boiled over. Yeah, I think so too. I think you hit that on the head. I want to be mindful of time. The great thoughts from everyone in this meeting. This was a great meeting, great discussion. We've got our to-dos there. Let's go forth with our to-dos. And then we'll bring these other things to the greater meeting that I think probably should be fleshed out in the greater meeting. All right. So thanks folks. Appreciate your participation and continued efforts. And talk to you next time. Take care. Bye.