 So here I am, Christian's having problems and I'm getting in. So his Tether's connection is too slow is what he's saying in chat. So, hi, welcome everybody. I'm not supposed to be here, but I'm here. So, I'm happy to drive this and the recording is on. So that's good. So, Vadim, while I'm getting the page set up, you want to give an update on the 4-6 release if you don't mind if you haven't already? Yeah, sure. So the telemetry says it wasn't a complete flop because we have about 140 clusters upgraded and 17045 clusters still on 4-5. Apparently, the biggest problem is this fear, which has hit all possible issues, like Fedora suddenly changing hostname from default local host to Fedora. And SystemD resolved the problems and there was also a problem with OCMira. So at this point, Fedora has reverted a change of the hostname back to local host. We are waiting for this to hit our repost and we'll be able to test this fear more actively. SystemD resolved is apparently fixed. We're disabling that and disabling it in NSSwitchConf and in Network Manager, so it should be working right now. There's supposed to be another fix for that because there's an SE Linux issue that's preventing one of the processes from working properly. It's supposed to do a symbolic link. So hopefully that'll get fixed in Fedora and FCO. So that'll fix hopefully the patch that we're doing for NSSwitch. That is a bit, that's going to bite us when folks are installing Fedora 33 stable Fedora cross and upgrading to whatever we ship in OCD. It's not hitting us right now because things work perfectly if you start with Fedora 32, but very, very soon it's going to bite us so we're watching this closely. It's hitting me now when I did my testing. Yeah, yeah, so it's pretty bad, but it's not exactly the problem right now. I mean, there are still options. We can either ask folks to use all their Fedora cross or we can try to come up with a workaround on OCD site while the official fix is getting merged. The largest problem by now is that we're incorrectly mirroring images because of the build a bug on our whole build form. We have finally gotten to the very end of this yesterday. And it's going to take, I don't have estimates right now, probably a week to rebuild the whole images so that we could mirror that. It's pretty serious for OCD, but we're still debating how serious that's for our customers. So that's a pretty large mess. I think we have all the problems filed as OCD issue stacks. So I will go ahead and create a tracking issue with the status of all fixes right now for the next release. Another problem I've noticed is OVN controllers are using way too many CPUs, but it appears to happen over a couple of reboots. So we need more information on that. I think it was reported to OCD as well, but we didn't have enough information to track this and pass it to network guys, but these are probably the largest problems I've hit so far. Meanwhile, we are working on official enhancement for OCD so that we wouldn't have to rebase our installer every couple of days. Most of the installer folks are on PTOs right now so we'll chase them this week, because the next Friday is the future freeze for OpenShift. And soon we have Kubernetes 120 rebase landing in 4.7. This would be available in the night lease that we will work right now. And hopefully 4.7 release would go much smoother than this one. I think that's all I've got. So I apologize because I'm jumping in late here today and I'm a little out of sorts. So the 4.6, we have a build of it that people can use. Should we be publicizing it yet? And that was a conversation we were having in Slack the other day. So should we wait until all of these things are resolved before we start, you know, talking about it? I think so. I think so, yeah. We are, it's an official table release. It's just not recommended for vSphere folks. And vSphere folks are approximately 30% of our user base if the telemetry is correct. So that's pretty large chunk. I also would like to have some more time with brush updates of samples operator, where we ship TentOS and UBI things and get some experience from that. That would be, if we would be publishing a blog post, that would be very interesting to mention this that it now has community samples. We can extend them in a bit faster fashion than OCP because we're pretty much independent from this part of OCP. That should be an interesting part in the blog post probably, yeah. Okay. Which is good because I haven't written the blog post so. I kind of was listening to Charo in some of the back room who's not here. I don't think Charo managed to make it today either. This is just a week from hell, I think, for meetings clashing. And he was having difficulty making the CRC for OKD 4.6 to work. I think he got it going, but I'm, and I think he got the images up and running. I don't know if anybody else on this call has tested those and played with them. Yeah, is there anybody who's taking a look at those? We could use some feedback on that to make sure that they're working correctly. There's silence. I love silence. It doesn't happen often on these meetings that there's silence. So yeah, I think it's a little fresh. Yeah, I haven't had a chance to do anything yet. I've been, I've been run ragged for the past four weeks. Since Vadim is, oh, sorry, go ahead. No, go ahead. Go for it. One thing I saw Vadim and other folks can chime in on this is one of the things we're seeing a lot in the slack is people who are confused about the 32 versus 33 F costs. Is there a way that we can, is it notate that or better let people know not to panic or to know that they should grab 32 and that it will be updated to 33. How can we manage that so that it isn't a recurring point of confusion? I think that that hinders adoption. I think we need some more documentation on this. In IPI, the starting image is managed by you and it's going to pull the latest stable F 32. In UPI, people are free to do whatever they want. We just tell them, you stable the request, or you, if you have some special use case, you can use a different starting point, but it's, they are just confused by the release page which shows which door across release you end up with, but it's managed by MCO. You don't have to start with the same one. And now the problem is that some folks are thinking that if they start with the very same release, the upgrade won't go will go faster, but it's not true because we mix in our own. We mix there in install packages, it's just going to take the very same approximate time. Perhaps we should note this on, we should give more attention to FAQ page we have on GitHub. And probably the documentation is the only answer I have right now. I'm volunteering myself to do that as a question because I've seen it come up and I'm happy to answer that and put that into the FAQ then. Yeah, if you make a pull request, make sure it gets merged. If you don't have proof. The other thing is to put a note on the OKD.io site as well. Somewhere on the, somewhere, somewhere loud on probably on the download page. So if you make a pull request there, I'll merge that as well. So that would be, it would be great. I just, I know, and I, so that's the questions. I'm just looking at who's here is Juliana or Mike from ACM here. I think they were going to come. I wanted to make sure I didn't forget to say that there. I don't see either of them or maybe in the chat. Yep. Nope. The folks that came last meeting and go back to the. There are screen here from O.C.M. the open. Buster management initiative, otherwise known as ACM inside of red hat. They're going to, I think on Thursday, they're having their first meeting and I'll post the link to that in the, the Google. Group so that if people wanted to join in that, that would be great. The other couple of things that I have on the agenda items that I just wanted to touch on is. We did a really nice birds of a feather at Kupkan, North America, and we got accepted for another round of that. I'm going to talk about the European time zones for a dev comp CZ in February. So I'd like to rinse and repeat that. So just I'll put a note on the Google group with that as well. So anybody who are other people here besides me planning on going to dev comp CZ is I guess my quick question. I've got a talk for dev comp CZ already approved. So I'm going to definitely be there. I will tap on you and I will try and get Christian to come because I think it's his time zone. So there's one, at least one chair from, from that and we'll, we'll host that pretty much the same way that we did just a quick five minute overview of what OKD is and maybe a demo of. The code ready container or some other new aspect that's coming up by February that we want to chat about and then leave the rest of it open for Q and a and conversations. But it's pretty easy to do the other thing that's come up a few times. Recently, I've been talking with the folks over at GitHub itself and these GitHub actions. That's a new thing that is a new thing and they probably will come soon to one of the working group meetings, but I thought I would flag that today and throw it into the stop sharing again. I love blue jeans for this. The link to that there are some already set up. Oh, this is cool. So take a look at those and I'm going to invite John Bohannon from GitHub and one of the Red Hatters who's been working with them to come to a future thing. So start look, look, take a look at it. And if it's of interest, we'll, we'll give him some time on the agenda. I want you to go ahead and plan for giving them a time on the agenda. I want to hear about this. Okay, so I thought it was interesting. So that was that was good and the the other thing that I have been besides the blog post and and besides the fedora magazine thing. Outreach and and on that side of the fence is doing thinking about doing an OKD summit or OKD con or something like that for contributors and working group members and end users. I guess what everybody needs is one more virtual event, but trying to make my virtual events be more very specific so that people have a purpose as opposed to generic. So I think and a reason to come. And the good folks at CERN. I don't know if Iago is not on the call here. He didn't think he would come in. Yeah, I've already got access to hop in but thanks Berkist. That's a wonderful. Yeah, I have often is good. Yeah, no, it's really good. So I was thinking there since dev comp is in February and summit is doing something in April that maybe. March would be a good time to do it. The folks at CERN and is Joseph Meyer on the call here from Rodian Schwartz. He is. He is here but he is muted. I'm going to unmute everybody because you know what I just love to hear dogs and kids barking in the background. Hello. I came, I came two minutes ago to this meeting. Just in time to be summoned. So what I was thinking of doing is having it sort of a two, a two part thing is 1 is a whole bunch of end users with deployments talking about their use cases and journey and giving us their feedback. Kind of in an interactive way. So, Joseph, you had mentioned that you might be willing to share that story of, you know, using okay D and where you're at with that. It's one of those and the CERN folks also said that they would be happy to do so as well. So, and CERN for Amy who's on here and pretty sure is using it on open stack. So, and they have, they're just migrating from four, five to four, six. So they're going to be 1 of the 1st production. So, non working group members, because I know some of you, Bruce, I see your face and there was a couple of the folks who are using it in production. I am not interested in doing that also. Okay, well, and sorry, I'm not recognizing your John Fort. And which John Fort and which market America. Okay, so market America and Greensboro. I would, you know, I'll take everybody and maybe four or five end users talk about their journeys, what they're doing, give us our feedback and have the working group members listening to that with as much or as little confirmation bias as possible, but just listening to that and then since Josh is on here and Amy is here. One of the things that I'd like to do is work a bit more on our contribution ladder and onboarding people into the working group and figuring out, I know Vadim one of the things that you've been muttering in the background is how do we get more like code actual code donations from the community, as opposed to waiting for Vadim to get off PTO and tell us what's in the latest release. So I would like to spur that side of the conversation in 2021 is to try and figure out how to, because it's very it's difficult because OpenShift, the product will really the main driver engineering resource wise for OKD. But there are other places where we could do better and we, I've been preaching externally about wonderful contribution ladders and how to become a maintainer and all that stuff about other projects and I would like to apply some of that to OKD itself and figure out how that is. So that would give us from now until March to really have conversations about what that would look like. And Vadim I really value your insights into how people can do that and help so that you and Christian and even the Charo building the code ready container images on his home lab and figuring out that part. But that I'm thinking if people are on board for that. And I'm just looking in the chat I'm thinking. That actually be interested in being involved in that because I do want to become a more involved contributor. I was on a couple of weeks ago and just saying how how can I get more involved, especially with code since you know I am a developer and stuff like that so. Yeah, although everybody's probably tired of seeing my email inside of GitHub at this point so probably too prolific. No, definitely needs to be discussed. The problem is if an outside users have some low hanging fruits and OKD that means we're doing our jobs very, very poorly. Since we pays our stuff on no CP. And it's supposed to get properly tested by CI and then trickles down into OKD. You are not supposed to to find issues immediately on installation or right after update that means we on our CI side need more. I don't know more tests, more attention to that. There is however a huge area of contributions to OKD as in how do we extend it. How do we which components community would use more actively than enterprise consumers for instance, something related to let's encrypt. Something like cert bot included in OKD payload itself would be more interesting for the community. And OCP doesn't need that. So these extension points are probably where we should be contributing code there is a bunch of interesting. For example, operational operators, for instance, folks at adversary organization in OpenShift part have developed their own routes monitor. Basically a black box exporter which looks that all of your routes are available and served correctly. That won't ever get into CP code base originally, for instance, probably belongs to OLM. So that discussion which operators or components should live is optional on OLM and which should be part of OKD itself. That's an interesting discussion. We probably want to minimize our surface of what we maintain and put more stuff into OLM. But OKD is a distribution and setting some brainstorming, some subscriptions from OLM, for instance. That's an interesting topic to discuss. There's also the other end of the thing too is that I'm getting inquiries from the product management team. A lot of people who are coming to OpenShift for the first time that are potential users of that come to the open source side of things. So many of you maybe didn't come in through the OpenShift.com world. You came in through the open source side and making that more of a seamless experience for people. So I know I've been talking to the developer.com folks about having OKD be one of the tools that they use when they're doing demos and things like that and making that a smoother thing. And also hearing from people who are in the community and how do we get our feedback more fluidly into the product management epics and things like that I think is something that I'd like to figure out. We do it by sharing our stories and, you know, Market America and Roding Shorts and CERN and, you know, putting yourselves on stages one way because the product managers and the engineers all listen to those talks over and over again, which is great. But I think there needs to be an even more sort of a feature request process of some ilk that we build out so that it gets up and in. There's Mike. All right. Mike Ng joined a minute ago. And I did mention this and this is Mike Ng from the OCM folks, the Open Cluster Management folks. He just put in, dropped into the chat that this Thursday, which I think is the 10th, at 1530 UTC, there is going to be their very, very first Open Cluster Management Community project. So if you're interested, they were the ones that spoke at the last meeting. So that's, so that's what I think 2021 more, more seamless into the CI CD workflow and the testing stuff. I think that's a big goal for us to get that done, as well as the build process for code ready containers to be more automated from my perspective. But I would really like John and Joseph and people who are actually using it out there in the world. What are the features that you're looking for that we don't have and where we need to be working and to push that up the pipeline to more visibility to the product managers is really kind of their key. And how you can, you know, how can we get your contribution? If you're willing, John, where can we put you to work besides, you know, making changes to the documentation and the OCD site and creating recipes? What else can we, we. I'll test VMware. Honestly, because that I mean the last two weeks has been my pain point and I am more than willing. I've actually gone through the process of building my own packages and stuff and making changes and then funding locally to make sure that they work. So I become a lot more familiar with that process. The last thing I don't know, and I'm more than happy to help the team. This will be incredibly helpful. First of all, again, because of the fedora 33 change. We are now unable to fetch the log bundles from CI. We're still discussing if it's the bug we need to fix an OCD, or CI should use modern SSH keys because of the crypto policy change and fedora RSA keys are not being being rejected so internally we're discussing that. The way we work, we don't touch clusters manually, we just ask CI to build it. If it passes, then it's good. If it doesn't pass, there is no way we can override this. And that takes quite a lot of time and really humbles our productivity right now, but that's an important decision we need to make. Meanwhile, there is a bunch of proposed patches we need to test like fresh system, the freshest network manager. It would be great to help fedora CoS folks to start with fedora 34, like a Rohite build they wanted to track. And the sooner we stop this, the less problems we encounter later. At least they won't hit us at the same time just like they did the months ago. When it comes to OpenShift codes, like sending code straight to OpenShift it's a bit tricky because you have to start at 4.7. And if you really want to try it out in 4.6, you would have to file a bug. That bug needs to be triaged by folks and approved that we want this to be back ported. That's a lot of bureaucracy you probably don't want to get involved in this, but if you really want to and you're hitting a specific bug, we'll definitely help with that. That's not an issue. It's just not trivial because we don't have like a, I cannot think of some low hanging proof we need to fix right now. We could bring people through. Although that sounds like something we should have, we should have a list of bugs we would like to teach folks to how to work with Oakley and go through the whole process. I think it's part of the contributor summit con thing. We might even have like a little hackathon where we make even just walk people through fixing a bug. I tell you from my experience like yesterday, you know, I went through and there's a couple of bugs out there that I wanted to test for the fixes. So I took the code from GitHub and then applied the fixes and then built MCO and then applied it to my cluster. So, but that was not a greatly documented process, you know, on how to do that. Some of it, there's one page that was, okay, it's sort of there. So I figured it out. But, you know, those are pieces that, you know, if you want people to help develop or help test patches and stuff that probably need a little bit more guidance on in order to get there because there's a lot there to understand. And then, you know, how do you how do you apply that, you know, your own package that you built your own container, and how do you get that into your own installer and test with that whole process is a little. Interesting to figure out how's that. Yeah, no. Yeah, I wanted to add a comment on the whole bug triage debugging kind of informational side of things too. It might be worthwhile to kind of go through some of the hot topics that are coming up in bugzilla at one of these virtual events to kind of show, I guess, more of the community. What are the issues that are hitting the head of master right now, or the, you know, the tip of our main trunk development so we could help to propagate those issues further out because, you know, Vadim was pointing this out, you know, when when we're working on OCP as a product, you know, a lot of the stuff we're looking at is, you know, coming out for the plus one version, and that's probably a version or two away from what we're seeing in a D so like, if anything we can do to help reduce the information gap between what okay D users are experiencing and what we're pushing at the forefront, I think will help us to overcome, you know, this situation of how do we take more community, because I'd love to see that personally. I think that might be a good answer. No, no, go Jamie. One of the things I think might be helpful is for us to somehow collate a list of folks that are testing and debugging, and what particular platform they're using. So for example, if I knew all of the VCR folks, we could all get together and, and have a little chat about okay did you notice this did you notice this. Right now everything sort of scattered and you don't necessarily, unless you're on a call with someone and you hear them talking about what particular platform they're using, you don't really know like I know now know john is, you know, from this and some conversation online, he's used VCR as well. I think it would be helpful if we somehow attract that so that we could say okay, here's something I'm seeing in VCR it seems specific to these here who are the other VCR folks that can bounce this off. And I'd be happy to arrange like a zoom or a blue jeans for V sphere like a sub working group of people. But I think we, we started doing that with when we did the okay D marathon started like trying to get the content created for that back that was coupon EU in August, and started to identify who who were the people who were willing to like say hey I'll do digital ocean or I'll do v sphere or I'll do this, but then to go the next step and, you know, self identify maybe in the group, which one you're, you're willing to be a tester for and then creating a space for that in in the repo somewhere and posting, you know, maybe a bi monthly, all the v sphere spokes or like when v sphere is a problem like it is right now. Sorry, Joseph, you came in late. So, yeah, we're we're having some issues with the v sphere. But I think that I mean I'm happy to facilitate that to do that and host that but I think we also have to would have to have one of the technical co chairs like Vadim or Charo or Christian to come and be the facilitator for that conversation or at least the listener, maybe not the answer of all questions, but to have one of the open shift engineering team and Mike, you know, you know, somebody to report back, I think is the key here is to keep the notes and to report back. And if we want to kick off with v sphere. I'm happy to do another one on that and maybe timing it with when some of these issues are resolved. Do you think next week at the same time by then we'd have one that we could do a v sphere triage session maybe might be what I would call it at this point. Oh yeah, the v sphere specific problem should be fixed this week. I don't think that long we're literally waiting for system the update and MCO probably. But the OC mirroring problem. Pretty huge. I don't have an estimate for that. And I don't want to break another stable release for the folks who are doing mirroring. The nightlies. In this fear should be fixed very soon, but stable release will probably want to hold it open till we fix the build from problem. Again, I'll file a tracking bug where we will track all the problems and discuss the stuff. I'm just thinking because these these meetings we have our bi weekly. So on the other week, we could do a v sphere one and if we wanted to do a v sphere specific one next week, if. I'm happy to host next, you know, this UTC time next week to do a v to call out to all the v sphere folks, or we can wait until after the holiday. If that if you think that's better buddy, we wait longer or are you okay with doing something maybe next week for v sphere just to. Um, let's give. Let's give it a try next week. Okay. And holidays are working and see how it goes. We might not have to need every single week just to just put out the fire. I'm thinking alternate like next next in between do v sphere, then do a work a regular working group meeting and then the following one pick one of the other platforms. You know, and, you know, do a bare metal one. You know, v sphere. Sorry, like, I, I mean, I'm, I am totally happy to get involved and help like liais as much as I can between what's happening in the machine API team and what's happening here and okay. I think, you know, it's interesting to see it's interesting to me at least to see all the discussion about v sphere because I think we have an internal impression at least that we you know we're not totally happy with where we're at with the v sphere. And I think we see a lot of problems with v sphere. And I would love to be able to see a situation under which we're taking community patches and incorporating them into the installer into the machine API, whatever it happens to be. So yeah, like if there's a v sphere triage meeting and we come up with a list of issues or whatnot like, I'm certainly willing to help like try and match those against either what we're looking at internally, or how we could coordinate a patch with somebody and landing in one of the OCP repose because I think it's completely doable we've taken community patches before. And I'd love to see that kind of like accelerate in the future. Yeah. So, like, if you and maybe Vadim can come to next week, I will post something on the Google, the Google group and just use this exact same time slot, because it works for my schedule now that I've adjusted for time zones. And then just use that and then maybe just call it the v sphere, treat update or triage conversation. And I'll call it triage because that's what came out of my mouth and now you're all thinking triage. And then I'll let Mike and Vadim mostly drive it. And we'll have a notes document like we have for the meeting notes and we can share that with the engineers and the product managers and I can let you guys. Maybe Mike, if you'll own that. Facilitating the conversation with the engineering teams. Because I, yeah, the other, the other part of it is, is the product managers are looking for this feedback. And, and the engineering teams are looking for this feedback. So if we can give it to them, that'll help and give them ammunition. We're putting more resources on. Yeah, I'm totally happy to help. I mean, you know, I don't say unfortunately, but like my, my sphere of influence is kind of limited in this respect. I mean, I'm, I'm working with the cloud team and machine API. So like I'm looking a lot of the cloud, the cloud providers and our team is owning that code for OCP. But we don't necessarily dive deep into the installer stuff. So if we start to get into installer issues, I might have to get other people involved. But at least if we're talking about cloud providers and the machine API layer, you know, yeah, I'm happy to put my back into it and help. Okay, cool. It'd be good. I'm just looking at the, so that I'm happy to facilitate that and, and, and, and I'm going to float a few dates probably not this working. Do we, when's the next meeting that we have scheduled? I think we have one for some obscene time close to to the holidays. The 22nd. 22nd. Are we really going to miss that one? Yeah, that was the other question I had is that. I think we can all just kind of say, no, or not, we should probably. Unless there's like something everybody needs to do that maybe we'll do this v sphere triage to make sure that the v sphere folks are all happy and have something to test with next week. They can play on their holidays. But I'm thinking the 22nd, we might have to, you know, call it's a wrap. No. But that's something I want to mention. Oh, sorry. Some of them John brought up earlier. You know, when it comes to hacking and kind of like replacing components inside of open shift and whatnot. You know, we are aware of this, at least in terms of some of the engineering teams. We're trying to write more documentation and blogs kind of addressing, you know, how do you get in here and start hacking these things? We started to add this to the machine API repo. So if you look at the machine API operator, you'll start to see we have like some hacking documents there and we're starting to add more. But, you know, one of the things that our team is taking on is we would like to document showing our users, you know, how to hack on these components, you know, how to replace components, how to add your own cloud provider, these kind of things. Unfortunately, I had to talk all about that for DevConf, but it got rejected. Well, I'll give you a space for it. Yeah. So actually, and I know Amy Merrick's on here and so and she is a documentation person par excellence and a community person par. If we can coerce her maybe into helping us coach people on how to do better documentation and to contribute to the company. That would be an excellent thing to do to to set up a session on that. And also work on contributing guidance stuff. That would be wonderful. Amy, I would love that help. And that would be great. And then so we could do that. And I'm thinking, you know, the more we can do to get the contributor ladder to be clear, hacking guides, how to contribute. And we have that one page that that even put the link in there for on contributing, but that is good, but it's not sufficient, obviously. That's where I started and then sort of figured it out from there so it was a good starting spot but there's I mean I'm putting notes together as I do this and I might even put a video together or something that you know that goes through the process but good. If you're technical, you know, if you're not technical, it's challenging. Yeah. And Jimmy, did I did. If you put that recipe in as a request a pull request against okd.io. I'll add it to the recipe page for okd.io. And even the, and I know Cheryl was going to do some documentation around making that clearer how to add your recipes into up there. So there's there's a lot of room for improvement. It's what I'm saying and I think 2021 is when I really want to focus on that, making sure that we have all that documentation aligned there and if anyone, I was looking at the calendar for things in March. Circling back to doing like an okd end user summit contributor summit kind of thing. If anyone has I looked at my calendars and it looked like March was the emptiest month to do something and to try and do it in using blue jeans or zoom and making it highly interactive. I suppose to intratto and maybe use hop in as, as Josh was pointing out to, but something that's that would give us the ability to do like to do hack things and to actually collaborate and work on some of this documentation live. I'd like to host a few more like working sessions like that in 2021 as well. So we just fix things. Dan, I know I know you, you've talked a lot about like our virtual meetups and everything and stuff what like any thoughts about doing like an okd like hackathon for a couple days next week or something like we could just get together triage some issues and then work through them over the course of a day or two or just allow people to experiment see what they come up with that kind of stuff. Yeah, so what I'm, what I'm always happy to do what I think what what I'd like to do is do this triage session for V sphere and then if we have and we can go all day, you know, as long as people want and keep the keep the lines open to do that. I'm just looking at the calendar here. Just use me a second and see what next week looks like before I put my foot in my mouth and. I think that if we did the triage meeting and maybe made it longer. Like the first part would be actually setting up. Listening to people's issues and stuff like that. And I'm happy to extend the time period for as long as people want. I might not be the best person to run the hackathon, but but let's let's do the first triage thing there and it may we can also do it the next day or. Yeah, it gets it gets easier as we get close to Christmas because people are leaving leaving me alone. So, but yeah, I'm happy to set up a, you know, an interactive zoom account or zoom is your preference or blue jeans, whichever is zoom allows us to do breakouts a little bit nicer than jeans has nothing for that. So, and I have a zoom account now that lets me do that. Yeah, that would be that would be good and maybe the doc stuff, but let's do the first triage session next week. He will comes from that who shows up and what issues we have. So, and then I'm happy to and then I'm happy to do like a reoccurring hack stuff so that we do more than just talk in the working group, which is good. We need to see your faces and get your feedback. Yeah, I didn't want to suggest anything different for next week. I think the triage sounds great. I was just thinking maybe like, you know, I'm looking optimistically towards next year when we can hopefully travel again and whatnot and we get back to like Kubecon and Openshift Commons and whatnot and I just, it kind of makes me wonder like it would be really cool if we could do like an okd focused get together or something where we all kind of are able to meet up and and do some hacking and whatnot and you know, just, yeah, like have fun you know hackathon kind of stuff. Yeah, I think optimistically I'm seeing people in Vancouver open source summit said in August that they're going to try and host something in person in August for open source the Linux foundation thing. And then Kubecon North America is scheduled for Los Angeles in October, which I think is is more viable. You know, I don't have a crystal ball and I haven't been vaccinated yet. My name's not William Shakespeare and I'm not in the UK, but I'm hoping that that we do optimistically but I think that we could do some stuff well before that virtually using zoom and the breakout stuff because basically that's the three day class that I'm in right now that I'm going to have to hop out of is is is all done in zoom and is all with breakouts and zoom and it's working pretty nicely in inner source summit or a pack did a nice thing with breakouts and hacking. So a group of people could be assigned to go to a room, work on something like led by Amy to fix the, you know, the onboarding documentation, for example. Yeah, and Joseph, you're always nervous. So that that's sort of what I was thinking. Is there anything else that I've been talking a lot that other people have that we should have talked about today. Any problems people are seeing. I saw a finger go up by Neil. Was that just a random. Now that was just me saying that everything's been fine. Oh, God, that's amazing coming from you. Thank you. Since again, I have questions. So a lot of times, you know, I want to have a conversation with the developer and get help doesn't seem to be a great place to have discussions. You know, it's good for bug tracking and stuff. We're going to be using slack for discussions in the, in the dev portion of, you know, open shift dev for, you know, development questions like we've been having today, you know, that are sort of outside of, you know, bug resolution and stuff. Or is there a better way or another place to do it. Well, unfortunately, slack is the place that we're that in theory we're supposed to potentially be doing it. So slack is that it's slack, but other than that, yeah, that's, that's typically the place. There's a new set of features and I haven't played with them yet and maybe somebody else has in GitHub called GitHub discussions. That I haven't played with at all. That that might be something we could use as well. And we could always be in the GitHub actions team will be coming sooner than later. But there's another whole group of people over at GitHub that have been trying to promote using their discussion discussions capabilities. Has anyone here used that yet or am I bringing another new feature from GitHub to the forefront here. There's getter as well but there's getter as well but like we are not using either of them right now. I would like to keep stuff in the open as much as possible and tied to like the GitHub community projects agenda and that just so there's one central location but that's me. Well then we could probably just set up getter connected to the GitHub projects on there and let people start discussing there. It feels too separate for me from and I know everybody's not thrilled with Slack but the OpenShift Dev and OpenShift user conversations. I think that's where you really get the direct connectivity and if we silo ourselves off as just OKD folks, we're not going to have that connection. Yeah, but people have to have to be able to get into the Slack in the first place. There are a couple Devs. If we're talking about the Kubernetes Slack, there are a couple OpenShift Devs who do hang out in that OpenShift Dev channel. I mean, I'm one of them. So, you know, for those who wanted to start a more developer oriented conversation like you could certainly try there. And then if the conversation right now are basically the OpenShift Dev open, well three places, I guess, OpenShift Dev, OpenShift users, but also GitHub. And GitHub doesn't seem like a great place to ask questions about how to do something. And I don't want to do that. OpenShift Dev on Slack is, I'm not sure what I think of it yet. Yeah, if you want to ping me on IRC, I'm at MECO on FreeNode. Yeah, it's also, there's the fine line of customer support and technical support for customers versus you get what you pay for. No, I understand. But that's part of the reason why I want to help do things is because I'm a consumer of the open source stuff and not just OpenShift or OKD. But, you know, in order to pay back, I want to make sure that I'm contributing. Yeah, no, I know. I mean, and that's what it, what we, yeah, so I think right now what I'm trying to do is make sure that I know that Vadim and Christian pay attention and Charo pays attention and Mike, you pay attention. But keep the visibility of OKD in the OpenShift Dev and user in that so that the engineers are cognizant that there's a lot of good feedback coming from OKD and the OKD working group. So that's, that's rather than create a separate channel. But I haven't played with the GitHub discussion stuff too. I think, yeah, and I haven't seen the Kubernetes world folks adopted in any way yet. So that was just an ask. And one of the things I think, oh, sorry, Diane, go ahead. Go for it. One of the things that I've seen just in the past couple of weeks is in terms of conversations on GitHub or conversations in the channel or whatnot. It can help for folks that are in the working group to participate in them or folks who are friendly to OKD and to Christian and Vadim, etc. In terms of I've seen a couple of tickets come in where folks were like really sort of demanding to Vadim and Christian and other folks. And I think if you, if you participate in the channels and are friendly and supportive, it sort of lifts the conversation up a little bit more so that folks, it reinforces the notion that Vadim and Christian are busy and they need people to actually, you know, get the documentation into their bug reports when they're submitted and things like that. So I think having conversations out in public helps sort of reinforce a positive culture in dealing with the folks who are actually doing a lot of development on this. Just a side thought. One of the things that I'm trying to do internally at Red Hat is to raise the visibility of OKD within the product managers conversations. And so get your feedback back to them so that they realize that. Like I think, John, you're using the commercial version and the open source origin and OKD. Okay, perfect. So there's, I guess, Rodean Schwartz is there's a couple, there's a number of people who have both OCP and OKD and so there's that that conversation that I'm trying to make sure people realize that this is one of the on ramps to being a customer and, you know, raise that visibility and it's so that's part of part of one of the things I'm trying to do this year to is to really focus on end users and what they're doing and what your workloads are. Because I think there's also, like with the open data hub team, they're very interested in hearing people who have AI and ML and the edge folks and each of the other silos and the telcos and stuff. That are market specific. And then we once we once they know that someone's using OKD and maybe using it in an edge scenario, then we can get some of the resources from the edge team to help us as well and be aware of it. And the more visible we are the more more likely they'll they'll come in and pay attention and take your feedback. Any roads to paying customers. I just want to give a heads up to you to if you're ever looking for more allies inside a redhead messaging between. Please reach out because I raise this all the time with our team about like the issues that I see users bringing to the OKD like forums are kind of different than what we see coming in from customers. And, you know, this is probably something I imagine resonates with with Vadim and Christian and whatnot. You know, for those of us who are like redhead employees and we're working on OCP, but we also really interested in OKD or we're working on OKD. It can get tough for us to like turn it off. You know, because it's like we're going 100% trying to make the product really good and then we turn to the community and it's like the community has got a lot of asks and it's difficult sometimes for us to say, you know, I'm going to I'm going to put more effort into the product or community. It's like we don't we don't necessarily look at it that way. So I would love to see us have a stronger OKD community that like traditional redhead products. There's a bigger communication between the community and the product folks like I would love to see that person. Yeah, no, I think I think that's my goal. Really with and raising up the visibility of the end users in this community. So, Jamie, you'll get a umish request to talk at something and, you know, everybody everybody will at some point and data when you're really doing stuff, Neil and others and Bruce at BC it so really showcasing this coming year. You know, some of the stuff that you're doing. And by recording the videos and you know, there's, you know, the guy from well lead from Armaco in Saudi, you know, those folks are, you know, this is really a great group of folks who show us what some of the problems are and, you know, what problems you're trying to solve and that's really key to us innovating period, you know, that's been mine, been my sort of mantra the past six months here is that really the end users are driving the innovation these days in open source. So, you'll hear me pontificate. I do have to end this call now because I am in a class and supposed to be learning something, but I always learn when I'm hanging out here with you guys so thank you for today and I will go into the working group mailing lists. And we'll get you guys an appointment for next week to do v sphere triage and I'm hoping Vadim that you'll be available to come to that if that's good. Yeah, cool. And Mike and I'll let you guys mostly lead it and I'll just record it. You know, I never can't ever shut up, which is what I have to do right now. Thanks, Diane. Thank you. Take care. There goes my lunch. I know. Bye bye.