 Okay. Welcome to the Jenkins platform special interest group meeting. It's the second of July. Remind everyone that we abide by the Jenkins code of conduct in our meetings. Thanks for joining us. A detail. Great to have you here. Likewise, Mike for you. Thanks very much. Happy to be here. All right. So agenda topics that I had for today. I have open action items, Java 11 as default in our images and marks preliminary document preparation for a JEP. Okay. So that is this place here. Then coordinating proposed Docker changes. We've got a new change coming in that is doing multi arch and faster builds by using Docker build X. Need to review and comment on the poll request. So coordinating proposed Docker changes. That's all that I had Mike or anything you want to add to the agenda. Okay. So quick look at the action items. The JEP for Java 11 is under development now. The JEP for Docker operating system support. I've still got to create sincere apologies way behind the plugin installation manager docs seem to have paused. Sudhakar has not responded to comments, but it's good enough that we may just go ahead and proceed with it because it's significantly more than the existing documentation. I just have to understand and be sure that the things that are in their work. And then Jim Crowley had an item to submit refinements. And as far as I can tell, it's going to be superseded by Tim Giacome's work. Tim's using some of Jim's ideas. And so I think this one will likely close out the next time we meet and just say, hey, let's use Tim's. Any questions or concerns on the action items? No. Okay. So then the next topic then is Java 11. And what I think we ought to do is first look at and review. Be sure, Mike, that I've understood the way we viewed it from the Contributor Summit. I've reviewed the meeting notes and the recording, but want to double check to be sure that I've not misstated something. So what I think we've got is the decision was described here or the preference. Decision is too strong. Sorry, I should be more precise. The proposal was delivered Java 8 based images as an escape hatch and Java make the change to Java 11 in the September LTS release. Whoops, where is my note there? Yeah. So make Java 11 the default in the LTS release and four to six weeks before that in the weekly release and provide as an escape hatch and a JDK8 image that also includes that they could use if they absolutely had to have JDK8. Document it, include it in the upgrade guide, etc. We need to revisit the agent containers and add the same tags there. Does that match, Mike, with what you intended or? It does, I think. So we'd have two explicitly named sets of images, one with the dash JDK8 and one with the dash JDK11 suffix. And the JDK11 would also be the equivalent of the latest tag for just the base. Oh, that's okay. That's a very, you just, you make an important note. Use, and I like your phrasing, explosively named images. So meaning much more detailed name, I think is what you're saying, right? So like it would be something on the order of buster dash, something, something, JDK11 or maybe you can describe further what. I'm basically just, so at least from the JDK perspective, like, if you're looking, you're not sure what image you want to grab, like we have, you know, I definitely want JDK11 or definitely want JDK8 and it's pretty clear from the image name, what I'm going to get. And then I assume by making it to the fault that if you just say, give me the latest Jenkins image, that's more or less going to be a link to the latest JDK11 image. Does that make, right? Yes, okay. And then the simple names are aliases for one of the more detailed names. Latest may point to JDK11 on Debian Buster with adopt open JDK11.0.12. Assuming that's the version that's shipped by that point, because right now we're at 11.0.11. Did I capture that correctly? Okay, great. I don't know if it is important to call out that it's adopt open JDK in the JDK11 image names or if just JDK11 is sufficient. I guess if we haven't really been explicit about which JDK vendor the image is built with in the past, it doesn't probably matter to be that fine today. But on the other hand, like if we're taking the time to change the way we name things, like you can always consider if I don't have enough widespread Docker experience to know what is the typical convention, if any, I would say probably based on my experience was not really a strong convention. Yeah, I've certainly not seen one, and we've got two or three different conventions in the Jenkins images. So if we look at, I was just sampling this morning, so the controller images, the tags look like this. They're pretty short and nondescript in terms of which JDK is installed or anything like that, right? The crucial attributes are not visible in the tag name, but the inbound agent image includes the remoting version number, the JDK version, the JDK and some operating system specific things as well. Then the outbound agent is a mix of that. Some like these include version number, but not much else. Others include version number and operating system. So it feels like this may be a place where we adopt a naming convention across all the images. I mean, I'm always in favor of trying to be self-documenting and consistent and explicit in naming. I know it's often hard to go back and retrofit that at some point. We accumulated enough history out there. Right, but for new images, and certainly we will have new images here or we could add additional tags that describe, hey, this is the JDK version that's inside here and this is the remoting version. So those are two important things, I think, because knowing the remoting, like you have compatibility issues with remoting versions and knowing that one version of remoting is in a particular image is probably useful when you're trying to match it up with what other base image you're going to deploy. Okay, yeah, so it feels like there's a tagging convention here that I need to include in this plan that I hadn't even considered. Okay, insert a proposal here for the image tagging convention that would be used for new images. Great, okay. All right, so anything else in terms of contributor summit concepts? And so the timeline, let's be sure we've got the timeline. So the timeline four to six weeks before September LTS, we change the weekly base images to JDK 11, right? And then September LTS changes LTS base images, LTS base isn't needed just say color images images to JDK 11. Now that's the controller and now the question is how do we handle the agents and I assume the agents transition, do we start the transition of agents prior to LTS or wait for LTS? If we don't do it prior to LTS or we're going to potentially cause people problems that they end up with a mismatched Java 8 and Java 11 agent and controller. Good point. What if I had not considered this for the discussion at the summit but I wonder what if we four to six weeks prior add and you used a great phrase for it, what was your phrase? It was explosively named tags for JDK 11 agent images. So these would be new tags, right? Is that the same four to six weeks prior as the previous bullet point? Yeah, that's what I was trying to say. So through or apparently at the same time essentially. Yeah, I think so. I think that makes sense like rather than sort of dribbling out name changes over like I would introduce the new name change, tagging, scheme, for agents and controllers ahead of the LTS and then that way everything kind of moves together at the same pace. Yeah, okay. So we say hey four to six weeks before the September LTS we switch the weekly controller images to JDK 11 and we add JDK 11 agent tags with more precise names and then at the September LTS we switch, whoops, switch the LTS controller images and switch the agent images to JDK 11. Does that does that seem like a sensible approach? So and certainly I'll bring it up in the mailing list and in the JEP for further discussion. Yeah, I think that makes sense to me. I see lots of work hiding there. Okay, cool. Aditya, any anything you observe here of dangers we have or things where we might be making need to be considering something? I had a question. When are we changing the controller in TSMA just like you're not tagging it with explosive naming? I see that. Oh, good point. So you say when do we add the add, yeah, good one. Shouldn't we do add more add controller tags with more precise names when we start, when we do the weekly and now will we need to, yeah, we'll probably also need, that'll probably be this more precise weekly names and this one will be more precise LTS names and there isn't really a concept on the agents of an LTS. So yeah, does that, does that address your question Aditya? Thanks for asking it. Yeah, yes it does. Okay, very good. Okay, one of my concerns hiding here is our current images, many of our current images are intentionally based on adopt OpenJDK images. Let's use their current name, adoptium images and that's, yeah, let's okay back to where we were, adopt OpenJDK images and that's great, we like that. It's very healthy that they provide the image and we just base on it. For instance, our Debian Buster and Alpine are both that way. However, Debian Bullseye is coming. It's unclear to me if it will be available in time or adopt to provide an image for it. And so my proposal is we decouple this for Bullseye. Just we watch and see Buster remains fully supported. This is Debian 10 Bullseye we consider opportunistic. Any objections to that? Any other topics there? We could look at this Google doc. I've got some, some, the table of contents I think is a good first question of what other things should be included in this document. So I put in goals and current state and desired future state and image tagging convention, changes we need to make to implement it and impact analysis and announcements and documentation. Are there other things, Mike or Aditya, that you would recommend? Oh, this document, this proposal as a Jenkins enhancement proposal should cover these things. Should we have a timeline thing or is that implicit? I mean beyond the desired future state of September 2021. Right. Yeah, maybe that's already enough to just say desired future state is enough of an expression. Can you scroll down? Is there anything in that section at the moment? It's just right now saying, hey, describe here what it should look like. And what I was thinking it would describe is here are the tags. Here's the tagging format we would use. Here is the, so the image tagging convention. Oh, that needs to be a level three head there. Yes, I think that's pretty good. I think that is probably enough of the timeline. Great. As we, maybe for things like the image tagging convention or even just to me, the main paragraph there, if we kind of work backwards from September LTS is approximately going to be this date or whatever. So that means four to six weeks, call it six weeks before that, we should be ready or prepared to start making the weekly name changes, like rolling those out sort of, you know, even if it's just so September, August, July, beginning of August, you know, anywhere we can have point out a milestone, like a key milestone. Maybe, maybe that's what we should, maybe that's what we should call it out is milestones. I like that, that wording as, as just say milestones so that we know if we're on track or not, right, because we've got, there are some crucial date based things like the September, September 2021 LTS freeze or LTS is selection date. So this is the date when the Jenkins based version is selection. And then, then there's the September 2021 LTS release candidate is built. Then there's the September 2021 LTS release is, does that seem sensible, Mike? Yeah, I like that. Okay. All right. Maybe milestones even belong inside the future state. Okay. Anything else? It's still a rough draft. It still needs lots and lots of things in it. I'll continue working on it today and ask for feedback from various people. Any other things on that proposed JEP? Okay, great. Next topic then was Tim Jacome has, has submitted a proposal that uses a parallel build process and could lead us to eventually having multi-architect, multi-architecture Docker images. It also appears to be as much as forex faster than the current build process we're using. And one of the concerns from the security team has been the slow, slow process that we have to build our Docker images today. So for me, this one is, is a, is a marvelous accomplishment. Let me get the, the, a link to the PR embedded here so that others can take a look at it. So feedback is coming in, need to do some, yeah, some further exploring. And we've got this multi-arch builds, which will be superseded by PR 1137. The install plugins.sh is dependent on documentation from Sudakar. And that still needs my review and further comments and corrections. And we, this non-route user, I don't know where, what its current status is. Those were all the topics that I had, anything else that we missed in today's agenda. Okay. Then I think we can call an end to today's session and I'll send you links to the, to, to those documents and look for your feedback. Yeah, thanks, Mike. Thank you, Aditya. Thank you. Everybody has a good weekend. All right. Yes. Enjoy the weekend.