 And let's get started. So welcome to the OkD documentation subgroup meeting for January 25th of the year 2022. Please take a look at the agenda real quick and let me know if there's anything you want to change or modify. I'll put the link in the chat as well so that folks can see it. And don't forget to put your name in the attendance and it looks like we have a couple of folks that haven't been to meetings before. If you want to introduce yourselves feel free to do so no pressure but if you want to introduce yourself either in the chat or live in audio and video go right ahead. Yeah, sure. Hi, this is Aisha and I work with the CFE team and with this flat team as a software engineer and really works with the VMware vSphere and CI related stuff. Christian introduced me for the OkD group and because I'm also going to participate with him as a co-speaker in a DEF CONS 2022 for the OkD presentation. Because I was always being really interested for OkD and I really like that's the community thing and I really like it. And I'm also really interested in OkD. That's why I'm joining this meeting and I wanted to say hi to everyone. Christian is not in the meeting, but yeah, I'm hopeful that I will be joining the meetings in coming weeks every week as much as I can and contribute as much as I can. Excellent. Well, welcome to the meeting. Anyone else want to introduce themselves? Hi, I'm Sharon. I'm also in the CFE team like Aisha. I'm new to the team. It's been a couple of months only and actually OkD is on the teams agenda. So I was just curious to know how we can help out. Excellent. Well, thank you for joining us and anyone else want to introduce? I think we have one other person. No? Okay. Well, let's move on then and let's take a look at the agenda and we'll start out with issues in the repo. Brian, are there any issues or pull requests in the documents repo? There was one from Sandro. Yeah, he raised one just off the meeting last week around the community section. So it's issue number 255 in the OkDIO meeting. I'll post the link into the chat, the Blue Sheen's chat. So I think we're probably going to need Diane to look at this one because it really looks as to what is the purpose of the external sort of the community site. And should we consolidate it? And I think the community site was more around the wider commons community that everything was meant to point to. But I'm not sure how many other projects are all that uses that and so I'm not sure we can answer that today. Yeah, so that was originally. So when I first started attending the meetings, there was this community with the charter, which were reworking the charter. You know, the new chairs and stuff like that were modified to that recently. And then there was also like, I think that's where the projects tab is, isn't it? Where was, there used to be a tab that had like the meeting stuff. Yeah, that's it. So under projects, there's like a, oh no, that's not it either. So there used to be a panel basically with all of the lists of tasks and whatnot. And I don't know, it's in one of the repositories. It might be, might have been in this one. In terms of the community stuff, do folks see a reason to keep it around? I mean, we're basically moving. Well, I guess the centers around the question, let me phrase it this way. Is there value in separating the web content from the administrative content? The community one is basically administrative stuff like the charter members, owners roadmap. Is there any reason why that should continue to be separated from the web content or the repo that has the web content? I guess, I mean, there's only five documents in it. And it, are we the only project in the community, in which case I don't think it makes sense, separating it. However, if this was meant to look at a wider set of projects, then I think it just makes sense. But if it's purely the OCD community, I think we should pull us into the OCD.io site or put it in the OpenShift repo. I don't think it makes sense having a whole repo for five markdown files. Right. Bruce, what do you think? Yeah, I know that makes sense to me as well. And I mean, if you look at the URL, it's like OCD.io class community. So it would seem that it would only be OCD.io projects. So why not fold it in? I think that there is a general problem that several other people have brought up, which is that our communications is extremely fragmented with a number of places where people could go. Some of them are challenging to get into. You sort of have to be invited and others are relatively easy. But I think that in general, if we can consolidate so that there's like one place as much as possible, that would be fine. Now, for community outreach, which is one of Diane's big concerns, that's a different story. And I know nothing about that. So I don't offer an opinion. Yeah, I think that this was created because the sense was that OCD was the community distribution of Kubernetes and Open. And that was the, you know, the tagline of it. And so I think that's why this was created, but I've never seen any other projects. And obviously there's no documentation in here from anything else. The last commit was the changing the charter or changing. Yeah, it was like changing the chairs and the format of the affiliations, which was something that I did and Christian approved. All right, well, straw poll vote seems to indicate that we'll do any of our other guests have any thoughts on this. Wanted to just be the regulars anyone else have any thoughts about, you know, repos and should administrative stuff like that's in this repo should be separate. Can it be folded into a single repo where we also have our website stuff and other files. Okay, doesn't seem like anyone has anything to add. So I think we should fold it in to the new. Let's do it when we make the change to the OCD project. GitHub. Does that make sense to do it all like it once. I think it makes sense to do it. And again, just for the new members joining. We are looking to create our own GitHub organization and put all our content within that organization, rather than within the open shift. GitHub organization, or I forget what the custom the CS customer support, which is where the website is. So at some point in the near future, we're going to pull everything into a new new GitHub organization for OCD. Thanks for that contact. Related to that change. I was just thinking about how, like, the best sort of GitHub name was already taken. And we tried to get it back and couldn't, which is not untypical, I think, with my experience as well. So now we have sort of like OCD projects or something like that. Yeah, project, that's project, which is not something that would occur to people to look for. So maybe we should task Diane to look into search engine optimization to move that name up in the list. So if somebody searches for a, you know, like OCD or something like that, that that one appears. And that will give people a way of finding it in sort of a natural way. Now we do have OCD and Git lab, right? I think that we did end up getting that. But. I thought that we did. Yeah. Oh, no, that's that one we couldn't get into. That's the Kenzo Acuda owns that one. What was the. Which ones? Is it that both of them were owned by somebody? Let's kind of remember here. Yeah, it's like both of them are like, they were created by people and then like never used. Okay, so yeah, we can't get Git on or can't get OCD on either of them, which is too bad. So, all right, let's talk to Diane. Well, I'll add that as an item here. So I'll add that. Talk to Diane about SEO. By the way, she will not be in the next few meetings actually she is taking a much needed break. So let's move on to the next item. Are there any pull requests that we should be aware of Brian anything that came in in terms of pull requests? Nope, nothing since the last meeting. Okay, great. New business, the slack down channel dev slack channel. You know, going back to folks maybe that didn't pick this up in the main meeting. There's questions about the value of having the dev slack channel. It's it's almost exclusively be used by people posting user questions, sometimes cross posting with the user channel as well. Does this group see any reason to keep the dev channel around? Well, I actually like the way it's currently formulated no. But I sort of had this idea of the two channels somehow being, you know, one more for admin issues and the other for actual user issues. Like people running applications on OKD would be the users and people administering OKD would be, you know, admin. And so I was originally like long time ago looking at the dev channel as being more for people trying to get OKD itself to work versus running loads on OKD. And maybe you have those two distinct communities. I don't know. But as far as people developing OKD, I would say they're not so many that they need a slack channel. You know, they can just sort of yell across the hall or something like that or well not quite that because they're some of them are different countries, but figuratively speaking. The one thing that I noticed is there's actually very few questions about running workloads. Very, very few. So I don't know that a separate one for folks actually running apps would be necessary. And I actually question the use of slack. And it really goes back to the, I mean, we have people cross posting because one, they're not getting answers quickly enough because it doesn't seem to be there's a huge community logging into everywhere to actually answer the questions. And also, I mean, if you're a new user, they're called OpenShift Dev and OpenShift users. So I think there might be some hesitation is are they actually for OKD or do I have to be an OpenShift paying user? I think there is some confusion around that. Certainly when I first joined the community, I saw that it's like, well, do I have to be a paying user to use this channel? And Red Hat don't use this as an official OpenShift channel. So it is very much a community channel. My tech is trying to push everyone onto the github discussions. Let's have one place to go for everything. I think I'd be inclined to as well because then you don't get repeat questions or you can point people to solutions and whatnot. As opposed to it's very hard to keep linking back to previous conversations and slack and solutions. So yeah, I'd be inclined to shut them both down. But in conversation last week, it was said that they want to maintain the presence on the Kubernetes. Yeah, I understand that. But even so, having the OpenShift name there, it doesn't sort of suggest that it's also for OKD. Yeah, unless you start reading the posts. So we could rename the channel or at least propose, rename the channel to OKD and see if that got pushed back. Right. Or OpenShift slash OKD or OpenShift dash OKD or something like that. Would it make sense? Or OpenShift, I don't know. Let's find out. Yeah, go bigger, go home. We'll see what the options are for that. OK, so this group doesn't have a problem with shutting down the dev channel. Because in the main meeting, that's what we talked about. So maybe that's the path forward then. Just say yes. OK, so the next thing is something came up last week that was kind of a surprise. It happened pretty quickly. Sandra organized a Stakeholders, OKD Stakeholders meeting on like Monday afternoon and it happened on Thursday. And it was Christian Glombeck, Vadim, Diane, myself, actually I had to watch it later because I was double booked. And a handful of other folks, Charo was there. The gist of it is that Sandra wanted to know for the virtualization efforts, what is the path forward? Sandra's here. Sandra, you want to talk about the Stakeholders meeting that you organized? Yeah, OK. Just caught me by surprise. I just joined it. I was actually in the RUCA-IO community meeting right now because of the operator's support there. So yes, I was trying to put together kind of the situation of the community and understanding what the stakeholders and what's the plan for the upcoming year or so. And I understand that it's a huge goal to try to understand what will happen in a year from now in the OpenShift area because it changes every six weeks. So it's really hard to... But yeah, with regards to the involvement for the OKD virtualization part, I understood from the discussion that we had that there is a good opportunity there to have good support from the OKD community on that. And so I believe that it will be a nice contribution there. One of the things that just now in the RUCA-IO community meeting they raised is that they fear about having confusion between the OKD version and the OpenShift version of the operator. And out of the stakeholders meeting, it sorted out that there is a plan for having a dedicated OKD operator app. And this will solve this issue. So I'm pretty sure that this will help getting also the RUCA-IO operator into OKD. Right. And one of the things that Diane suggested at that meeting, and I'm going to move forward with that, is that we assemble a subgroup for operator stuff because this has been sort of ongoing. We want to address it, Bruce. I know you're very passionate about it. But it seems like a good idea. Maybe it's an async subgroup. It doesn't have to meet, but just defining tasks and pushing people to get that community operator catalog. The OKD community catalog created separate catalog for OKD and then get it populated with all of the operators we know and love. Is there any opposition to that idea? Yeah, go ahead, Brian. I was going to say, I mean, one of my, I guess, frustrations with the OKD project is when things happen behind closed doors within Red Hat. And as a community member, you just feel you're helpless in getting anything done. So is this going to be an operator catalog that's built as part of the Red Hat and build process, internal build process? Or is it something that we're looking to own as a community? Did you actually talk about how it's going to be manifested? Is it something that conversation? I can speak to this a little bit more, but and other folks who were at the meeting. Live, but it is that there is the person who currently is the point of contact for catalogs, right? I have no specific answer for that because I don't really understand how the catalog itself works, but from what I understood is a bunch of configuration files in a GitHub repo. So I believe that it can be completely on community side. The issue currently is it's built using prow. All the images are built using prow. And so, for example, if I want to customize it, I go through this sort of chase through a lot of repositories to try and work out how I can replicate the build. So we have like in a traditional open source repo, there's usually an instruction says how to build this. Where I think the Red Hat ones talk about the internal prow, build process, CI process, and there's all sorts of linkages in with that. And you look at a single repository and it just links to other repositories and it just seems to be an endless chain of trying to follow stuff through and missing information. And then if you want to do anything, if you want to suggest an update, we're locked out to those repositories because they are Red Hat repose and the community members have no sort of permission on there. So this is going to be specifically for OKD. Is it going to be done as the product is done, or is there an opportunity to actually open it up a little bit. So we have some control and some say in the operators. I think that that's a question for this subgroup to find out and do the research and meet with Red Hat. We have some names of people. There's the person that we talked about at the last meeting and then there's some people that came out of this meeting on Thursday that we can talk to. Let's get a list of people together who are interested in this topic. And maybe it's the same group. I don't know. Diane was suggesting a subgroup. There might be people who are interested in operator stuff but not interested in documentation. Let's get that group together work asynchronously and press some buttons and see what happens. I think we can do some research looping in Vadim, looping in Christian and looping in the person whose name I forgot already that we talked about at the main meeting last week and seeing exactly what is possible. I think, you know, I agree that a truly, a true OKD catalog would have to have some ability, there have to be some ability for us to make some modification to it. And have some governance over it, the OKD community to have some governance over it. I would say even if we can't modify it, if we can clone the repo and customize it for our own personal needs. I think that would be something where at the minute it's not obvious or trivial how I would do that say for the community catalog that's currently in OKD. I mean, that should all be public open source stuff. But trying to work out even how to rebuild that and get that configured into OKD is not a trivial task for anybody at the minute. Yeah. No, I agree. I guess my main concern would be that going from the current version to an OK version, we then cut the number of operators down by another factor of 10. And so we have an OKD catalog that has like one operator in it. And it is, you know, maybe the LCD operator. But you can, you can, it's an array, right? Isn't the catalog list, isn't it a list? It's a container. Yeah, it's sort of tricky though, because if like I was, I discovered, oh I don't know, a short while ago, that if you have an operator that's in the catalog that's, you know, that's managed, then you cannot have your own version of the same operator. So like there's a wild fly operator in the, oh sorry. Well, that one's actually not an operator, so maybe it doesn't apply to operators. There's a wild fly builder image and that gets tracked whenever they update the version. And it's generally a couple of versions behind, OK, fair enough. So before it was there at all, I could install my own, but once it's there, then it overrides what I install. And so there are some interactions with things, you know, like the sort of official versions of stuff then constrain your custom versions that you can put in normally. But now I've got like RookSeph installed and I'm using that for, you know, basically to allow people to create their own storage without my having to prove everything. And, you know, the RookSeph operator would be nice, you know, like I wouldn't mind going to that. I would, as long as it didn't blow away my existing setup and everything that's stored in there, that would be sort of unfortunate. But, you know, so I guess in principle, good idea, see what the details are. You know, like if the Red Hat people are willing to make that work, you know, then I'm happy to jump on and support that as best I can. Can I just ask another question? Is this meant to replace the Red Hat operators catalog that's in OCP? Or are we talking about the community operators that's currently in OKD? It's supposed to replace the Red Hat one, not the community one. Okay, so it's to avoid collision between operators that are in the Red Hat catalog with those that are in the community catalog. So if you want to push the same operator for both OKD and the OpenShift and you don't want to confuse the customers, you will have a way for publishing the same operator also for community. Okay, perfect. That's what I think that's the best approach. So we are looking at the Red Hat operators that are in the sort of the Red Hat catalog on OCP and releasing them. Yeah, great. So things like the tech on the pipeline, the serverless. So basically, because I've sort of resisted for the past quite a while using my developer pull secret. But from what I understand you're saying, Sandro, is that with this new system as you get the same operators with no pull secret as I would get using my Red Hat pull secret. I can't guarantee that you will have the same set of operators because it will depend on the developers of the operator itself. So the idea is to open the possibility for this to happen. And I would like to encourage every operator maintainer to push to the OKD catalog as well. Right. And then I guess a related question would be, well, okay, so does the community have any ability to do it if the Red Hat developers ignore it for a particular operator? Being an OKD community catalog, I believe that it's possible that community can push there. But I have no clue that it doesn't. Yeah, these are all the details we need to work out. So let's get the group of people who are interested in this together and put these questions into a document and then approach the respective people with those questions. I think that's the way forward for this. All right, so anything else before we move on from this topic? All right, so let's look at the task list. Create a list of links to add to the PR against product documentation. You add an extra book to provide links to the community documentation. We haven't done that yet. That's to provide to Michael. We should get started on that if someone wants to take the initiative on that one, put your name next to it on that first task there. Send email to Red Group, look at the code of conduct. Diane wants us to get it in by the next main meeting. So I'll send a reminder email like it out one more time, but we've been asked about, you know, where is the code of conduct? You know, because it says actually even says on the website like in progress or something like that or to do. So let's commit to all looking at that and the main group will have a vote and and sign off on it at the main meeting the next main meeting next week. Create template from general presentation. Sandra, did you get everything you need in terms of template presentation template? Yeah, I put together a kind of template shared with a few people for review. If it's okay for you, you can just add it to wherever you can store that presentation template. And so we'll change this to look over what Sandra created and we will do that and we'll send the link out to the group via email. So do we know where we want to store that? Are we going to put it in a central place or is it going to be looked at by somebody and then people contact them when they want it? I think we can put it in a, I think we can put it in a central place. I don't see why not. I'll just add it to the docs repo. Just check it into the docs repo. Yeah, it makes sense. Find out who's behind okd linkedin. Who was going to do that? That was Diane, I believe. Yeah, and I don't know that anything has come of that. I didn't get a chance to talk about vanity links yet. I wanted to create the playlist at the same time to see if we can have a vanity link for that playlist and for the okd group and see if not, maybe we create, I don't know, we'll see. Call up for YouTube content. We haven't done that yet. Does anyone want to write up a call out for YouTube content? I'm going to take a stab at a paragraph or two of an email to send out to the community asking for videos of installing okd, using okd. I'm always surprised that some of the videos I come across suggested to me that someone posted one couple weeks ago that was installing okd, I think, on Beatsphere or something. It was just someone random, like not affiliated with the working group randomly. It's like there are people out there making videos, that's cool, but we should see if we can get them at least promoted through our social media and stuff like that. Anyone want to take a stab at writing a paragraph or two to do that? Anyone? Alright, we'll leave that as a standing item then. I've got too much on my plate to take on writing. Review code for next meeting, we've got that. I did talk to Vadim about going over repo materials. And that meeting will also have a conversation about closing down the dev Slack channel. Brian, I'll get with you because Vadim had some suggested times that work well. So let's the three of us get together. Okay, sounds good. And then we got to talk to Diane about SEO. I'll do that when she gets back. Anything else? Yeah, I just think we need to capture a task list that we need to work out what's going on with the survey and also the Twitter credentials. Right. We talked about it on the main meeting, but yeah. Sorry, I have updates on that. So, Diane now has the credentials and we don't have an update on the survey yet. Turns out Drity was out for a couple of weeks on PTO and just got back, I think, like in the past couple of days. So let's check in with that. Asynchronously, I'll reach out to Drity directly and find out what the status is on the survey. And then let's commit to getting it out or signing off on it. If Drity can't do the extra work, let's just do it as it is, because I think it was pretty well close to being done. Because I think at this point we just need to get something out to help define sort of steps forward. Sounds good. Anything else? I've got something sort of, I guess, new and wildish in a way, but it does relate to documentation. Okay, so you might have seen many years ago. There are a couple of books that Red Hat was, you know, flogging for free. One of them was OpenShift for Developers covers OpenShift 3 and the other was DevOps for OpenShift 3 or something like that. And neither of them was ever updated for OpenShift 4. And possibly because the authors are no longer around, like Grant Shipley was one of the authors and he's long gone. But I wonder if it's worth updating those, like they were introductory books, and it might be worth updating to OKD4. But, you know, sort of, I guess, where is the source, you know, who has the intellectual property rights, et cetera, et cetera. I mean, there's a lot of issues, but, you know, I don't think, yeah, go ahead, Bret. Sorry, Bruce. I actually think that's incredibly useful because that's my main use case that I'm trying to achieve. But I think there is a dependency on getting the operators sorted because at the minute we don't have an ability to easily install any of the DevOps tools that are in OCP in OKD at the minute until we get those Red Hat operators available to OKD. But I actually think that's a very, very valuable thing because I think one of the challenges is when we get OKD installed, it's like, well, what next, where do I go from here? And at the minute, until we get things like the pipelines, the tecton, the GitOps, as an integral part of an OKD install, I think we're missing a huge part of the strategic getting started as a developer, learning how to do pipelines with tectons rather than the old build subsystem. Right. And I agree with that. And that would make the DevOps one difficult at the moment. But the developer one, OpenShift for Developers, a guide for impatient beginners, that one would be very easy to update. Basically, like I'm running my students to analogous things, so I wouldn't have a big difficulty updating that. I mean, it was only like an 81 page document with a repo behind it so that you could run the code. But that seems feasible. And it just sort of surprises me that there is this, I guess, big push from Red Hat back in OpenShift 3 and some of the things never carry forward. And it was, I think, somehow they got involved with O'Reilly. O'Reilly published it. I don't know if they made any money since Red Hat was giving away for free, but at least had the O'Reilly logo on it. All right. Well, let's look into that. So who wants to take that as a task? Yeah, I'm happy to get involved with that. The question is where to... Yeah, you can ask Diane. We'll find out. Bruce, I'm going to add you. Diane, I could track down Grant. Let's ask Diane and I'll see if I can send an email to Grant if I can find him again. Sure. He's out there. He's out there. Mr. Shipley's out there. I see his name fly by every once in a while. Right. Okay. Is there anything else that we have here? All right. Well, let's... Wait, wait, wait. One last comment. Okay. It's copyright 2016 Red Hat. Okay. The Red Hat owns the intellectual property. Okay. Well, we'll see. Maybe we can, you know, get them to update it or do something. Yeah. By the way, that book, what is it? The hybrid cloud apps with OpenShift and Kubernetes is pretty good. That came out this summer. I was actually really impressed. This last summer was actually pretty impressed with it. Yeah. Well, it's got three or four authors on it. Three authors on it. All right. Anything else? Sounds like we're good. I'm going to stop recording and end the meeting and I'll see you all at the next main meeting that are going to join us. Thank you to the new folks that joined us. And the main meeting next week would be the best one to find out about involvement in helping out the group in general. And thanks, Sandro, for popping in and updating us on what happened Thursday. And I'll put more info on that and what came out of that meeting into the meeting notes. And I think we're good to go. See you, folks. Thanks, Jamie. Bye. Bye-bye.