 Welcome, everyone. This is the Jenkins Platform Special Interest Group, 15th of January 2021. Happy New Year. Here are the items that I had on the agenda, or here's the agenda. Windows Docker images, Docker image build success, and the JEP platform proposal. What other topics do we need to put on? So, Alex, is there, you've got a PR right now for Docker image build rework. Is that something you'd like to discuss here? Yes, that's on the Docker agent. We could talk about it. Okay, all right, great. Gareth, were there any topics that you needed to be sure that we discussed here? I've got one arm increase, improving our arm support that I'd like to put on the list. No, I mean, no real topics for me. I think for the Windows Docker images, I think that's pretty much done, as far as I'm aware. There are some questions from Daniel about the use of the Jenkins for eval. I don't, I'm not sure. I'm not sure what his suggestion is actually. I think he, I think what his concern is, is we consider Jenkins for eval to be a, like, what is the word, experimental. So he's saying, why are we publishing something that's pulled from that into a, an official image in the Jenkins org. So, I think a way we could, well, we can talk about it when we get there, but. Right. Yeah, so, so that's a good topic on the Windows Docker images. Anything else. Kara, were there any, any particular concerns for you that we needed to put on to the agenda today? No, no, no. All right, then let's, let's go ahead and run the meeting. So we like to review open action items first. I still have the open jet. I am so proud that I finally created the Google doc, but I haven't touched it in a month with the holidays. So I promise that I will get back to this and, and go with our further discussions. The problem with the challenge here is that Debian Buster is or Debian, which one is it Debian nine is coming to end of life is reaching end of life and is already off support in at least some descriptions. But our images are based on it. So we've, we've already got that challenge and this JEP is a good excuse to drive forward to make those changes. Any concerns or topics there. Okay, next centos options for adopt open JDK. Alex. Yeah, so I created a PR. I think it's linked there. It just needs review. I'll, Olivier has reviewed it. But I don't know if we want any more reviews. And we had a question as to whether we needed to communicate that to users or not. So that was kind of where we're at. I don't know if we need to if it, if it's the you know the same. If it functions the same, do we necessarily need to make a big deal out of it? I don't know. Right. Well, and we fundamentally don't have a change log for for those. I mean, we're typically not tagging our repositories when we deliver a new Docker image right so there isn't really a place for us to document a change log. Right. So maybe that's something we should change and find a way to document. Okay, great. And we do have a way of doing that and some of like the Docker agent and other places so maybe we can reuse what we're doing there which is just using GitHub releases. But we just have to figure out because we have so many different images and so forth how do we want to do that. Right. Okay, thanks. Thanks. Okay. Anything else on the on the Sentos options? Not for me. Okay, plugin installation manager is is still growing in its adoption and its usage. We're now using it in the documentation. I like the idea Alex that you had suggested earlier of a shim to allow install plugins that sh to continue to exist as a script, but just have it called plugin installation manager. I started on something like that. I can create a PR from that so I was just running the same tests that we had previously for the install plugins but with the shim to make sure that it function the same way according to what it was so. I can probably maybe have a PR for that next week. Okay, that's that's very encouraging. Okay, so if it were, if we were able to do it with the shim, I think I agree with you that it may not need a post it's just, yes, this is the new implementation of plugin installation manager. And maybe we can put out a on the developer list or something once we have like builds going to Jenkins for eval or something or push some images to Jenkins for eval and say hey can you guys test this in your workflows just to make sure there's no corner cases that we don't have covered in our tests. Now, and is there a facility in the image that we could deliver some well, good good so some sort of a pre release. You get feedback. Excellent. Okay. All right, anything else on the plugin installation manager. The next topic then was multi arch CI or multi arch Alex, I'm not nearly up to date on that one as much as I should be anything you want to share there I know Jim is is off on other projects right now at IBM so he's not available for immediate work. Right. Yeah, I think. So, I mean I kind of reviewed what he, what he did and it seems fine, but we also need to figure out how it, how it needs to fit in with like any Jenkins file changes, and things like that so that it actually gets built uses the correct agents for the different architectures, all the, you know, all the images getting tagged correctly that sort of stuff so. I don't know, I might set up like a test instance or something and locally and run through through some of the flows have it pushed to my just my repository area on Docker hub. Just to see how things work. Okay, so that I like that that's that makes sense. That that how do we how do we stage tests, or how do we stage development is interesting also for the Jenkins core releases particular security releases where Olivier is wanting to move more and more towards staged builds as a, as a standard process. We certainly don't stage Docker builds right now right our Docker builds are, we build it and it goes it's published immediately. Right. Okay. Okay, on that on that multi arch stuff is that just building for multiple architectures are actually using like Docker multi arch support. So we have, well we have a an S390 X and a power PC agent that have been donated by I think IBM. Right. And so there is. There are people who want, you know, S390 X power PC and and arm agent images. So it's building and releasing those images. We've done it in the past with QMU, but it provided some challenges in terms of performance and actual functionality once the image was actually being used, which is why we wanted to go to using actual physical agents for those architectures. And we also, we do have arm on the AWS arm 64 agents on AWS so we've, we have physical agents so we can use for all those architectures now. So that's that's still pushing it's pushing multiple images, like an image for each architecture. Correct. So the same tag. Yeah, just different architecture for the, for that image. There is a concept isn't there in in Docker of a single image that is multiple architecture or if I misunderstood that. So it deals with manifests and things like that I'm not entirely up to speed on that but you have to push it like a manifest. And I think that Jim's changes do that. They deal with the manifest and, and so forth. There's just like multiple layers, like a layer for each architect, each architecture. Oh, and that makes sense. Yeah. So when you reference it you just reference whatever, you know, like a Jenkins LTS, and if you're on arm, you would get the arm version. You don't have to explicitly say I want the arm version. Okay, so and Alex, your observation is, as far as you can tell Jim's Jim's pull request is proposing to use multi arch that way so it would be that really would be published publishing an image for all architectures that is a single image but with multiple layers with multiple with layers that are platform specific. My understanding is that it's using manifests to do something similar. I don't know the underlying implementation but like the manifest is basically a generic definition of the image, which then has what architectures are supported for that image. And so, but that's my understanding. I'm not, by any means, any sort of expert on the multi arch stuff but that's my understanding of what I've seen. Great. All right, and that may be one where Gareth your understanding of might be benefited by we get get some benefit by having you review that pull request so that's something that we're, I've got a PR that's on top of Damien's PR actually for the changes for the Jenkins info pipeline library to add in multi arch support for that. So it's a minute where sort of actively testing out seeing how we can do that. Great. Okay, so so there are other places where you're looking at going multi arch. I'm, I'm interested from a from a Jenkins infrastructure I'm interested because Amazon offers lower cost compute from arm now than they do from from MD 64. So there's some some interest for me and lower potentially lowering infra costs by considering putting some of our images into arm, put it some of our workload on the arm rather than being on on Intel. Apple, a bit of a spanner in the works as well with the new stuff. Another example and one is is a good example of that for desktop for laptop. Everyone's having to update. Right. Okay, anything else on the multi arch Docker question. All right, next topic then Docker images for LTSC 2019 Gareth. Yes, so I think to the windows the main, the main images are all being published and built. And so are the agents all of those pills are merged. There is yeah there was an outstanding question from Daniel around using to the adopt open JDK images that aren't yet available. We were publishing publishing them under the Jenkins free vow with the idea that we'd swap them out when I think it was Alex is your PR was merged. But I'm guessing that the, when we're publishing the agent images on top of those are actually pushing those to Jenkins. I think is that is that the way the confusion is lying or is that where Daniel's question is coming from. Yeah, I think so. Yeah, because the parent image effectively becomes. Yeah, you have a Jenkins image depending on Jenkins for a valid. So we could I mean we could push those other images those base images to the Jenkins org. That that shouldn't be a problem we could do that. And then once they release their images we could just switch that over. That would that would I mean it. The only reason it's not. I mean, the only reason it's not official from them is because that PR hasn't been merged. So I think they're, it's hard to tell when they're going to merge it. We've had ones that have gone for six months some that have gotten some peers that are, you know, two days so depending on when they merge that we can just push those base images when we build them into the Jenkins org on Docker hub for now. And then maybe that would just alleviate Daniel's concerns for now. We know obviously people run agents on windows or they run Jenkins on windows. How many people do we know of that use these windows server core actual Docker images. Well I think it's going to be going to become more useful with like Kubernetes. If people need to do Linux builds and windows builds they may have, they may start using these images more with Kubernetes. I don't honestly see a bunch of people using these just directly, just because Docker on windows is not as capable as Docker on Linux. That's my take on it is I think that the major use is is would be for the Kubernetes people. It's just that the size of the image is the images that produce that pretty big about 2.8 gig for the windows images, which may, may be a concern. So I did I have, I don't know if I submitted it but I had another PR to do to enable slim images for the adopt open JDK windows. And I was able to get it down to like for the nano server at least down to like the 300 megabyte range, which is a lot more useful, I think but I agree the 2.8 gig image size is pretty prohibitive. So, but I don't remember if I got that PR merged or not. I'll look at that. But again that's nano server as well. But for agents nano server should work okay. Yeah, I thought we had bumped into challenges with nano server because it was missing crucial things but but I don't remember so. Okay, we do have nano server images right now for the agents, not for the server, not for the server, or for the controller I mean, but we do have for the agents. So, we have and get runs on it. And some stuff like that so at least those things work under the agent image so I like I have no idea how many people are actually using the images. That's that's kind of hard to know as to whether they're actually useful to people. Okay. Gareth anything else on Windows Docker. I know that's that's that's it ready. Okay. So next topic was the CI Jenkins that I own master branch and the question was could we set a goal to make it pass, and we're not passing yet any comments or feedback there. It's the publish experimental step that's failing so the build is working correctly but it's once it tries to publish those to the Jenkins for eval. It's failing because of we need to update the Jenkins file, because of some of the changes that on a PR that Jim made. I believe I have a PR to fix that but I need to double check that. We just disabled that publish to Jenkins for eval for now, because I don't know if people are actually using those images or not. Again, we don't, it's hard to know whether they're using those who's using those and how many, you know, how many and stuff like that. Great. Okay. Those are the two options. So next topic I'd propose to skip because I don't have I have done nothing to prepare myself for a conversation with it unless someone else feels like they really want us to talk about the Docker platform Jeff draft. I'd like to skip it for now. Any objections. Fine with me. Okay. I'll excuse my shame for not for now will revisit rework revise and reopen discussion. Is that is that document open for commenting. Okay, it's, it should be a let me double check just to be sure. It should be shared for. Oh no it's not open for comedy shame on me. I don't know how it is. Okay, anyone can comment now. Sorry about that. I don't know why I didn't do that that's that's that's embarrassing and another level. Okay. Docker image build rework so Alex. Yeah, so this is so I have a PR open on the Docker agent to rework so that even the Linux images are built and published from within the RCI infrastructure. So the reason for this is there have been some PRs in the past that want to add things like build date metadata, and things like that and using the auto build features of Docker hub do not allow you to do things like that. So, or override environment variables for publishing or tagging or things like that so that the PR just builds and publishes the images for both windows and Linux within the CI dot Jenkins.io or trusted, depending on on Well for it would only publish on trusted. It would build on CI dot Jenkins.io for both. Okay, so it builds on CI dot Jenkins.io and publishes. Okay. It basically takes what we're doing with windows right now, which is we're doing the build and publish all within our infrastructure because they don't support auto build on the Docker hub builds. So then moves both into our infrastructure. All right, so then needs review. Are there are there any compatibility risks hiding there compatibility threats that we need to be aware of or notify people of it should be just a direct port over or. Yeah, it should be. And one advantage it also gives us is, Jeff Thompson has had, you know, issues having to go through like 20 Docker files and update the remoting version. This also reworks it so that you can edit a single file, and it will pull that remoting version in for the new build so it provides us some additional capabilities that are going to be nice hopefully. Yeah. Okay. Now, I've seen I've been thrilled with dependable in other areas can dependable manage Docker files as well. Or no, or yes it can. So an aspect of them. Yeah, certain aspects of them. Yeah. This does not this this PR does not go that distance. It's correct. It gives us a single place to manage them. And then we would submit PR as the usual way for that single price. Yes. Okay. Excellent. Anything else on the image build rework Alex. And this is just kind of the first one I after I do this one I and you know get feedback and so forth. I would do similar things to the other images. This is easiest one. And is this for the court the controller image or no this this is for the Docker agent, which is the base agent image for like the inbound agent. It's not the base image for the SSH agent but it is the base for the inbound and just kind of the basic remoting agent. Okay. So once that is implemented for this base image, then look to apply the same apply the same techniques in the other images. Right. Got it. Okay. Thank you, Mr. Alex. No, that should be all. Okay, so my last my topic here is improving arm support and, and this is more a question than, than an answer is what steps do we need to do to take to publish arm images. Is it just do the the multi arch that we've already talked about. So what are you saying for the controller or for the, for everything or what what. So for me first would be agents. And then controller, because with with I find the the Amazon arm eight instances, interesting even for the controller there they like offer a 40% or 20 to 40% discount on terms of compared to Intel architecture. So we do, we do have am eyes for arm 64 right now that we're actually using in our that are connected to like see it at Jenkins.io. So that might be something that you can use in the interim. It's it's our, it's the normal. We use packer to build it and it's basically the same as our Ubuntu based build agents, but it's arm 64 instead of the AMD 64. And we've been using those on see it out Jenkins.io. That's one option. Initially, if you just need the am I identifier, you should be able to use it on AWS if you have like internal usage for yourself but we already do have those connected to see it out Jenkins.io and trusted I believe. Right. And so I've been, I've been using those quite happily. The arm, the arm agent on see it at Jenkins.io I confirmed yesterday again, it works great. So then in terms of image generation, the arms support on our Docker image as I guess is what I should say, because what we've really got. I'm confident we run an arm. I'm using it. I haven't run the controller yet but the agents. I think we have an agents Docker image yet for arm. Is that correct Alex. That's correct we don't have a, we don't publish an arm version you could take what's there and build it on an arm system. And it would, it would, you should be able to build it just fine. Thank you. And then I assume the same applies to the controller is that as a first test I could build my own image on arm and use that for experiments and to see hey how does it behave. So we have that in our flow to build those images right now once Jim's YAR and stuff get merged in, but you can still also do the same thing and build the normal you'd like Debbie an image for instance, on an arm platform and it would generate and Docker image for arm that you could use for the controller. I've actually done that and it works just fine. Excellent. That address that answer my question and I've got, got things going on there that are, I think arm is a particularly interesting platform. Great. Thank you. Any other topics we should address before we close our meeting. I take it back. I've got one more contributor summit. I'll be sending a proposal shortly for a contributor summit associated with FOS them or roughly two weeks after FOS them. And what I'm going to suggest is that SIGs spend time in the, in the introduction segment, summarizing their results and where they're and their plans. And so we'll, we'll likely get that responsibility and I'll probably try to be first voice, but I'm sure that you're all aware of that proposal and I'll send a copy to you. Anything else. All right, let's call it a meeting. Thank you. I will post the recording after the after it's finished processing. Thanks.