 Welcome to the Jenkins platform special interest group meeting. It's the 11th of March 2022 items on the agenda include Docker agent support additions. Linux packages using system D require Java 11 Linux operating system support policy and a proposal to change the exit lifecycle on Docker images. And any other addition any other topics so Mike I think your topic would fit under the Docker agent support additions question, you would I think wanted to talk about Windows server support versions etc. So I'm interested in the system being so the system, I've been there. Okay, great. I think the a bunch of images are not using that. Understood something correctly yesterday for the Debian packages. So let's, well let's let's certainly go through and we can certainly discuss it. Absolutely. I'm not aware of any open actual I take it back we've got one open action item that still needs to carry forward it's a documentation task for the SIG that I haven't completed yet the plugin installation manager docs still need to be updated with more use cases etc. Alright, so then on Docker agent support additions under consideration run over rock done has started the process of proposing 32 bit arm support in the Docker images. His was I think first interest was on an agent. And then consider later elsewhere. So he's doing the work I believe in the Docker SSH agents repository. In general, our pattern has been 32 bit is considered an optional platform for us as part of the platform the operating system support policy draft. It's a level two, whereas 64 bit AMD 64 and arm 64 and system three 390 are all considered double one. We do have images for 64 bit platforms. We do. Yeah, so we provide Docker images for for here that's let's actually go to hub.docker.com so we can look at them. The easiest way to see that is to actually go look to see how it's presented. So if we look here at Jenkins sluggish okay tags. And if we look at the most let's look at the most recent LTS. And here we see, and let's make it big enough so human beings can read it AMD 64. So AMD 64 arm 64 and system 390 are all provided in those in those images. Did that answer your question Mike. It totally did. So this is this is special thanks to Tim Jacob and Damian Deportal Tim found how to use Docker build X bake to let us build multi platform binaries on AMD 64. And then we have automated tests that were provided by a person at IBM that tests these things regularly and make sure that they're still well behaved on the actual platforms. And it's actually quite a quite a cool story. Yeah, it is. So then the next question I think was, Hey, which windows images are supported and what versions of windows are supported. And for that, I think we have to go to the Docker repository itself on GitHub. Here, if I remember correctly, if we look for the build script that constructs the images, I believe it is. Oh dear how embarrassing well let's start to make no make file wouldn't be windows so the on there should be a dot PS or dot PS one script. Oh, there it is. Yes, thank you. Very good. All right. So this one should show us which versions are supported. And if we look for LTSC. Yes. How about 20, let's see 1809. And that's not telling me specifically the version number we're using. So we may actually have to go to the job definition itself on the Jenkins file just a minute let's see. So in the Jenkins file. It says run make dot PS one. And here's the definition for Linux so it really must be that the labels are defined the inside make dot PS one so let's go back here and let's take a look at windows. Here we go. Okay. So, it's we're providing currently an image for Windows server core. Maybe if it's not too much trouble could you just give me a overview of what is LTSC. What is the difference between that and this 1809. Oh, you bet. Absolutely. Yeah, very good. Okay, so what is Windows server. Yeah, that's a really good question. LTSC. So here's their, here's their, their description and, and it's the best description I've recognized. Oh no, let's not use let's use Microsoft's. So they've got a concept of a long term servicing channel. Right, exactly. So this is the every six months. And the long term servicing channel is every two to three years. So let me put a link into that so what is LTSC. This one. Good question, because so there it is what it's saying is. LTSC is released every two to three years, and I think the 2018 was their most recent LTS. And, and they, that's, that's this 18 is this, and then the semi annual is the 1809 or 2009 or 2103 are all semi annual channel numbers. So yeah, does, does that, does that answer the initial question of hey what's LTSC. Okay, and then my understanding was sorry did you have other questions Mike. So my understanding was that if we look at the tags here. This 1809. And it's eight months ago so that this one is the current version, but 2019. I'm a little surprised at that naming Mike and I'm not sure that I can explain the naming 2019 so 2019 must be the base windows server core. Windows server core. Is there a, like a policy for platform that we only do images for the LTSC channel or the. There is that's we don't know the thing I'm trying to have a little better understanding of this. Yeah, good question so the, the, the, the message there is that we intentionally want LTSC, and we don't attempt to track the semi annual channel. So, so LTSC is the preferred channel is the channel we, we track. We do not track the semi annual channel. And now, but if I remember correctly 1809 was matched with an LTSC and so that's why it stayed there, but windows server core 2019. Okay, so 1809 coincided with with an LTS server right here we go let's get this one I think this is the place where we can. Okay, windows server. Yes, here we go. So LTSC 2019 was the previous is the previous and apparently they've just not long ago done LTSC 2022 and we haven't yet had a pull request to update to LTSC 2022. So, no pull request yet update to LTSC 2022 and put that link in so that we've got it to track it. Okay. Yeah, that makes sense I was because I was a little confused by the 1809 versus LTSC's just because the naming convention for me off. Exactly see that we're 1809 is a semi annual channel name right that's 2018, the ninth month, whereas 2019 is LTSC naming. But yeah that the similar it's they're both four digit they didn't have the decency to put a dash or a dot between things so yeah it's it's plenty confusing. Okay, so so the now I've not seen active requests for LTSC 2022 support other than a brief mention by Ben Rich. So for the moment, I assume the plan is to continue with LTSC 2019 until there is more demand for LTSC 22. Does that work okay for you. Yes. So we have some customers who have been asking about why we don't support that because they would like to and are updating their windows infrastructure. Okay, so so there are there are users that you've got you've got users that are interested in LTSC 2022. So that question from Ben Rich originates. Got it. Alright, so, so in that case would it be an ad LTSC 2022 and continue using continue providing 2020 2019. Another question I don't know enough to say, if we didn't continue to support 2019 if that would leave some people in a lurch because don't know if it's the sort of situation where it's backward it's compatible sort of sounds like. And it definitely is not that part. So I would guess 2019 will continue to stick around for the rest of its natural support life for Microsoft in ways. Yeah, and so for there's a last time I had had dug into this, there is a strong coupling between these LTSC numbers and the Docker image that you can actually use there if you don't have it exactly matched it, it may not run. So they got a ready to just straight shut you down. Oh, it does. Okay, I believe, but that's my understanding here is that they, they need to be matched for the functionality to work like you want to do. Okay, so, so right now the preference. And this is purely from a build side perspective with preferences to do only one windows image because the windows build process is critical path in terms of timing. Due to slow, slow windows builds and the, you can imagine that the windows images are dramatically larger than the Linux images and the windows machines are. Okay, only comparable performance. So right now, unless there's something that persuades us differently will tend to stay with LTSC 2019 keep us informed and or submit a poll request if you get to that point where you say hey we really want LTSC 2022. It's a, it's a reasonable thing to say let's get to the newest. It just will require us to do some infrastructure updates to Jenkins infra in order to use LTSC 2022 images to build it. If I will definitely keep you a rise of any movement or updates on that topic. Great. Any, any other topics related to Docker agent support. That covers I have a much clearer picture now in my head. Great. All right, so let's take next topic then of Linux packages use system D instead of system five in it so Darren Pope, and I did a, did a live stream yesterday that highlights the different changes in system D and system 3.332.1 new features, including system D. So the, the nice city there is. It's got about 20 or 30 minutes in it now we were able to see that and I've confirmed that it's running on gabion Ubuntu red hat. So, so we're pretty confident that it's working as expected. There are some there there have been one or two bug reports, there have been a few bug reports let's just say it that way on specific details, and we need some need documentation improvements for some of those details so one of them is, for instance, that now we can use reserved ports like port 80 or port 443 directly thanks to system D. But there isn't any instructions specifically in the documentation about how you make that change it's a pretty simple change, but you have to read configuration files to make it so how to use port 80 or port 443. And those are, I think they're, they're interesting and useful because it would allow a Jenkins user conceivably to run an SSL encrypted Jenkins directly without having to use reverse proxy. But we didn't have system D support yet in the Debian packages. That that maybe on the cloud B side, I wonder if that's, that's what you're seeing. That's fine. Yeah, so the down at cloud B. I guess there's another thing there's a documentation update needed. Another thing that I remind reminded on needed on PKG Jenkins.io there's a web page that is available the official docs have it, but the PKG distribution site does not. Yeah, so and, and this includes a this change includes a migrator that reads the old configuration settings and copies them into a new configuration. Basically, it'll help you shift your configuration from system five to system D. Exactly. It does exactly that and, and thus far we've had had no reports of failures there, but we've had some subtleties. HTTP port was a subtle bug report we received, and it's got a fix in that's been proposed now and then there was one other. I don't know what the specific details but but we're expecting more things like that where some surprise happens and and users have to make a change that it's really elegant that now we can make configuration edits on any platform, use the same commands. Yeah, or any Linux Linux install use the same commands. It does does make it easier to administer the trade off there is it also moves the log location to a system D standard location. And it places the war file in a system in a standard location. Likely some bumps along the way of people realizing Oh, this is changed. And hey, they've been running the old way for as much as 14 years. So, so this, this is a non trivial change in that it's changing something that's got a long history. Any other questions there Mike or topics that we should discuss. There is, there is one more item which is that Darren and Mark will do one or two more live streams specifically focused on system D. Because we're expecting lots of lots of interest on how do you use this thing well, how do you help it, let it help you. All right. Next topic is also here to my heart. Oh well good well so let's talk that one because this one I need to include some links to the Jenkins JIRA so I'm going to, I'm going to bring in a Jenkins JIRA page onto my list of tabs just a minute, so that we can stare at this together. Java 11. Okay, good. So, here we go let's look at this. So what Basel has done Basel crow has done is he has created and named a sequence series of epics for us. And what let's start with this one as our first link. It's required Java 11 and that link identifies many of the items of work that need to be done so if we take a look here at the things that, for instance, prevent the windows installer from using Java eight. Once we've got it, we should we need to be sure we can compile stapler with Java 11. We need to be able to compile them even HPI plug in with Java 11. Those kinds of things are identified here. Some of the others here I would consider optional. But, for instance, we've got to be able to build plugins with Java 11 naturally. These kinds of things file leak detector, the work is has just barely finished on that one so it looks good. Is this is this the kind of thing that you were looking for my kind of thing. This is excellent because you're very interested in the progress and timing of the requirement to become a reality. Excellent. Okay, so. And, and now as part of this effort, what what Basel has also done has created some downstream epics for the eventual transition to Java 17 that may be several years away yet, but we've got a placeholder to capture that. And we know, oh, hey, when when the Java 17 transition happens will will use the same technique. And yeah, Basel's done really an exceptional job of capturing these things and yes we've got, we've got some of the things that are that are actually this one for instance 59 910 that Jesse Glick flagged as maybe a blocker and we really need to end it before we turn off Java 8. Yeah, I was looking into that as well actually. This morning is that. And that can potentially impact people who are already moving to use the Java 11 with the Docker images of Java 11 by default now for instance and so this is something people could be hitting out in the wild. Exactly, right. I mean, this one is one that we, we, it appears we probably already have some users affected by it because we've already, we already started last year this transition to Java 11. And, and so it's, you're right, it's a risk and we've got to understand it. Good. Thank you. Anything else on the required Java 11 topic. So that's kind of covered the questions I was curious about some. All right. Thank you for pointing me to that epic as well. Yeah, that Basel has really done an excellent job there so the next topic then was the Linux operating system support policy back in February I had proposed a poll request. We're doing the windows operating system support policy that we have on Jenkins.io to propose a whoops to propose a Linux support policy. And if we look here, we should be able to go find well let's look at the page. So it describes three levels, level one supported level to patches considered and level three unsupported. Level two is, hey, we'll take it most anything. The only reason something is on level three is if the vendor of the Linux operating system no longer supports that version. So we will not accept patches to support Ubuntu 14. Sorry, it's just off the list, level two or platforms that we don't have the capacity to test. Level five, for instance, the 32 bit architectures, we just aren't going to spend the effort to construct testing environments for those. And pretty much everything else is here. If we've got access to it to test it. Most of them are already actually running automated tests in those environments. And the advantage is I need to get the right approvals in order to be allowed to merge it and I think I just got Basel's approval. But I'd like to have either Tim or Oleg give approval so that I can confidently merge. I mean, I, it makes sense. And I think, you know, having them follow the same sort of model terminology and everything is going to make life easier for everybody. Exactly. Yeah, good point. So it's and there was a developer mailing list. There is a developer mailing list discussion on it and people can read it. It's, it's, it's been quiet. And so I'm trying to bring it back to life. The first one was exit life cycle change and this is one mic where where it may be good for you and I both to be thinking about this one. What's what the proposal is is that in the Jenkins Docker GitHub repository, Basel had submitted a pull request suggesting to use a different life cycle so the life cycle is what besides a restart and on Linux, for instance, we have a specific Linux life cycle that on restart does certain things. And in Docker, we by default use the Linux life cycle, which means we invoke relatively complicated Linux code before we shut down the Java process. And Basel's point here is, look, we don't need to, we don't need to do that because Docker will handle restarting the process for us. We don't have to do all this exotic Linux specific stuff if we just say, we're going to do a restart all restart always and let Docker do the work. However, I noticed as I was testing it, that it had a surprise in that when I do a Docker run. It will stay in the foreground by default until I restart Jenkins and then the Docker run process appears to exit but the Docker process that is Jenkins continues. So it's a minor a minor compatibility change that I found interesting and we may need to document the that kind of. I don't know anybody that actually runs Docker in the foreground and expects it to stay there long term right that's that's really odd. So that's the and do you have any insights or any comments that you wanted to share in terms of exit lifecycle I haven't. I haven't explored further. I'm only superficially familiar with it. But anything that reduces complexity and standardizes things across platforms and 100% in support of so in my understanding of the benefit of that is correct. I think it's, it's definitely worth pursuing. Good. Okay, great. What is, what is tiny, tiny. So, so this is, this is one that I haven't even proposed yet that in a in the Docker world. Docker has the ability to. So there is there needs to be a process Reaper for for processes started by Docker that then start sub processes. And, and in our case we use tiny which is a small version of in it. And this tiny that we use is actually now been sub been sort of replaced if you will by Docker creating that as a standard part of it. It's, it's packaging, so that we could instead of bundling our own copy, we could use theirs. So, and yeah here's a good one. Ah, yes. So, the internal services in a container talks about in it. And if you run it with the in it option to run the container it creates a tiny in it process and reaps the processes for you when the container exits. So, so the idea there is, they've got this capability now and we're not using the capability they provide. We could use the capability they provide, at least we could evaluate it. Let me put a link to this into that because great if this one still needs more evaluation and needs a poll request for discussion so there's nothing else to say on it except that pay a poll request needs to be opened and I'll take a look at her others will take a look at it as time allows. That covers all the topics we had for today Mike anything else that you wanted to be sure we discuss. I know you covered everything. I want to talk about. All right, thanks, we'll go ahead and end for today recording should be available and posted in about 24 hours. Thanks.