 Welcome everyone, this is Jenkin's platform Sieg-Mitting, September 12th, 2023 and today we have Mark Wait and Kenneth Saleno. Thanks a lot for coming, folks. In the agenda today, we have a few open-action items, in fact, one, as always. We have a few things to say about the ongoing work, what is going on, of course, with GDK21, that's the subject nowadays. We'll see pretty fast what has been done lately on the agent and controller images. And then, if you have something to add, we would have new topics. Mark, Kenneth, would you have anything to add to the agenda before I forget? No, not for today, thanks. No topics for me. Okay, that should be a quick meeting. So as always, Docker images, once again, container image depreciation for the Blue Ocean container, which does not mean official Jenkin's controller image on top of which you installed Blue Ocean, it's just a separate container, which has been deprecated for a long time and we still have to announce it officially to the users. But frankly, you should know about that. It's been a while. It hasn't been updated and it's pretty scary to run such an old container anyhow. Yes, for the ongoing work, I don't have... Before you leave that one, before you depart from that one, there was a recent change from Tim Jacome mentioning that now the readme is at least for some container images are automatically populated into Docker Hub. And we may be able to leverage that to make an improvement here. The big thing is we got to get the message out on the site and et cetera. So Tim's change, I think, was in one of the agent images, but it may help us here as well. Okay. So some of the readme files are now being synced with Docker Hub. Thanks for letting me know. I saw that discussion earlier this week, but I don't think of putting it in there. Thanks for listening to that. Now if we had Stefan or Damian today, they would have had tons of things to say about the GDK-21 on the infra. So I just say some of the things I know about that because I participated a little bit on that. So Tethering supplies all the access versions of their GDK-21 for lots of platforms, AMD 64, of course, ARM 64, even RISC 564, and maybe PPC-LE64, I haven't checked, Kenneth. But there are lots of them. They are nightly built, so almost every other day you have something new to chew on. But sometimes the platform is not there. Sometimes it's there. It just depends. You know, it's just nightly built. But sometimes they also supply a more stable version with the called EA Beta, so early access beta. And that's the one that has been installed on the Jenkins infra. So it was in lots of different places, like Parker. I've seen something in Vagrant just about everywhere. So we have installed the latest EA version that was delivered, I think, the second week of August. We haven't seen any other ones since then. And it's almost ready for the official version that should happen next week, seven days from now. Yes, I'm super excited that we'll see. There should be a few EA iPhone beta to remove here and there in the Jenkins infra, but more or less it should be okay. We also have used Update Shelline to keep it updated. So of course, then Temerin hasn't supplied yet another version of EA. And I highly doubt this will happen. I don't think we will see that before the official version. So that's some preliminary work in order to have the definitive version of JDK 21, not definitive, because there will be some, of course, other versions, plus something, plus one, plus two and so on, but anyhow, the official version. So it's working as far as I know. We haven't broken anything. Or would you have any other information that I don't have more? No, as far as we're getting more and more things that support Java 21 in their tests, we found no Java 21 related bugs that would affect production at all. All the changes made so far have all been related to test. So that's really impressive as how well they've done in the transition from 17 to 21. Oh, yes. That's really encouraging. By the way, Mark, as we're talking about JDK 21 and 17, would you like to give us a summary about what you're working on, what has been proposed to the community and if there is anything, it's not finished. I know for the time being, but if there are any progress on that side. Sure. Yeah. So I sent last Friday, I sent a summary to the Jenkins board and Jenkins officers, so the infrastructure officer, the release officer, the events officer and the security officer proposing that proposing what's in the Google doc. And if you open the Google doc, we can we can actually read the text that I sent to them. So it's it's a long description about a transition from where we are right now to a two plus two plus two support model for Java. Java releases go out every six years or Java, Java releases go out every two years and they are supported for six years. All right. So a two year every two year release. So 2023, there's a release. The next one will be in 2025, 17 release two years go in 2021. And each of those releases is supported for six years. But the Jenkins project and the Jenkins maintainers don't want the overhead of carrying three Java versions at any one time in their code base. So the proposal here is to go to two plus two plus two model. First two years of the new Java release, we support it without requiring it. The required Java will be the one previous. So in this picture, Java 21 today is not supported. Will be supported for a period while Java 11 and Java 17 are supported. Eventually, we'll get to the point where we'll only have two at a time. So one, the predecessor version is is required. The current version is supported for two years. After those two years of initial, then the current the the latest version becomes the mandatory version because that's when we start supporting the next major version of Java, the next LTS. So it's a two plus two. And that means we will drop support for the oldest Java version in the last two years of its life. Does that does that explanation make sense, Bruno, Kenneth? Even to me, I understood, which is a good sign, I think. Kenneth, I'm sure you understood everything. Yeah. Yeah. So I and I have to say the the testing I've done in the past three months have only been with Java 17. I kind of, you know, I knew this was coming and it kind of gave up on Java 11. Personally, you know, because it everything worked just fine. And in each new build, I wanted to be sure 17 was good. But it's it's good to hear from you that everything that was working in 17 you think has been working in 21. So I don't anticipate I'm going to be catching anything myself. Right. Well, and and there's an important milestone for people who are using Java 11 right now. That milestone is the October 20, 24 end of life. Right. And that's that's a different thing. Java 8 still hasn't reached end of life. And it won't have reached end of life by by October 20, 24. It's got a longer life than Java 11. But Java 11 will get no more security fixes in the public releases of it after that end of life. So users want to get off Java 11 and on to Java 17 promptly. Absolutely. Yeah. The plan should be made now. Right. Thanks a lot, Mark. By the way, Kenneth, have you tried GDK 21 yet by yourself for Jenkins of other projects now? No, no. So the way that my automation works when I do my builds, I build based on the the weekly that I want to test and the hash for that. And then I don't tweak anything else to be specific. And whatever tags are there from that build, which I've only seen 11 and 17, the last build I did. So it should 21 start appearing when I do my build now. I'm afraid if you're stuck with PPC 64 LE not yet. We'll see later in the document that we have supplied agents, agent images for GDK 21. They are tagged with GDK 21 hyphen preview, but it's only for AMD 64 and ARM 64, unfortunately. Yeah, I was very prudent. So so theoretically, I could I could hack the build to to make it build for PPC 64 LE then. Oh, if ever you want to have a PR for PPC 64 LE, please do so. I would be delighted to see that. Sure. Yeah, well, I wasn't brave enough to do it. Sorry, Mark, go ahead. I think I think it's reasonable to expect that. Adoptium that Eclipse Temeron will support PPC 64 64 LE in Java 21 because they support it with Java 20. And given that now, I don't think right now that they're delivering any pre-release builds that are based on PPC 64, but you could check. We haven't checked because we don't have any physical PPC 64 LE hardware in the Jenkins infrastructure. If you don't mind, let me quickly check. Great. OK, really easy. So GDK, why not? This one is the last one. And. Yeah, they do exist. Good. OK, so all you need to do is download it. Yep. Yoohoo. But the thing is, there is no guarantee whatsoever if they will continue delivering for PPC 64 LE, for ARM 64, whatever. We don't know. These are only nightly build releases. So we put preview because it's not finished. And we even not sure. You know, there was a disclaimer, I think, in the latest image we published, saying, you know, it's existing for the time being, but we can't promise it will still be there one week from now. But yes, that's cool. Go ahead. If you have time, Kness, fire up your PR. I'll be glad to see that. I was about to say something. I forgot. Whatever. We'll see. I hope it will still be there when the official one will be delivered. We'll see. Thanks a lot for all these long summary, Mark. That was just about perfect. Now, what has been on lately, so the last two weeks, we have seen a few new release for the SSH agent. We have seen minor dedicated version burn. So we are now on 170811 and 110211 for the 1117. They have been, as I've just said, the first dedicated 21 preview images. The thing is, it's only for ARM 64 and AMD 64, my fault. Yeah. Then for the Docker agent, we had a few version bumps to and we also have a breaking change and we had three releases. The breaking change is on the windows images. I still don't have the numbers. I'm sure that with at least one user of this windows image. No, I'm just kidding. I don't know. Maybe a thousand of users are using that. But for the timing, nobody has complained that we had some. They had some problem with that. We had a few users not being happy with the Debian Bookworm update, but for the Windows one, no news for the time being. And OK, that that unhappiness in terms of changing from bullseye to bookworm was going to happen eventually. Anyway, bullseye will not live forever. So I don't feel much shame in the fact that, yes, we do occasionally upgrade our operating systems. I don't feel any shame. I'm pretty proud that we were not late. You know, we were not the last car in the train. I'm pretty happy when we, you know, we managed to have our operating, supported operating systems, most or more or less up to date. And when I say unhappy, it's because they have been some side effects. I can't remember them all. But for example, I remember a plugin not working anymore. Because of the controller email that went to Bookworm, because something changed in LDAP within Bookworm. That kind of things happened and it makes a project progress because we have to make changes to support those latest changes. That's pretty normal. Now, for the Inbun agent, that same thing, a few version berms and two new releases. And the same thing for Windows. We now we use an LTSC 2019 instead of the Windows 7 core. And we also have added preview images for JDK 21. And even for Alpine, all of that started with a user saying, hey, it would be nice to have JDK 21 Alpine or images, to which Damian answered, no, I'm sorry, that won't be possible. Timurine doesn't supply any Alpine or 64 images. It's complicated. And then I checked on the releases. That's not true anymore. We could do something about that. And the user created a fantastic first PR. We have a new contributor and solving the problem by himself. And then I took on and made the other agent modifications so that we had JDK 21 all the releases. That's a nice collaboration. I'm pretty happy about that. Anyhow, nothing major on the controller, because it was already ready for JDK 21, I think. We have a few bumps from UB9 and UB8 and, of course, different versions of JDK 17 and JDK 11. It looks like we made it to the end of the agenda. Anything you would like to add any feedback, any question? Nothing for me. Kenneth, I'm waiting for your PR. Not that I will be able to review it, of course, but I will be happy to see emerge on the guitar repo. Wait a sec. I take it back. There is something it's visible on the screen here and it's a reminder on the screen of something that we have yet to do. Notice the baseline for our image is dash CentOS 7. Yeah, I was pretty shocked when I saw that. Should I say it's convenient, it's convenient and harmless because all we do is use the JDK that's bundled inside it. But ultimately, we really should switch from CentOS 7 to another thing. Yeah, is it binary compatible with UB8? No, it is. Well, yes. And so if Temeron provides a UBI8 container image, we could use that instead. Oh, OK. It's not using model as Alpine does. It's just a Lipsy standard classic, right? So I made a proposal a few months ago. You know, before the time being, we have two from the first form is for the Eclipse Temeron image. And then we have another from that takes one. Jailing has been run. We integrate the resulting JDK into the final image. And I made the proof of concept, I may say, that was only downloading the binary from Temeron binaries and then installing it after running Jailing. We finally forgot that because it's not necessary. The actual method works pretty well. But maybe in that case, it could. It depends, right? If I like, I think Tim Jacob had the right approach to say, it is good if someone else is building a container image and supporting it, let's use their work. And I think that's a very sensible choice that he recommended, but a container image based on CentOS 7 doesn't align with our support plan, right? And in June of 2024, it won't align with anyone's support plan. Yeah. So either now or June of 2024, we've got to get off that thing. And therefore we need to choose what the new destination is. And if they already deliver a UBI 8 or a some other variant, you know, maybe they deliver a Debian version, either of those would be fine. They're both based on G-Lab C. Yeah. OK, I get it. Why not? OK. So it's for which one is you think that this CentOS 7 it's UBI something or I haven't put the link to the actual PR of this thing. So I don't know. I'm sorry. Ask your question again. Sorry. This controller image using JDK CentOS 7 is for which target operating system? All the Linux targets are almost all the Linux targets. So Debian, for instance, uses it. And and Alma Linux uses it because all it's doing is delivering the JDK. It's just a convenient way to get the JDK. And and so we haven't switched from that convenient way to get the JDK to another convenient way to get the JDK. So we could stick with another Terumin Tamarin supplied container image. Right. We can switch to another Tamarin container image and be just as happy. Right. But I think so long as that other image is not an Alpine image. We don't certainly don't want to put a muscle based JDK inside of being there to try that running G-Lab C. No, you don't want that. OK. So that's something I could do, I guess. Yes, it's even simple. I thought there was some hidden implication, you know, something that I hadn't seen. Not that I'm aware of. No, it's just the problem is if you choose something cutting edge, more cutting edge like UBI 9, there's a risk that the JDK you chose may not run on those those older operating systems like Debian 10. Right. And I was going to say something when you brought up Alma. I would probably recommend against that because I think in the near future, they're going to be tracking stream and not enterprise Linux. Well, and and the the fact that we have an Alma distro is even in its own a question, right? Why? Why bother? It's an open question that we've we still got to confront. Yes. Yeah. So I guess that the leapsy version that is running in Bucorum is not the same at the one running in both side, for example. But the difference may not be major enough to be a problem. And the one who would have the problem if there was any problem would be us as we are using gelling to build a JDK. So that would not be the end user who would face some issues, I guess. Right. So could I try to do that, starting from the Bucorum image? OK. Yeah, absolutely. Well, if you look at every place where we reference a dash sento seven in a from clause, we want to replace all of them. And what the replacement should be is is a topic for investigation. I think you'll have to look at the list of containers provided by Temeron and see which one is the is the best fit for our needs. Right. Looks like fun at this for me. OK, thanks a lot for rating this point, Mark. I wouldn't have thought of that. I was just kind of shocked, but I forgot. OK. Thanks a lot. Anything else before we wrap it up? One, two, three. I think that's fine. No. Thanks a lot for coming, folks. I think this was really interesting, at least to me. The recording should be available from 24 to 48 hours. And until next time, enjoy Jenkins. Thank you. Bye bye. Thanks. Bye bye.