 Welcome to the Jenkins Platform Special Interest Group. It's July 16, 2021. Remind everyone that we're part of, that we abide by the Jenkins Code of Conduct during our sessions. So agenda items, I had open action items. Java 11 is default in our image and pending docker changes. Aditya, are there any things that you would like to add to the agenda? No. Okay, all right. Well, let's go ahead and review the items we've got then. So I have the action items still to open a Jenkins enhancement proposal for Java 11 is the standard docker image. See the Google doc for the first draft. I've made a lot of progress, spent many hours staring at it and trying to understand what exact steps should be described and why. So I'll continue work on that today. Then we've got a docker operating system support JEP and platform selection rules. And I'm delighted to say that the user SAPR has created the code owner's file that implements the idea. So we've already got a beginning and SAPR has proposed self as maintainer whoops, of the Alma Linux docker image which is a Red Hat Linux clone somewhat like CentOS. We had the additional, any question there Aditya? No, no questions. Okay. Then we had plugin installation manager documentation that's in progress. We need that so we can merge the replacement of install plugins.sh. And we had a topic on refinements for parallelization. Those have been closed in favor of Tim's Tim Jacome's work for on docker bake. And I'm really very pleased with docker bake as a way of doing it. It's working on the controller right now. We've been delivering with it for about a week. The most recent weekly was delivered using it and it builds faster. And there are additional improvements in test performance that are pending from Damian to portal. So nice positive. So this docker bake is the process which brings docker image parallel to it. That is the same full request. That is correct. Exactly. Yes, you're right. It does parallel image building and it does multi-architecture image building. So AMD64, ARM64, PPC64 and S390X are the initial set that we envision using. Yeah. Wonderful. Okay. Any other topics or questions on open action items? None so much. Okay. So then let's, I wanted to take just a brief minute and look at the Java 11 as Jenkins default JDK table of contents here because it highlights some of the things that need work. And we'll need our attention. So big portion of the work right now has been on specification on how do we tag? What should we do with new, which tags should we add? Which tags should we modify? What should the tagging convention be? And the current proposal is to honor the existing tagging conventions in the four different repositories that we have. So we have the controller, image is one repository. We have an agent image that is the base for inbound agent and the base for outbound agent. And so those images have, or those Docker, those GitHub repositories each have their own tagging format based on the needs of that image. And my proposal here is let's continue that format and then we'll move on to the next slide. That format, then we've got a number of issues to review and now there's a talk. There are different topics here that are standard parts of the Jenkins enhancement proposal process that remind us we need to think about compatibility and about testing and about additional infrastructure, if any. Working prototypes, et cetera. So these will all be addressed and I expect to have this submitted before we meet again in two weeks. All right, document needs review and seeking additional comments, right? Would love to have any reviewers possible. It's my thinking right now based on what we had discussed in the Jenkins contributor summit and in the Jenkins contributor summit we talked about adding new tags for Java 8 and making the existing tags that don't specify a version number prefer use Java 11 instead of Java 8. And so this goes through the exercise of trying to enumerate those. This tag would become this content, this tag would become this content. And there are a lot of changes across many different repositories. Okay, and this naming convention is the one that will follow the explosive naming system that was discussed two weeks ago. Right, right. So it does adds the concept of explosive naming of Docker images so that we have more details, more details in the base Docker image, in the Docker image tags. So that if someone wants, so tags like it might be buster-jdk11-2.289.3 or .2- let's see, what are some other parts? Well, so that would probably be enough to specify it but that gives operating system, Java version and Jenkins version. And I actually put together a worksheet trying to enumerate the tagging, where is my worksheet link? Just a minute. Here it is, the image tagging conventions worksheet is an attempt for me to express the existing tags and what semantics they have already inside, explicitly inside the tag name like Jenkins version or variant or JDK and which things are implicit in them. And this attempt, I tried to do it for controller, for agent, for inbound agent and for SSH outbound agent. So the idea is making sure that we know which attribute should be in an explosive name and which we should drop. So for instance, I'm prone right now to drop virtual machine because we've stopped delivering open J9 images even to the evaluation location. And therefore virtual machine, as far as I can tell, is a constant now. It will always be hotspot. And the operating system is nowhere used and JDK, Java can be run on every operating system. So does that make sense to remove it? Well, operating system is quite important because the Docker image is actually used. Oh, it has the same, oh yeah, yeah, sorry, sorry, yeah. Good question, a very good question because in this case, it's actually at the utilities provided with the operating system are coming from Alpine. Now, when Docker runs it, it actually runs it on top of the kernel that you're currently using, right? So it doesn't actually come with an Alpine kernel, it just comes with Alpine user land utilities like Git and Git LFS and make those kinds of utilities are all provided by Alpine. And so for me, I think it's quite important that we have, oh, that's wrong, I think that's CentOS 8. Yeah, okay, living and learning. Any other questions there, Aditya? Yeah, just one, when you were writing Buster.JDK this whole thing, so when you were, am I out of it? Yes, you sure are, go ahead. Okay, so you were writing this, right? Buster, JDK 11 and the Jenkins version. So my question was, does agent controller, the inbound and outbound controllers, they have a different naming system or we can add another tag like hyphen agent or hyphen inbound, hyphen outbound to make sure that it is present there itself? So they have a very different naming convention and I think it's in our, to our benefit that they have that different, that they've used that different naming convention. So if we look at, let's look at the, a commonly used when the inbound agent, it has a version number on its leftmost field that is the version number of Jenkins remoting that is used. So 4.9 here is not a Jenkins version. It's the Jenkins remoting library version on which this is based. Okay, yeah, then it makes sense that we'll keep it this way and not add another tag because the convention, writing convention will give us which kind of Docker image it is. Right, exactly. Well, and because the inbound agent image is in a different repository and therefore has a different image base name, it becomes very clear that it is that other image form. So likewise here we see with outbound agents, the version number here is a version number that is assigned based on the contents of the image. And so 2.1.0 is the older image and 3.0.0 is the newer image. Okay. But again, those are both independent versions, independent numbers compared to the Jenkins version. And that's, for me, I think that's correct because these agents can be used with any Jenkins controller version that supports their version of remoting, which means almost all supported Jenkins controller versions. Okay, yeah, I did not know that. So that's why I had the question. Yeah, well, and this was quite a learning experience for me to assemble these. Oh, those tags are important. People use those, they rely on those. Now, what should the meaning of those tags be when we make this transition? So 2.301-Slim, for instance, will become a JDK-11 image, although right now it's JDK-8. Those kinds of, detecting those kinds of transitions are important. Very good. Very good. All right, any other questions on JDK-11 as default in all our images? Oh, I've got one item. Yeah, I have no questions. Okay, so the Jenkins LTS baseline version is not yet selected for September. And Mark started the thread, the developer mailing list thread to get the answer. Let me put a link to that in here. So this one, and right now the choices are 2.300, 2.301, 2.302, and each have strengths and weaknesses in terms of, would we choose that one or choose another one? Actually that's not helping. Hey, anything else on Java 11? No. All right, next topic then was pending Docker changes. And here we've got a number of changes that need code review and need people to experiment with them. So if we look at the Docker pull requests for the controller right now, we've got add a multi-arch build, which is this is the work that Tim Jacome has started. We've got pending enable the parallel flag in bats that Tim has started. And that is improving right now. Damien is dealing with weather emergencies in his home neighborhood, in his home area. So, but he's made very good progress and the user Saper has also been a great help in some Marcin Schejlak has also been a great help on investigating, making sure that this runs in multiple platforms and multiple environments. Okay, and I think this is the pull request that actually Damien was asking me if I have Docker installed on my Windows machine to build and test. Oh, very good. Very, very good. Yeah, I have not done anything to check Windows. So that would be a great help if you could check Windows. Yes, unfortunately, I did not have Docker installed. So I will do it. But yeah, it might take some time. I usually use Ubuntu for my Docker. It's easier in Linux. Yes, it was first written for Linux. So that's not a shock that it's easier in Linux. Yes, absolutely. All right, so the things, are there other topics there that you would like to discuss Aditya? Not a topic really, but I had a question in general about the platform thing. So I actually wanted to know what is the aim of this special interest group and how can I be more active here and participate? So after attending the infrasigs, I actually know what does infrasig do and how can I help? So similarly is, yeah, I would like to know about platform. Very good, yeah. So let's look at how it describes itself. So this sig is a place for platform support discussions, including Java, operating systems, architectures, Docker, packaging and web containers. So platform support policies, platform support efforts and more. So what we've done, and if we look at the Jenkins roadmap, we can see. So I'm sorry to interrupt, Mark, just one question over there. Then you see platform, which platform are we talking about here? Or is it just a platform is like a variable here for the user's platform? So that is my question. You described it precisely. A platform in this case is, a platform is just a description of some component that is typically beneath or strongly connected to Jenkins. So Java is a platform component, whether it's Java 8 or Java 11 or Java 17, the operating system, whether it's OpenBSD or FreeBSD or Debian Linux or Mac OS or Windows, it's a part of the platform sig. Architectures, so risk five, ARM64, AMD64, PowerPC64 are all interesting architectures. Docker, well, you know Docker images. And so did that address your question Aditya? Yes, yes. Now I have a better understanding of what does the platform signify over here. So initially by the name platform, I thought it was something like related to Jenkins.io or some other platform like CI or Jenkins.io. So that, usually we call those dashboards as platforms, right? So, and in Cloud Native, we have a platform as a service. So that got me even more confused that, okay, which platform is this talking about? Understood, very good question. Yeah, so in this case, it's using platform to describe something on which, something on which Jenkins strongly depends. And that could be the Java side, the operating system that it's running on, the Docker image, those are all platform related things. Not clear. Great, excellent, thank you. Very good, all right. So, and I'm just gonna paste a link to this page because I think that helps remind us. Now, in terms of, I like to look at the roadmap periodically to remind myself what's happening in platform in the roadmap. So if we search here for platform, whoops, it helps if I spell it correctly. Here we go. So Jenkins on cloud platforms has these items, right? Kubernetes operator, Jenkins file runner, cloud events. Kubernetes, more pluggable build results, pluggable storage types, et cetera. Those are cloud platform things. And then if we look at packaging and platform support, you'll see Docker images for Windows, Windows installer done, Windows support policy, Docker images for system 390 for PowerPC, OpenJ9, I think actually that's a good one we now need to remove. Let me put a note on that. Mark to remove OpenJ9 image from the Jenkins roadmap because we're not going to do that when we've pulled back from it and we'll just use hotspot images. AdoptOpenJDK is actually nicely in progress and ARM64, et cetera. So these are all parts of the roadmap and each of these links is actually clickable and should take us to a page that highlights what the plans are and what the current progress is. Oh, that's really helpful. Okay, so roadmap and let me put that link in there as well because that way people can find, hey, here's where we're going. So and I need to give myself an action item. Any other topics that you'd like to bring? None right now, I'm not clear, happy for today. All right, well, thank you very much Aditya. Let's go ahead and end the session for today. I'll post the recording later. Okay, thank you so much. Thank you very much, talked to you in two weeks. Yes.