 Welcome, everyone. This is the platform special interest group. It's the 27th of August, 2020. We're recording this session. It will be available on the platform sick play mess agenda review. Adopt open JDK for Docker on Alpine is a topic wanted to give a final status report on that. Then adopt open JDK eight for Docker on TV and incentives. Also, I wanted to add a topic which is the retirement schedule. For Debbie and Debbie and no, no, not they did step in nine in our Docker anyways. And we'll talk that briefly. And plug in installation manager and Docker images. Tim, with you here, would you be okay if we put that as you used to tell us some, give us a brief about it. Great. Okay. And then update center improvements. And that one, Tim, if you're available would also be great to have you you've got much deeper understanding of it than I do and would love to highlight it. Yep. Any other topics we should put on the agenda. Okay, and let's go ahead and go. So adopt open JDK eight for Docker on Alpine is done. Delivered in Jenkins 2.2 35.5 in Jenkins 2.200 believe that that change which is the Alpine 3.12. And adopt open JDK eight you 262. So we were previously previously Alpine 3.9 and eight you 212. And I haven't seen any outrage or serious irritation at that transformation. Alex, have you had anyone complaining to you about breaking something. I actually wonder if how many people are using that. Well, that's a that's a good, that's a good topic for a topic for my action item on a jet to get us the rules for operating system support because we may want to just consider dropping Alpine completely. Good. Okay. All right. Alpine. Don't drop my Alpine. Oh, you use Alpine Tim. Wait, let me share. Maybe we don't. My experience with Alpine was, was not so great. I think we dropped, we dropped Alpine because we use JDK live on. Yeah, now we use, we use the JDK live on tag. Right. Okay. We used to use Alpine. Okay. Well, that's, that's okay. Good to hear that somebody was using it. That's, that's a win. There was a period where it was being shipped or something derived from Alpine was being shipped by cloudies, but I think they found that particularly painful and shifted away. Okay. So adopt open JDK eight for doctor on Debian incentives. So here we've got PR in progress, right Alex. We have a PR for the Debian portion, but we're still just installing for young. Okay. So I guess what we should determine is whether we want to install a specific version of Java. Or we just want to continue to rely on the package manager. Yeah, I thought that I've, at least for me, I like the, I like the specific version of Java from adopt. However, I guess that that may only work for Debian I don't know if adopt is providing a sento space image at all. I don't know if it's provided an image but they may provide an RPM. Okay. I'll look into that. You can assign that to me. Great. Thanks. Okay. Next topic was retirement schedule for Debian nine in our images so this one is not a pressing one right now but Debian has announced, or has stated on their website. And sometime in 2021 will release their next version and the dates they were showing was like March or later. And when they do that their policy is that the old stable becomes unsupported so Debian nine will be unsupported at that time. Okay. And I think we need to have transition either to Debian 10 or to the new version, which will I assume me number Debian 11 bullseye. For me that fits within the operating system support Jeff that I've got to get out. And just the proposal how to manage it it's another another instance of what are the rules we should be applying to decide which operating system to support any other questions there conversation there. I don't know if it's, but it's not specific to this but I know Daniel has voices concerned about the number of images we publish, having to wait for publishing all of those images for security releases. So I'm wondering if you want to do something where we have an official set of images that are like main image of Jenkins publish and then ancillary ones that we do publish but are not like the main support. Yeah, so still leave them in the in the Jenkins CI, but but acknowledge you're not going to claim official support for these. Yeah. More like, but would you envision. I mean it seems though that that was that may still cause Daniel heartache because he'll get people who are badgering him saying I want this security things on this thing that is not officially supported. Yeah, but this is what we'll be to consider adopting JDK does something like that right where. Yeah, I think it's just just speed up the publishing paralyze it. It all takes the same amount of time to publish. Do we currently build them all on Dr Hub at the moment has it. I thought I thought we actually built them all on our own infrastructure because the Docker help build process wasn't doing what we needed. At least back when we were evaluating that is on trust now I. Yes, for the for the official Jenkins repo it's untrusted for that we do. I couldn't find the last time I was looking. Yeah. Those are factors to consider in getting that jet prepared. All right. Anything else on the retirement schedule for operating systems or general operating system support. I do have a PR that switches our main image to buster. When it switches to adopt open JDK, so that would switch the main from stretch. Okay, so that would that would address the specific question on on Debbie and nine. Good. All right. Next topic then plug in installation manager and doctor images. So Tim you want to give us a brief overview. Sorry Tim my timing is especially bad. That was completely unacceptable. That's fine. Yep. So the latest weekly replaces the install plugins study state script with the plugin installation manager CLI which was a GSOC 2019 project and set a number of improvements over the last few months. The biggest new feature is probably being able to automatically update your plugin file with the CLI which saves 20 to 30 minutes of tedious reviewing and finding new versions to just like a script that takes one to two seconds to run. So it's the plugins that text file with the version numbers inside the text file. Yeah. Nice. Yep. And also it also works in the ammo file as well. And it can output it to come up console as well as just like a human readable if you want that. If you just want to see what the new versions are. It's in the latest weekly version only so two dot two five four. And it'll be in the next LTS in a couple of weeks I guess. Maybe we should do an announcement on that list or the user's list. And that I think is is there was a full replacement soon topic that was brought up in the info meeting Tim do you want to do you have any details you want to share on that. I think Daniel Beck was described. One thing so Daniel Beck want to think there's a progress open which makes the install plugins scripts more compliant with the update center. It uses less use the directory structure less than guessing versions. I don't think it's not 100% correct but it's enough that I think Daniel can retire some of the updates into lines. I think it might still rely on I think it's yeah so I think there's a progress that Daniel just wanted merged. It's open against the install plugins script. I don't think it's Daniel I think Alex might have opened the progress. Okay. Just let me put that way. Correct me if I'm wrong Alex. That's correct. It's just kind of a band aid. We definitely want to move to plugin installation manager. The idea Alex and the install plugins change is is a an immediate workaround that would allow Daniel to continue advancing the update center improvements is that the idea and then plugin installation manager will eventually replace installment plugins completely. Yes. Now I don't know how to do the notification thing here how do we how do we get the message out to our doctor image users. I don't know what to do with the notification warning or or even just a hey try. Just. Hey do you want to try the new then the new plugin manager CLI it has automated update support and and there's a bit of tested. Yes. Next generation CLI. Do you think it's enough to add a warning to install plugins that is each. Do you think people actually will see that. I would put it at the beginning and the end. People might see that I mean they probably won't see it at the beginning. That's a good idea. I can take an action item to create a PR. Great. Well, and it feels like this is one where we would we would benefit by some additional notice and additional either a reminder to a blog post or something like it. I can certainly do some social media things if that would help. Yeah, I think the blog post might be good. Just to kind of give an overview of the tool because it can be very useful outside of Docker as well. So as a as a way to get a separate voice doing that Tim, you're about to go on vacation or be okay if I offered the blog post. Try to squeeze it in. I doubt it will be ready before you leave on vacation but I also doubt that if you were to take the action that you would somehow magically do it before you left on vacation that's not going to happen so not going on vacation. Okay, let me put that on. Put that on on there. And I'll review, I'll rely on reviewers to correct me if I say something too bold or not bold enough about eventual obsolescence it certainly won't have any timeline timeline on it, but rather stating that we intend actually maybe this is the place to highlight the update center. This is using HTTPS and should also highlight an invitation to add more mirrors are we at the point where we're ready to recruit more mirrors. Tim what's your sense there is it premature should we wait till you get back before we consider promoting people to become more mirror sites. No, definitely, it's definitely good to promote it more murders the better I'd say. Okay, so I may. I may ping. I may ping Daniel back to see if you'd like to be involved in in contributing to that blog post because it's, I think the HTTP to HTTPS transition is an important thing to highlight for people and this is a good excuse to say hey look. This is, we've gotten smarter about what we're doing with the update center. Okay, anything else on plugin installation manager and Docker images. No. Last topic I had was update center improvements. Tim you want to take that topic. Yeah, sure. We're going to cover the last couple of minutes but it's enabling HTTPS for plugins into end previously mirrors was on HTTP and updates serve them to also serve HTTP links. In some cases, but now updates is always serving HTTPS links, although you can still access it initially on HTTP, which will hopefully remove at some point. You can also go to Java issues with cross protocol and your browser like grades seamlessly HTTP yes but Java won't do it with that a lot of extra code isn't in there currently. So yeah that's one so into end this style, which was gained from switching from mirror brain to merit that all their mirrors support HTTPS and so any new mirrors we need to support it as well. So that was about plugins being available immediately. After release the previously was about an hour to two hours after release, you would quite likely get four or fours, and it'll be impossible to install a plugin. It's still the client plugin got 300,000 instances running it, but for the next two hours it's impossible to install get to basically it's impossible to install possible to start a new Jenkins because it's dependent on by so many things. But so now it's available immediately. We push it to both Azure, which is a full back storage and to OSQ, which is the Oregon State University mirror, and it's available in those two places immediately as part of the updates into push this made possible by Daniel. Adding new features that they seem to have to to just have a new file which includes all the recent releases for the last three hours, and we only sync those on every push. We have one complication we need to keep an eye on is that originally a full back was something called archives.org. And so that's, so we were currently only mirror Jenkins wars and not sure about plugins, but definitely Jenkins war that have been released in the last year. And we include everything on archives.org, but the machine is incredibly slow. And it was okay for war files for people that weren't updating. But there's an issue with mirror bits where it doesn't seem to pick up plugin releases, but just doesn't notice something in the mirror for an hour and a half. It's got two stages where it does a local refresh and sync where it seems to take about 15 minutes to notice that the plugins on mirror bits, and then we'll hash it and look to see if it's available anywhere. And it does, it does regular askings, full askings of every mirror to see whether the versions have changed. Those seem to happen roughly every half hour or so, but it seems to take at least an hour to an hour and a half before it notices that it's on mirrors, even though it's there pretty much immediately. So initially we're using our own bandwidth, which is something we're really doing to fix. Whether it's upgrading archives, whether it's fixing mirror bits, well, improving mirror bits to allow us to tell us that a specific thing has just been updated. So with mirror brain that did have that capability. So there was a specific even be scan and you can pass the file path. And so mirror brain you could. So that was what was done during security releases. So security releases didn't have that issue. And so it allows an immediate sync. The mirror bits is missing that feature. So possibly we could contribute it. I asked my save I didn't get response and I haven't had time to raise an issue. Now in terms of one of my worries was Azure bandwidth cost. Should I just be looking at the Azure cost estimation console to just to be monitoring. Hey, have we gone off the off the scales with bandwidth cost. Yeah, probably cost management is the best place. I mean, I'm looking at directly at the storage account which shows the amount of bandwidth. And I was calculating a place of pricing. We just got a quick look and cost analysis for us. Now I saw also that you've done an update to refresh the gip data has that actually been applied or is that still a pull request. That's, so that's been applied. I raised the issue on Olivia. So it's, it's in Olivia's get hub account is the mirror bits document we used. I raised an issue there that we never updated it. And Olivia decided to reply. Oh, good. Okay. She told me that we should just run it regularly from infra Jenkins and update the image, but I think I found a better way. I don't really want to have to meant to manually approve and merge the answer for it all the time for the waste of our time. And I found a geo IP update Docker image which is an official image they publish, which will just, and you can pass it an argument was how often you want to refresh. And it will just, it just updates it for you. I added it to another container and mounted the gip data in both containers. And so it runs every 24 hours now. And at least it's up. It's updated at least once let's say that. So previously it was January was when it was last built. And the last modified date is now August. Excellent. Thank you. And that was so someone, someone raised an issue and I see saying that I'm the data. Well, they're us. They said they were going to a mirror that shouldn't be in that the geography data used to be wrong. And it was fixed at some point. So that led us to oh yeah. I assume that it was being updated by corn that wasn't great. That is that is excellent. Thank you very, very much for that. Any other questions from anyone on the update center improvements. I was, I was delighted to have pushed a new version of the get get plug in and had no complaints about being unavailable. And delighted when I updated a plug in yesterday morning, and it only released 51 minutes earlier and I saw no, no problem there either. So, very nice. Thanks. Any other topics we need to discuss today that covers it then recording will be posted. I'll update the action item list after the meeting to be sure that it records action items we added to the session. Thanks very much. Vivek, was there anything that you had topic that you needed to add while you were here. Thanks everybody recording will be posted.