 Welcome everyone. This is the Jenkins platform special interest group meeting. It's the 22nd of October. Let's look at the agenda and work through it. So items that I've got on the agenda include we'll review open action items. We've talked about adopt open JDK for Docker on Debian close a retirement plan for Debian nine. We had an open question about asking if we should switch the default image from JDK eight to JDK 11. Our PC 64 little Indian agent access. Windows server 1909 agent support or a cloud and Docker platform support jet draft. Any other topics that we need to add to the agenda. Okay, then let's go ahead. Open action items. I still have the open action to open a jet for Docker operating system support. Last week, I ran an evaluation script to compare our Docker configurations between various repositories, looking inconsistencies, how things are named, etc. The comparisons were between the, the Jenkins core Jenkins agent, Jenkins Docker agent or Jenkins inbound agent and Jenkins SSH agent images and found some inconsistencies was grateful to see that there were fewer inconsistencies and I'm going to use that data to frame the principles and the rules that we'll use in the platform plan. I'm still behind on getting that actually drafted it will be out as out I hope within the next few days. And it is that of an initially drafted without submitting it as a pull request so that we can make corrections and comments as a platform sick before it ever gets in as a pull request. I'm open to otherwise though we could use a pull request to evaluate it as well. Alright, so Alex is with us today so we'll skip over his report on sent those options for adopt open JDK and the install plugins. I've still got the action to prepare blog post on plugin installation manager. That's, that's a good thing because we've had fewer than fewer blog posts, lately than we want than typical. And we had one item from Jim Crawley of IBM on submitting refinements for further parallelization. He had asked some questions recently on the on the Docker image generation process. And that I think that indicates that he's making progress. Any questions or comments on the open action items. Okay, let's talk adopt open JDK eight. So a pull request is submitted that restructures the, the contents of the Docker repository and I had thought that that had been intended to use open adopt open JDK for the base and for the base images. But when I run from the Jenkins slash Jenkins 2.249.2 Docker image is still using open JDK rather than adopt open JDK. Now those images are based that I tested are based on Debian. And they're Debian nine based. So they are slated to be retired. But rather, what we would say is they'll be upgraded to Debian upgraded to Debian 10. Within the next few months as Debian nine is reaching its end of life. So we'll need, we'll need a further conversation with Alex, I thought it was going to use adopt, but as far as I can tell it is not so a lot to check to see if, if the new versions based on Debian 10 are using it. So then retirement plan for Debian stretch nine in the Docker images. And there will be written. Sorry, Gareth I just realized I may not have started the recording. Oh no I am we are good. Sorry. Okay, so switching the retirement plan for Debian nine. So that will be part of the platform plan, the Docker platform plan jet, because Debian nine is an obvious way to test the rules, test the proposals for the guidelines to say hey would that have caused us to drop this naturally anyway. Each switch from JDK eight to JDK 11 I propose to defer this one JDK eight has a very long life ahead of itself. And I don't see much motivation for us to switch to JDK 11 has issues in Web socket connected agents that I'd like to avoid for our users by default. JDK power PC 64 Linden agent access. We had access from personal machines. It's reliable from CI dot Jenkins dot I didn't understand why and Rafael Santa of IBM found that jumbo packets were enabled at their on their side, and thinks that that may have been the cause of network communication problems. A new machine is being provisioned, and we will connect it to our various infrastructure when it's when it's available. Any questions on power PC 64. Windows server. Gareth, you want to take us there and share with us what what we've learned so far, I'm actually going to mute myself so that my clattering keyboard. Yeah, so suppose that there is a bit of an ongoing question about whether this is Windows server 1909 support, or whether we want to change it to be a Windows server 2019 LTSC support. What we've found is building Docker images on Windows is very strict about the version of the kernel that you have in older versions of Windows it's it's extremely strict that strictness has loosened slightly in 2019 and onwards but it would, it's still, we wouldn't be able to create a 1909 image on a 1909 server, for instance, which means that every six months, we're going to be sort of version chasing, creating new VMs to be able to handle the bills of these images so it's a I'll just let Mark catch up slightly. It's, it's, it's an ongoing is going to be an ongoing task and the question is what do we actually want to support. I think the recommendation for the I'm proposing and I think Mark agrees is that we, we go with the LTSC versions of Windows and try and support those and where possible, we can still keep building these on a regular basis so that we get patch upgrades but 1909 also 2019 LTSC is supported until 2024 I think if, if that's the case that we want to go with that LTSC 2019 version then I'm currently doing some testing to see if I can build an 1809 1809 Docker image on top of the LTSC 2019 host because in theory they are the same kernel version or very, very close to the same kernel version. But we know that there is no at the moment there is no adopt open JDK image for 2019 LTSC. There is an open pull request that Mark as the Alex sorry has pushed up for that. Okay, so for the rest for LTSC 2019 support. Yeah, so he's pushed he's pushed up for LTSC 2019 1909 and I think one of the nano servers, but it's I think it's going to be the LTSC 2019 that we need. Okay, so this was, and this was an adopt open JDK pull request. Yes, correct. Yeah, so, Gareth you've described what what I was. I think is the right approach I think we should stop using to stop supporting the semi annual. We should call them SAIC in increment right for semi annual releases, like 1809 1909 20H2. 2004 and then 20H2. Right. Well, and of course there was a 1903 in there and there was an 1803 so. But I think, rolling our generating equipment every six months is is more work than we want and more work than our consumers want. So, and then but then use LTSC 2019 as our base, regularly patch it. So, but with the with the end of life of 1809 being in November. I think that makes good sense at all sorts of reasons. So yeah, 2019 LTSC is based on 1809. So it should, and if we switch anything that we produce should be compatible with what consumers are already running. Good. All right. Yes, 2019 also has the best chance of compatibility that's good. Excellent. Thank you. And I'm going to factor that into the platform plan, Jeff, Jeff as well, try to include the rules as you've described them Gareth so that so that people are aware hey this is the plan 1809 is ending life. Debbie and nine is ending life, and we will, we will switch at this point to LTSC 2019, rather than switching to 1909 or 20H2. Any other any other insights you want to offer there any other guidance to us. No, that's it. All right. See next topic then was Oracle cloud and I've been in discussion with Oracle I've actually signed a confidential disclosure agreement with them so that they can share things with us with me as needed. And I'll be doing some experiments to run Jenkins in Oracle cloud here within the next few days. What we hope is that they will be willing to offer additional compute power and network bandwidth to Jenkins project and help us offset the cost of compute power and network bandwidth that we currently pay to Azure and that we're currently paying for the applications for from from AWS. Oh, and one other. Actually, I should add it here as your credit offer request. So we've submitted a request to Microsoft Azure. Asking that they donate resources to Jenkins. But we'll know within a few weeks by next next meeting, and I'll certainly let you know what the word is if they say no that's okay it's no worse than we have now but we would love to have a donation from Microsoft as well if they're willing. Any questions there. Docker platform support the jet draft. The framework I've got there is. I've got some some basic principles that I'm operating with, and then we'll craft rules to apply those principles, and then we'll use the test cases of current current state, and what the transition is to the next state based on those principles So the one of the principles was that we we want to use current currently maintained operating systems only. I know that may sound shocking or surprising note that makes sense that we don't want to use operating systems that vendors aren't supporting currently maintained JDK's And we want one of my principles is we want a maintainer assigned for each distribution for each image that we deliver so that we know that there's someone who will care for and worry about that. And as an example, right now we have CentOS seven images that I don't think any of the maintainers actively use a CentOS seven image. And with if we don't actively use the image there is every risk that we will fail to that detect problems in it that we will not get the results we want and that users will also not But this is a different concept than we have right now we're right now what we have as a repository level maintainer, not an image level maintainer, but the doctor image actually has the concept of a maintainer in the image. And I'm, I'm going to bring the proposal that we consider putting the names of people in those maintainer image maintainer lists so that we know who's, who's aware of that image and caring for it. Now, Gareth in your experience with Jenkins X or with the Kubernetes project. Are there any principles I should be aware of here of things that they've done that you saw you felt like work quite well. In terms of the base. Docker platform that we supported. Right. We tried to make images as small as possible. That's, it's not always easy. Jenkins X one and two had a used this kind of builder process, which basically requires an operating system and bundles everything into the image. So the images. If you wanted to have a Java builder you required Maven and probably multiple versions of Java and whatever else. I think it was it's quite frequent that the builders would get to around about four gig in size that is a significant cost if you're on bandwidth when you're allowing people to download those. Jenkins X three, it's using tecton so every build step essentially runs in a different container or can run in a different container which means you can base images off scratch and or some of the smaller lightweight things. That's where it wasn't, wasn't as required. So, whatever possible we were trying to base things off. Yeah, the base scratch image or something like alpine slam or something as small as possible. There are times when that's not to above. Okay, that's a good idea and that's an area where I'm not not expert at all so we will probably beg for your help to assist us as we review those changes to the Docker image, image contents that's good. We also hosted all of our images inside. We also hosted CR rather than Docker hub. We're because it offered image scanning by a kind of default and it was free, although I think in about a week's time it's becoming paid for words, there's the different tiers of paying for I think it goes up soon. So image scanning that security scanning looking for outdated outdated packages or packages that have no CDs. Yes. So just to see our supports that out of the box. But then you do pay, even though it should be globally distributed you do pay quite a bit for bandwidth for people to download these images so making those images as small as possible is quite beneficial. Okay, thank you. Any, any other guidance you want to suggest there based on things that you should consider that I wasn't aware of the benefit the strong benefits of multi container images things. And I also know there's there's a there has been a bit of a push recently to go from her towards arm based images as well or I don't know whether it's supporting them both or providing two different images. I know there is a Jenkins X initiative that's happening. Well, and that fits with our platform needs we've got, we've got arm AMD 64 and we intend to do. We've already got as 390 X and we intend to do power PC 64 le so being multi platform is is a good thing for us. And that covers all the topics we have for today. I think we can conclude our session. Gary, thanks very much for being here recording will be hosted in will be available in about an hour. Thanks.