 Hello, this is Jenkins Platform Sieg meeting September 9, 2022. Today we have Mark Wait, of course, and myself, Bruno Vrusha, and today the subject are numerous. On the agenda, we have some open action items. We'll talk about the preview suffix from GDK 17 agent images. We'll talk also about the talk or image management for Jenkins agent. And also the Docker container deprecation for the blue ocean container. And we'll see something about the request for specific tools in the Docker images. Yes, because, yes, we removed Coal a few weeks ago. Of course, we'll talk about Java 11, Java 17, and DevOps World, which is in a few weeks from now. Mark, it looks like there is an open action item on your side. Yes, I've shared credentials for the system 390 machine already. I haven't shared those yet. So that still stays as an open item, probably several weeks before I'll get to it. Of course. No hurry, no hurry. Now, for the preview suffix removal from GDK 17 agent images, we had open three pull requests, which have been, no, pull request issues, sorry. And somebody that came out of the blue made three pull requests that were merged. Yes, a new contributor. That's something nice. Thanks a lot. Whoever, maybe I forgot the name on the contributor, unfortunately. Anyway, thanks a lot. Now, yeah, container repository management for Jenkins agent. Mark, could you tell us a few things about that? Yeah, so the struggle here is that right now we have many, we have multiple repositories. And with multiple, multiple repositories that are managing multiple container images. So there is a multiple repositories and multiple images from those repositories. And with the multiple contain multiple repositories, it's quite difficult to do a release process that is clean, simple and comprehensible. So releases are unnecessarily complicated. Yes, I encountered that a few weeks a month ago when I tried to add the ARM64 architecture for a few Docker images. And frankly, we missed some things. There were some versions missing and it made a mess. Yes, I totally agree. It is too complicated. Right. Well, and the stacking and the layering is another piece. Now, we probably cannot get rid of any of the layers or any of the conceptual blocks because people depend upon them in some way or other. However, one of the proposals is from Damian DuPortal is to combine the repositories into a single repository that could then be used to deliver to multiple destinations. However, we've got to do more designing and more planning work to accomplish it because what we cannot do is we cannot just drop support for the existing container images. People expect them to continue simplifying the release process. It's not justification to drop or to rename labels. We've got to be sure we retain compatibility. Of course. And that's really it. Then there's one more topic, which is this separate repository for Jenkins agents with tools installed. Which is linked to a topic we'll address later on in this meeting. Oh, yes. Yes. Good point. So that one, let's talk to it later then. They are not actively maintained and many of the agents, many of the container images are still using Java 8 and that just won't work with the most recent LTS. So they have to be switched, either they need to switch, need to be upgraded or we acknowledge that they're ended. And I think people will want, let's just say it, there's not an either here. They need to be upgraded. We don't have any metrics about the number of times these have been downloaded. Are they used frequently or not? Ah, actually Docker Hub does provide download metrics. And I'm sure that what we would see is some of them are heavily used and others are rarely used. Yes. So that we have a list of priorities if we have to update them. Good idea. Right. Okay. It's not very precise on the Docker Hub repo directly. You have to use the API, I'm afraid, to have the real numbers. For example, I have one Docker image, which is more than 2.1 million downloaded. And on Docker, it just written 1 million. No, it's wrong. Oh, okay, all right. But if you use the API, you'll have the precise number. I see. Good. Well, that's very good. Whoops. That was my shameless, auto promo moment. Good. Yeah, any questions on container repository management for Jenkins agents? No, I only agree that that's necessary to do something simpler. Yeah. So I think it'll be a topic for discussion at the contributor summit. Oh, nice. Because we'll have the right people present there for a good discussion. Oh, yeah. Yeah. So let's just plan on it. I don't know that we should put it on the agenda, but rather over the lunch table or just sitting around, we can talk through because we'll have Damian there, we'll have Kim Jacome there, I'll be there, Bruno, you'll be there. We've got the right players to be part of that discussion. Super. Next topic is Docker container deprecation for the Blue Ocean container. We've seen lots of efforts from Kevin, for example, regarding the Blue Ocean, putting message just about everywhere saying, you know, it deprecated. You maybe shouldn't count on it. But that's not the case yet for the Docker container. So yes, we have something to do regarding that container. Yeah. And this deprecation really, there's some software needed here, right? We can certainly change the text on the Docker Hub page. The challenge is most people don't read that page. Once they've got the container working, they will never look at it again. And if they did look at it, they may not recognize whatever change we make. So then the question is, do we put it in an LTS change log? Do we add it to Jenkins.io pages? And then the bigger question, do we do something like a Jenkins administrative monitor that pops up and says, gives you a warning in the top right-hand corner of Jenkins controller. And when they click it, pops up a nice little dialogue that says, you are running a container that is deprecated. Please make plan your switch to this other container. So is that a discussion for the documentation Sieg and for the Jenkins governance meeting? Actually, I think these are something that we can handle here. Because it's all part of what I'd call the platform side. So for me, the biggest challenge is this one. It means someone has to write the administrative monitor. It's a little bit of Java code. And then test it that it works end to end. And that the whatever file we're using to make the decision shall we show it is only in the Blue Ocean container and not in other containers, et cetera. So there's some software work there. That, I think, is the right way to do it for the healthiest experience for Jenkins users. These other places are certainly minimum necessary. And we want those as well. Cool. Now the next step for me, I think, is really we just this is work that needs to be done and we report on it regularly in platform Sieg meetings. OK. So we should give ourselves a task to have a look at that Java code. So I'm OK to contribute to that, even if I don't know where to start. But. Yes. Well, so and I'm not sure I'm not sure I'm ready to put an action item yet as much as knowing that let's keep let's discuss it and begin the ideas of, hey, here are the kinds of things we think should be done. Maybe maybe the answer here is and maybe this is a valid action item is create an issue in the Jenkins packaging repository. Or the docker see the challenges, which one maybe it will create an issue that proposes this, yes, exactly, that proposes the deprecation and includes details of the steps to do it. OK, good idea. Yeah, because that now that's one the challenge that is the creating the issue really does mean defining the plan. Good. All right. Next subject now is the request for specific tools in the docker images because, yes, we had some tools earlier in the versions goal, for example, and you told me the other day that we previously all also had some other tools that were removed from images. But yes, sometimes we have to do some cleanup and code is not strictly necessary in our docker images. So, yes, it's gone. We feel sorry for the users who heavily dependent on it. But the way it is, from what I understood for more advanced Jenkins users is, yes, these image are there, but for you to augment them, to change them to add the tool that you need and you should not rely on them to do everything and to be bundled with all the tools that you need, you should just extend these images. Am I right, Mark? That's correct. And it's a general case problem. If we get into the mode of, oh, we'll deliver the tools you need, we now become responsible for the care and maintenance of those tools and delivering versions of those tools and making sure that when a security issue arises in those tools that we resolve that security issue, it's part of what makes it so challenging to have these images, like we mentioned earlier, with separate tools in them, right? Well, it's got, we deliver a Python image, but it may not be the current, most current Python release or it may be the current Python release and that's not what they want. Yeah, so the intent is we want users to extend from our base image. Now, one of the concerns expressed by a voice in that thread was, hey, that's complicated. And the answer is yes, it is. Container management is non-trivial, but the alternative is also non-trivial and the Jenkins project just doesn't have enough people to maintain everybody's tooling images. You're right. And I'm sure there was always a tutorial somewhere telling us how to extend the base Docker Jenkins images. And if not, we definitely should write one, but I'm sure it already exists and it is well-referenced. I could maybe add a reference to that if I find it in the thread to help the users and we should have a prepared answer for all the users who will face the same kind of issues. That's my belief. That's very good because the Jenkins infrastructure team uses exactly this technique, the extension technique. So we must have an example because they're doing it. And they host their image definitions publicly. So yes, they certainly do exist. I don't know that there's a tutorial that shows how to do it, but I do know that it's there. And actually, this is a candidate for somebody who could ask at DevOps World and they ask me anything session with Damian DuPortal and Erwe LeMire that, hey, how are you managing your Docker images and why? Yes, and the answer is not, you don't want to know that. No, it is not. Good. Any other remarks on that subject? That's it. That's all for me. Thank you. Next one is we Crier Java 11 on newer for Jenkins Core. Yes, congratulations everyone. 2.361.1 has released, is available, and there are C, the change log, the upgrade guide. There was a blog post from CDF on it. There was also a live stream yesterday, so many resources available to help people. Great. That's it for Java 11 for me. Yeah, what about Java 17 then? So, and there it's ongoing. And there have been a few recent reports that are working through, but in general, working quite well, it seems to be working quite well. The Jenkins infrastructure team is planning to put one or more of their machines on JDK 11, on JDK 17. 17, yeah. Yeah. Great. And it is what it is, but it's still working for me on a daily basis, but I have nothing complicated, but I'm happy to work with Java 17 nonetheless. Cool. Next subject is DevOps world in Orlando. We will have a contributor summit presentation, I think it's on the Tuesday. Yes, yes it is. And some people from AWS will tell us about how to use EC2 instances of macOS, to be able to build more easily iOS and macOS applications, I guess. It won't be a long presentation, but I'm sure they will be around the rest of the day, so that we can discuss with them in their booth, for example. Or I think that for the contributor summit, we also have next to that a booth, a Jenkins IO booth, and that we also have a place where we can give some quick talks and so on. So maybe they could also interact with our users there. But anyway, that's a good thing to have news about instances of macOS in EC2, because my experience is that it was kind of difficult and pricey. And I read a few things here and there, let's say that now it's easier and maybe cheaper. So I want to know more about that. Great. And I think that the end of the agenda, whoa, that's what I call an efficient meeting. Super, thanks very much. Thank you, Mark.