 Welcome, it's the 25th of March, 2022. This is the Jenkins Platform SIG Special Interest Group meeting. Today's agenda items, we've got open action items, Docker agent support additions, Linux packages for System D, Java 11 for Jenkins Core, operating system support policy, exit lifecycle changes. I think we'll hold on this one and replacing these last two will hold, not bother with them today at all, because they need more discussion in the groups. Any other topics that need to be added here? Oh, let's see, we had Windows, LTS, Windows Server 2022, LTSC support in the Docker agent images. That was a topic, good. Or maybe that's what this one was. Let's do it like that. Anything, Ben, that you need to add? Or Kevin, that you need to add? No, I think that's everything. OK, great. All right. OK, so one item I've got is that on the action item list, plugin installation manager docs, we received a pull request to Jenkins.io that we close because the pull request was too detailed for Jenkins.io and filled with a number of mistakes. The pull request still exists when you get the content, but we want to put it instead into the plugin installation manager itself. That remains open. Kevin and I will probably work on that as a topic for our efforts. Next topic then was there. Microsoft has released Windows Server 2022 and their long-term support channel now includes a Windows Server 2022. We've also received a pull request from the community to add it as an agent image, but it needs Windows Server 2022 in our infrastructure. And the Infra team is working on that. No timeline. They're trying to see what will it take to make it work in AWS and Azure and all the places it needs to work. Any questions there, or Ben, any comments from you on that one? I think I know we have some roadmap time as far as when the, I believe it's the 2019 LTS or the 1809 image, it's hard to say how it's listed as. We have some time that that's still going to be supported. And I believe I don't have the exact version, but I think it's Kubernetes 123 that starts to have support for the 2022 LTSC image. And I don't think, I don't know if the Jenkins infrastructure team is using that for that, but at least for the Kubernetes agent images. I don't believe that's available on AWS or Azure at this time. Yeah, and we are, I think still, we may still be at 1.21. So the Jenkins Infra is definitely not using 1.23 yet. Now, we tend to do a Kubernetes upgrade pretty much every quarter. And so I suspect we'll be close to that, but that may mean we're three to six months away before we can use the image. Yeah. Great, thank you. Has the adopt open, or I don't know if it's the adopt open JDK or who is hosting the JVM portion of that image. Has that been created already? Or is that what the pull request was created for? I think we structure our own image based on the Windows server core base, and then we put Tamarin onto it ourselves. OK. So I don't think we're relying on them to give us an operating system image. At least we haven't been on the Linux side. We've intentionally shifted away from relying on somebody else giving us the operating system image. Instead, we take it from the provider, like from AlmaLinux or UBI or Debian. And then we use their base image, and then we layer Tamarin as the JDK on top of it. OK. All right, good. Excellent. OK, so we've got Docker agent support then. It seems like it's not crushingly urgent right now, but we can go ahead with it. And the positives are ahead for us. That's great. I hope someday Microsoft will get out of the requirement that we have to use an exact matching kernel, but we're not there yet. All right. Mike, anything else from you on Windows Server 2022 LTSC that we need to be aware of? Not that I can think of at the moment. OK, all right. Good. So next topic then was the Linux packages using System D instead of System 5 in it. We just had a blog post published today, giving more details, some history, et cetera. It's truly a brilliant blog post. Let's see if it's visible already. Basil Crow did it. It's got some great history in it of, hey, let's go all the way back to Solaris and to real System 5, ancient stuff, and talks about 2010s, how change just came in. Nice blog post, worth reading. But in terms of the relatively low rate of bugs, even for such a large change, and we're going to continue. It looks good. It's in the LTS already and in weekly. Any questions on that one? Was there any pushback or any questions for operating systems that don't have System D in customers that still want to, customers of, I guess, the Jenkins platform that want to use that? I know there's still some people out there that are using older versions of CentOS or I believe the Amazon Linux one is still available but doesn't provide a System D. Will the Jenkins platform still provide System 5? And in scripts, I understand people can write their own. So Amazon Linux one, thankfully, is off support. OK, it's not supported. Yeah, since it's no longer supported by Amazon, the Jenkins project stance is that if the operating system vendor doesn't support it, we don't either. OK. And so Amazon Linux one, that was easy. But there is a current operating system version, a Linux that does not do System D, DevWon. And we've had at least one user who said, hey, could you please not abandon support for init scripts? And so what Basel did is he's actually continuing to deliver the init scripts so that they should still be able to use it. But we are not actively testing DevWon as we're only actively testing System D-based distributions. So if those users of DevWon or other exotic Linux variants that use init are needing something, then they'll have to report the problem to us. OK. Yeah, good question, very good question. Now for me, it's a very nice story. The number of tests that are running now, because what Basel did before he started the work on System D is he implemented a bunch of tests for installation on all sorts of interesting variants, including Amazon Linux 2, for example. So things that you might think, oh, that's kind of not right in the center of our platform plan, yet he's got a bunch of tests for things that are in those areas. He's testing CentoStream, for instance. So all sorts of interesting things in the automation. Anything else on System D? OK, next topic then is Java 11 or newer. So Basel has done a good job of researching and investigating topics. And what you can see here on the screen is a number of open issues that are getting in the way of us dropping support for Java 8. We need, for instance, to be able to compile the late Linux installer, the Linux agent installer with Java 11. We need to be sure we can build plugins with Java 11. We need to get rid of, there's this one right here that worries us that we can't duplicate it, but there's this failure that happens and it seems to be specific to Java 11. So those kind of things, we don't think we're going to be able to do Java, require Java 11 for the June LTS. September is our best hope right now. So we'd love to have more help, more assistance with this, and look forward to people's assistance. Any questions on Java 11? OK, next topic then. And this one I propose is the last topic for today, unless others have topics they want to, which is that we've now published on Jenkins.io, a Linux support policy. And it's based on what we actually test. There are three levels. We support it and supported means we've got something that's tested and we're running some test automation. So for example, we test regular on AMD64. We test on ARM64 on system 390 and on PowerPC. And those test results, we can monitor them and see that, hey, they're well-behaved. That gives us a level one platform. Level two platform, we're willing to consider patches for these, but we don't run automated tests. And we won't accept a patch if we think it would jeopardize one of the level one systems. These are 32-bit, RISC-5, and other atypical architectures, less popular architectures, and preview releases of operating systems. Then the level three is if the vendor doesn't support it, we don't support it and we will not accept patches to attempt support. So as an example, we had a question just recently, what about Ubuntu 16.04? And the answer is that's a level three platform. It happens to work, but that's a level three platform because the vendor does not support it. Any questions there? All right. So are there other topics we need to discuss before we call in for this session of the platform SIG meeting? I had one, Mark. I know with Java 11 coming out, what, I guess, what topics are there for Java 17? Because I know Java 11's initial, I think it's what the initial end of life is next year. So we have about a year of runtime on 11. Like what, like next steps for 17, like propose timeline on the Jenkins platform of when it's going to be moving to 17? Good question. So we just had a blog post that came out announcing preview availability of Java 17 support. So that's a good one. Basel has found that while he's doing the Java 11 work, he's visiting many of the same places that will need thought for Java 17. So he's been doing Java 17 in parallel. And so this preview release, this preview availability gives us a good way for people to help us with the evaluation. And we're visiting the same things that we would visit, we would have to visit for Java 11 anyway. What he found in his exploring was that it was surprisingly, surprisingly smooth that the work that Tim Jacob and others have already done has made things work quite well. And so he's continuing to propose, he's also created a series of epics in Jenkins JIRA. So here's one, Java 17 phase two. And he's got a series of, I think it's five phases for the Java 17 support that are represented here in JIRA. And you can track through these. Okay, here's the first phase, second phase, third phase. And he's been moving issues into those as he detects them. So we've got a reasonable way of managing what's Java 17 going to look like? We don't have a timeline that's being discussed, but we've got a picture that lays out, oh, okay, here are the things that we're discovering about Java 17. Did that answer your question, Ben? Yeah. Great. So JIRA epics used to track the work. And let me put the links to those in there so that we've got those. It's just a really, for me, this technique he's used of doing phased epics in JIRA has been really helpful for me to see where we are and how things are going. Great. Any other questions or topics? I didn't have anything to close. All right. Then let's call this session done. Recording should be available in 24 to 48 hours. Thanks everybody for participating. Thanks, Mark.