 have and how we intend to solve it. So that's basically just some of what we have on this page. So it explains Jenkins on Kubernetes and documentation we're going to be working on. So my thought is that as time goes on, as we have discussions, we could keep updating the page with more content like details of topics we intend to cover on the page and all of that. Excellent. And that looks great to me, and it sounds great. You did a really good job on creating the new layout. Congratulations. You've reverse engineered how to do a layout and you expressed it in a handle very well. Thank you. Well done. Thank you. So and I opened another pull request just before this meeting started to add G-Sort projects page to sub-project session as we discussed in the last meeting. I'm still checking it, I think there's an issue with the check or something. Very good. That's excellent. So next step as well. Thank you. Let me capture the link to that into our notes so that we've got it. New pull requests submitted for the structure. Excellent. And I should be able to review that pull request later today. I assume we're getting towards the end of your daisy now. So I should be able to review it. Oleg, no, he's traveling right now. Mark, he's sick. And Kristen, I suspect you're busy all day today. But probably by the time you're in the office tomorrow or by the time you're awake up tomorrow morning, you should have some review comments on it. OK. Thank you. Here we can do that. Now, Xenia, in terms of our working styles, are you OK if I push proposed changes to it myself or would you rather, that's a little bit less learning for you but a little bit faster to get the content out or I could just suggest, hey, I think you should change this and then you do it. Do you have a preference which way you would like? I think I would like the suggestions. OK. I will do suggestions then. Very good. Thank you. Thank you. OK. Just so I can have a better understanding of what's changing and so I don't make the same mistakes. Yeah. And I think that's great. I like the GitHub suggestions feature. It lets me offer very specific, oh, I think this should become that. And then you can write from GitHub, accept that suggestion and commit it right there. Yes. OK. Great. Anything else on the pull request? No, nothing else. OK. Next topic was the blog post to introduce Google Season of Docs. I had created confusion the last time we met by describing much something much different than what really was needed in the blog post. Xenob asked questions in our last meeting on Monday to clarify and the clarity is listed below, Kristen. So do you have any other questions you wanted to discuss there, Xenob? No, I don't. I'll have drafts ready for review on or before our next meeting. All right. Excellent. Thank you. OK. And access to a Kubernetes cluster, I've got, I'm exploring two paths. One is a donation from CloudViews and the other is a donation from Oracle. Oracle Cloud team is discussing, hey, how can they get more involved with Jenkins? And I still don't have an answer, Xenob. I think you're OK starting the writing next week without access to a cluster. Is that still OK? Yes, it's OK. OK. The motivation here is we've got, we're also mentoring a Jenkins X writer and they really can't start writing until Monday, so I'm pressing hard to get that one solved and more info at Monday's meeting. I'll let you know what I learned or by email. Next, structure the documentation of the Kubernetes on Jenkins section. So Xenob, would you like me to open up the proposal? What would you prefer? Yes, I think that's for now. Let's do that. And if I recall correctly, it was right here at the bottom. Yes. There we go. All right. And structure, yeah, structure is the same. OK. So Xenob and I discussed this one on Monday, Kristen. OK. And one of the daunting things for me was that I am probably the worst possible person to suggest how to structure documenting Jenkins on Kubernetes because I just don't have the experience. So that was one of the things we were hoping for, your guidance and your coaching and help. Now, Xenob, do you mind if I just take a copy of this and put it into a doc and we'll edit it right there so that we don't damage your original address? OK. That's probably the best way to do it too. And that way we can put comments and things on the stage. Right. Well, and then we don't feel shy about throwing away the things that I grabbed during our meeting. OK. So let's put it right. OK. So here's our text ready to go. Xenob, I suspect this is a place where any of us can offer suggestions or ideas. Kristen, if you've got suggestions, Xenob, do you want to guide us through some particular things where you say, oh, I'd like to do this and this? OK. So my thoughts when I was working on this is to have probably the first section like a user guide. So starting from the basics, what is Kubernetes, how Jenkins and Kubernetes relate or Jenkins and Kubernetes? Just like an introduction, then a guide to installing Jenkins on Kubernetes cluster. I think this is good for the installing Kubernetes cluster. Do we also want to, and Helm is good, do we also want to make sure we include the Jenkins operator? Ooh, right. Right. So Jenkins operator, because that's a different way to do the install, but perfectly valid, right? Right. And it's a good way to do this. And I think there's, luckily, I just actually watched the video last week, just getting started, tech talk that had been done by somebody. I'll see if I can find it again, I closed it. But yeah, if you want to get started with Jenkins operator, it's another good way to get started. Oh, good. Okay. All right. So yeah. I'll put it in here when I find it again. Excellent. All right, cool. You can keep going. Sorry. Yeah, I actually think this Jenkins on Kubernetes versus Jenkins, it shouldn't be at the top. Oh, good. Okay. Well, and maybe it's irrelevant in the sense that they know they're running Jenkins. We don't gain much by clarifying for them. What if we just deleted it and say, you know you're running Jenkins, and we don't have to. Good. Why? Now, Zina, in terms of, I was assuming there'd be something about administering Jenkins on Kubernetes. And now, this is just me thinking. So you're welcome to discard it, but upgrades, for instance, from one version to another, and upgrading plugins, and managing plugins. Kristen, I think there might be something worthwhile about tracking job definitions, and what I'm used to having called seed jobs, or maybe a different was it, or that's just called job definitions. The other one might be system configuration, credentials. Let's see what other things. Like if there's anything specific needed for setting up, like additionally running on Kubernetes. Because I guess the one thing I'm looking for is like, we should try to focus in this section probably on things that are different from managing. Oh, right. Like, you know what I'm saying? Because if we start getting into an entire guide on how managed Jenkins, it can get like a whole bunch of stuff. But it's a thing to highlight the pieces that you need, or very specific to be able to handle. That's a very good point. So it's more of what's different from typical, right? Because we certainly don't want in this section to describe configuration as code per se, because that's described elsewhere, right? So a good point. OK. Let's read a system configuration for Kubernetes, more than it is, how do I configure a system for a general purpose? Right. OK, good. Doesn't mean we can include links out to the other stuff. That's very good. And I've watched while the health charts go through upgrade processes. So is there something there about deploying a new version, defining it, and deploying it? Yeah. Xenob had included scaling Jenkins on Kubernetes. And that one seems like a fascinating topic. Yes. That will be really interesting. I can imagine that's something that a lot of people would be interested in seeing, even if they know the basics of how to use Kubernetes or Jenkins on Kubernetes, that would be a very popular section for more advanced users. So things like managing performance, right? Managing performance of jobs, system. Now, are there any Kubernetes-specific things relative to topics like backup or those kinds of things? Or is that, oh, use your standard techniques? I don't think so, but they're likely for more advanced people who know more about it than I do. But yeah, from what I know now. Now, this one, building Docker images, is, I thought, quite complicated. So choosing, isn't there a choice between Docker Kaniko and other builders? And I don't even remember the other builders' names. Yeah, we should definitely highlight that you should probably choose Kaniko. Like, as like you probably should highlight, because Docker and Docker is definitely highlight having that one first. Because sometimes Docker and Docker is an anti-pattern, even though I think a lot of people do use it. I've even abused it as like a before, just because you had to do it. You've had to be able to figure it out. But we should focus Trump's front of you now, like a Kaniko solution. Now, and is this a place where we ought to, should we, in this context, talk about container registries? Or is that outside of the scope? If we're talking about building the Docker container, we probably should mention it minimally. Okay. I think it might tie in a lot more to sometimes to the cloud provider stuff that is talked about like in the next section, because depending on who you're using, like definitely bring it up, but then it's like, depending on whatever cloud provider you're using, might end up changing your container registry choices to where maybe you're using, like I know that AWS has its own, but they 100% escapes me right now, but they have their own container registry type, you know what I'm saying? Right. So you can call, yeah, I agree. They talk about the general stuff, but also then there might also be the project. I don't know what to do with how much use we use. Xenob, any things that we've missed here in this section before we go to cloud providers? I don't think so. We look at cloud providers then. So Jenkins on GKE, nice, okay. So those are, I had missed that. Those are hyperlinks to existing locations, great. So GKE- So if they already, if those are already guides that have been written there. I believe so. I think these are links to the cloud providers, right? So here's the cloud provider for that one. I think this one is also, this is from Azure. So we got Google, Azure, and those are excellent. And then let's see, IBM, I'm, I don't think we found one for AWS or that probably should be in the list somewhere. Jenkins on AWS because certainly they are a major player. Yeah. Like if someone decides to build AWS. Here it is. Here's the, yeah, sorry. Here's the AWS link. It's just, it's a relatively specific link. It's sort of a very specific solution blog and very detailed. Whereas the others felt to me at least like they were more general purpose. Now, Zina, do you have any suggestions there on how you think you'd like to approach this? Do you want to choose them by popularity? Work on the most popular first or some other, some other reasoning? I think the idea would be to arrange it by the most popular. That way we'll be able to reach out, reach more people. And I think so too. So I've, I've tentatively put AWS at the top of the list because I think they're the largest, the largest provider. And then I think Azure is second and Google is third. What those will mean in terms of your development experience because certainly you can't, can't do, you can't do a documentation for EKS, the Amazon experience without us getting you an account on AWS, right? We'll have to get you access to those resources. So that, that will need some time to set up. Yeah, we can be, I could be working on the user guide in the meantime, depending on when we're able to. Good point, okay. And I, that also lobbies that I could go, go to these suppliers and say, hey, would you be willing to donate? Because they may say, hey, we're happy to donate funds to help an open source project like this. Great, okay. Any other notes, Kristen, as you've worked with the cloud providers, any crucial things where you think, oh, be sure we remember this or be sure we cover that? No, but I guess that I think for us is making sure that we do not live or favoring anyone, cloud provider, which I think is easy to do because if we have a list to all of them then and then if the directions are mostly like, I guess if the initial setup stuff is like, for example, this is how you set it up and using mini cube or something else just make it a little bit more clear. Just, yeah, just making sure we're not showing favoritism. Right, very good. I don't see anything that's jumping out at me right now. Now, there are many of these cloud providers have a container execution service. I think AWS calls there's Fargate and Azure, I know we use with CI.Jenkins.io. They call it ACI, Azure Container Instances. Is that in scope for this, do you think? Or is that no, that's too far afield, use the Kubernetes plugin instead? Well, those are for running specific jobs, right? Not for, okay, yeah, so maybe that might be since that's dealing with running Jenkins and that's so much, I can tell like this, I think the goal here was more for having like how to use Jenkins on Kubernetes, right? Right, okay, good, so I'm gonna just take that out there. Can I take it out? I don't know, Zedad, is that something that you had thought about covering here? But I thought it was more like, here's a Kubernetes environment, make Jenkins run on it. Right. Yeah. Okay, good, so taking that out. Yeah, so maybe we can add some extra stuff like that later if there's time, but I would mostly focus on let's get Jenkins running and then, all right, so now how do we configure, I guess, template? Maybe that's more of like the organizing templates to be able to run jobs, but we're not going to tell you how to change to write the Jenkins files, because maybe that's for it. Does that make more sense, Mark? I think so, yeah. Here's how to set up all the, basically anything inside of getting Jenkins to run and maybe like in the manage section of Jenkins. So then as you as administrator are going to be able to have people be able to create the jobs that they need to and use what's out there. Maybe that's kind of maybe how this project is. Right. Anything else on cloud providers before we go on to demo? Now, Zedad, on this one, had you envisioned like a video or how would you, how would you see this demo? Yeah, so this hyperlink actually links to a video I saw on setting up Jenkins on Kubernetes. I was thinking we could highlight that in the documentation, but since Mikey mentioned something about CataCoder, I think this would be a good section to include that if we're going to be working on that. Very good. I like that because CataCoder has the benefit. If I've understood what its intent is, that they would actually use a CataCoder resource to start up their experiment, to explore, yeah, okay. Yeah, that would be really nifty to have in the demo section. Any other things you recommend here, Zinab, in your experience of creating these kind of demos? What things interest people? What things may get them most excited, most enthused? So in my experience in writing documentation, I think demos should be able to take people through simple steps so as not to tire them out. So more like setting up Jenkins on Kubernetes or anything simple that's not too deep or technical or long rather, so people don't tire out while watching the video or going through the tutorial. And something should be able to relate to people at different levels, that's beginners, intermediate, expert, so someone who is speaking this documentation for the first time and is really confused as to where to get started. So this demo should be able to at least give them an idea or a sense of direction as to where they're going to or how to get started. So that's why I put in setting up Jenkins on Kubernetes but I'm not sure of other topics that we can cover in this section but I'm sure there are loads. Very good, okay. And one that I've seen with the Jenkins tutorials on Jenkins.io is we really need a high probability of success. Yeah. Users that don't succeed in a tutorial get very grumpy. Yes, you're very right. They grumble and the grumbling gets and it's, Kodakotas makes it even more attractive that way because they assure the environment works so we're not trying to tell someone how to run in an environment that is uncontrolled. Think of all the times that the grumbling on the Jenkins.io site about, oh, this demo failed. Oh, where were you running it? In this bizarre and odd environment. Oh yeah, it would fail there. Right. Okay, sorry. We're not even at Jenkins yet. Right, exactly. It's like that Jenkins is not going to be the problem. Okay, anything else you'd like to discuss with on the demo topic? One thing I'm pretty sure of is as we, once we start writing, I'm sure we're going to be able to highlight some aspects of the documentation where it's good to just create a short demo. Good point. Yes, so prefer multiple brief demos rather than a single larger demo, right? Yes. And I think Kodakotas lobbies for that as well. I believe they talk about an upper bound on time. Say, hey, your tutorial shouldn't take more than this amount of time because we lose people after that. Okay. Also, question, is there a good additional SIG that would be a good place to share the demos and stuff to maybe get some testing or some additional visibility? Actually, that's a good point. There are several. There are at least two or three that would probably be interested in that. Let me offer them here as candidates. So there's one is the cloud native SIG. Right. Certainly, they'll be intensely interested in Kubernetes. Right, because I know that sometimes, especially if we're all involved, we'll be paying attention, but we're tested the stuff. We might be more familiar with it or we're just like, oh, okay, we understand what this is trying to say versus having another, maybe some other people come in and try it outside and get some additional perspectives that we might have missed. It's always good to ask other Jenkins experts. Jenkins and cloud experts. Particularly, so cloud native, we get the benefit that there are people there who are likely Google specific or Azure specific or AWS specific and can highlight, oh no, that's not gonna work as well for you if use this other technique. So that's very good. So multiple cloud providers give us hope there. Then I put platform SIG because we've got representatives from IBM, for instance, that periodically attend a platform SIG and talk about their PowerPC platform or their system 390Z platform, so their mainframe platform. And if Zinab, you wouldn't mind sharing demonstrations at some point during this, in those two SIGs, they would be delighted to have you there. I love that also. And then the documentation SIG, this one is more about structure and how do we fit it? So interested in structure and how to make it all work. So absolutely that would be a positive one. Doc SIG meets monthly near end of each month. Platform SIG meets every two weeks, Thursday, and it's actually not far from a reasonable time for your working days, Zinab. It's, I think it's one or two and one, 13 or 14 UTC. Cloud native, I think the meeting times are still being worked out. Great. Anything else on demo before we go on to the next topic? I think that's all for me. Okay. So then additional resources. And I think this is good ideas in terms of should some of these be included? And oh, oh, oh, oh, actually here's a good one. Okay, I missed this. This quick labs thing is a Kodakota style thing from Google Cloud. Okay. So this one, I'm gonna just borrow this and put it up near the Kodakota topic. See Google, quick labs. That would be really interesting too. It's like a, hey, an extra, if you're interested in running this on GKE, it's some people that might be their explicit use case. Right, right. And they, yeah, so okay, efficient. Oh, I did not even consider, okay, there's another potential vendor. Pivotal was bought by VMware, weren't they? And as such, now we're part of the VMware suite. So PKS-based clusters. Any other things we should do with these additional resources? So home charts I'm assuming is covered in the installing and in the administering. So that's a good reference. Jenkins docker in docker, at least the topic, is covered there and Kristen, you noted that's frequently an anti-pattern. Right. Yeah. And configuration is code. We discussed that one. Then, oh, okay, this is, okay, this is an online meetup on the getting started. Oh, Rancher, Rancher is another one, okay. And I don't, I don't, what's that? It's a different type of container, right? Oh, see, I don't know Rancher's market space. I thought they were a separate component. So I'd have to learn more about that one. Well, they might be coming at it from the perspective of using docker files because they have their own, I think they have their own way of defining files. So that makes them why they're trying to do it as like a hey, instead of using docker. Okay. Here's how to use Rancher. I don't know what their market share is. Like it, if there's a lot of people out there using Rancher. Great. Okay, so that sounds like since you don't know it and I don't know it, it holds as a low, likely low interest for right now. Okay, good. Yeah, but it's good. I mean, it's something they'll look into too. Okay. And we had already talked on those. Oh, one that hasn't been discussed here that Xenob and I talked about last week or on Monday was Microsoft Windows and Kubernetes. And I don't see that anywhere here. Does that fit anywhere into this structure or no, it needs to wait for another time? I mean, I guess it might be a logical thing to say. Window, no, not really. Because I bet they care about windows on any of the platforms and probably can run it anywhere. Maybe I should hide it under advanced topics and we leave it till later. Is that a fair thing to do? Kristen, what's your experience with Kubernetes, Windows and Kubernetes? The Jenkins project has wrestled with it a little bit, but it's sort of working by using these Azure container instances. Right, I was like, I haven't really had situations where we've had to use Windows on Kubernetes simply because it is so painful. So I'm just gonna list it as an advanced topic. Yeah, I think so. And if that's more about like using it, I guess if there's anything that needs to be done inside of, I think it would be able to speak to this, inside of Jenkins in order to tell it to actually have the right license for Windows, all that other fun stuff in the, basically the Bandage Jenkins page, then we should cover it there. But yeah, that does seem pretty advanced. Yeah, I don't know how many people are, I can imagine people would do it only for situations where you need Windows, like a Windows specific product. I know some security scanners, like if it only runs with Windows, or if you're doing a certain test of your product that it needs to be able to be deployed. But most of our stuff, I think people are using Linux. Right, yeah, if I'm deploying a Microsoft.NET based website or a.NET based web service or a.NET based microservice, then I've got to be on Windows. Oh yeah. Okay, got it. So we cover the topics that were on my thought, thoughts and way beyond, far beyond. Anything else you would like me to take note of? No, nothing else. And Kristen, any topics you think we've missed? No, definitely doing the, walking through the layout was a good thing to do because I can help us with started Mac. Great. Next pieces. I don't have anything else specific. Okay, then project timeline. Xenob, I'm not sure what to offer in terms of timeline here. What would you suggest? What works best for you in terms of planning your projects and what should be done first, which should be done second, those kind of things? So, well, for me, I think I just like to, if, like from the way we've broken down the topics and all that, since we know what we want to cover, I'd like to be able to determine how many sections or which topic to deal with within a week or probably before our next meeting that we were able to time the whole project and not plan for too much or less. So, and also know what we are expecting. So say, for instance, if we say, okay, installing Jenkins on Kubernetes probably without tape one week, then the following week, work on this. I think that's how I plan, I plan project. So things don't happen haphazardly and everyone has expectations. Sure. I like that, that sounds great. So map them to the calendar. Yeah, I like that a lot. Okay, so as far as I can tell, we certainly have flexibility to adjust as we learn more, right? Yes. I guess, what other question I have? Are there any pieces here in this kind of layout or thing that might take some coordination and extra time to accomplish? Like, I know that Mark, you're going to talk to some of the cloud providers to, you know, that's something that, it's out of our immediate control of our team just from, you know, having to work with external teams. I'm not sure like how, I've never used CataCoda to do any type of, like, you know, I've never like launched a thing on CataCoda before. Does that require us to like set things way ahead of time or I don't, I would have to sign up for something. I don't know if there is. Yeah, and Mark has agreed to give us a tutorial session on CataCoda. Okay. And so I think getting that scheduled would be very good in order to hit their dependencies. The team member, so inside CloudBees, a team member was working with CataCoda as well and found it to be quite fluid, quite comfortable, but it's worth us having Marky do the demonstration, talk about it and say, here's what he's learned. Marky has even more recent experience with CataCoda than my team member did. So. All right, perfect. Cause then it's like a extra barrier. It's like if we had to wait or submit something to be like, we would like to create, like create a course that I didn't know if it was something where we'd have to wait and it's submit sooner rather than later and then work on things in parallel. I'm just, I guess I'm trying to go, what can we do in parallel to get, so we don't end up in a situation where we're, you know, of course you'd have your blocked or something, wait, you're like, you're just waiting for someone else to get back to you without something. Right, right, absolutely. And it's out of the control of, you know, Mark myself or like Marky. Great. Any other key points? So it seems like I've got an action, we've got, I've got action items to continue on the work that I'll get the, the invitation sent out for the Cotacota session with Marky out today. I assume he won't respond for a day or two at least, but hopefully by next Monday we'll have it. If Marky were not available, if his illness turned longer, I think I could ask this colleague of mine to come give us an overview or we could invite Cotacota themselves to give us an overview. Great. Okay, let's see on this group. Okay. Any other topics we need to cover today? I think everything's okay from my side. Xena, I think it's okay for you? Yes. Okay, great. Then let's call an end. I'm going to stop the recording. I'll post a recording and I will put a hyperlink into the notes to the recording in case we need to refer to it later. Thank you, Xena. Have a great evening. Thanks, Kristen. Thanks very much. Thanks. Thank you. Bye. Bye.