 Welcome everyone. This is the platform special interest group for Jenkins. Thanks for being here and here's our agenda for today. Alex, thanks for joining us. So we've got open action items that will review first. Then we've got several topics around adopt open JDK. One as possibly considering it as the as a replacement base JDK for the Jenkins image, instead of relying on open JDK. The other is we've got a proposal right now in the community to add a J9 based image in addition to the hotspot based image. So we'll talk about that. Alex, that may frame or help us have further discussion and Docker multi multi arch. So we'll hear some further from you on that if you've got additional to discuss. Then we'll give a status report on the windows installer and the code signing thing. Okay, so we're going to have a meeting that are bumping that it's bumping into October fest discussion. And I think we will delay the configuration is code change. Oleg is traveling and on vacation this week so we'll likely delay that until another meeting. Anything else that needs to be added to the agenda Alex. No, I think that sounds good. Okay, so first then let's review the open action items. I've still got the action I'm long standing to open the jet for the Docker operating system support platform selection rules. That won't happen probably for a month or more because I've got other things that I need to focus on like October fest. Likewise, Oleg's got one for the windows support policy by the Jenkins project. So Alex, you've got the topic on windows installer code signing. And you, you want to give a brief status on that what you've learned is as you've watched that ticket flow. Basically, the update is they're going to create some type of LLC limited liability corporation to be an entity that will be able to purchase the code signing certificate. So we're just waiting on that the legal stuff for that to go through and then they can simply purchase some codes and gets for the Jenkins project. Great. Okay, so limited liability corporation in the US will allow them to have a legal entity which isn't tied to a single person right that's that's good. Excellent. Yeah, that's very good. Okay, and the core release automation project I know that Olivier continues working on that right now that I believe the biggest sticking point still is the code signing. Additional pressure putting on that to get that LLC created. I'm hoping to hear more within the next two or three weeks. Great. Thank you. Okay, so then the next is that adopt open JDK is an alternate JDK implementation, which includes JDK is built and tested for various interesting platforms. They're tested with the Java compatibility kit. They're verified and delivered, and they they work quite well I've been using them for many months as an alternative to open JDK. And that that alternative is now looking more interesting because it's a natural place to get platform support. For example, they already provide an officially a version they support that runs on IBM's mainframes, and they provide a version that runs on arm, for instance, so on the Raspberry Pi style processors. They, they run in enough interesting places plus of course they support Windows and Linux and Mac OS. Right now what Jim has started is a proposal to discuss what it would take to transition the docker image that we officially deliver from using open JDK to using adopt open JDK. And that would mean that it has to support. Right now we deliver a devian image, we deliver a devian slim image. We deliver a centos image. And Alex, if I remember correctly, we do not yet deliver a Windows image in Docker. Yeah, not for the master. We are providing images for agent. The FSA agent, JNLP agent and then basic agent image. But I did some work to do a master image on Windows. I'm really interested. So, I don't know if that's the, if there's any reason to bring one up at all. One thing that none of the organizations have is nano server Windows nano server images. So that's something I was going to work with Jim Crowley to see if we could work with the adopt open JDK team to create nano server images. Now, could you give me and help me out? What is nano server? That's a Windows product. Give me a little bit of overview on that. Yeah, so if you do a normal like Windows server core, Docker image is like 2.5 gigabytes, which is pretty large. And nano server is around 500 megabytes. So it's a pretty small image that provides the basic support for things, mainly it'd be used for agents, not for a master. I see. Okay, so this would give me the benefits of running on Windows kernel running, running with Windows file system Windows kernel, but without the large image size. Okay. Right, right. Yes. All right, so like slim for Windows. Interesting. Okay. So, but you say that, but you say not even adopt open JDK has a nano server image. That's correct. And there's actually a bug. At least in the 8th sense version 222. It has problems with nano server images because it doesn't have all of the DLLs and stuff that like the Windows server core has, because it's smaller obviously. Uh huh. So, there were a couple bugs that have been resolved. So we should be able to do nano server images now. Oh, okay. All right. So the bugs that were reported have been resolved for nano server should be possible but doesn't exist yet. Yeah, so Jim said he had a contact adopted from JDK that we can work with to try and get some nano server images created as well. All right. Excellent. That's great. Thank you very much. Okay, that's very encouraging. Now, one of my concerns was with all the master images we have, I am quite dependent and I assume others have the same bad behavior if you will, that the master images are very important and their exact content is quite important. So, for instance, I depend on certain pack on packages that are in in Debbie and in the image we can't change that I suspect or we'll get lots of grumbling. Now, the other one was, and I think Jim's proposal looks okay for that the other one was Alpine support, if I remember right, is is still problematic for for for the JDKs because, for instance, Alpine for J open JDK 11 isn't isn't supported at all. Have you heard anything on that topic further Alex. I'm not. And I don't know if Jim looked at JDK 11 when he was looking at their unofficial Alpine images. I'm not sure about that. Okay, so unofficial images available for open JDK. I don't want to adopt open JDK, because I thought I saw that that the job, the JDK project refuse to do Alpine because of the C library on which Alpine is based. I think what he said was that they actually just installed you live C. I don't remember for sure. Okay, all right. Natasha thanks for joining. So anything else on on Oh, so that I think covers the topics I know about adopt open JDK. Alex unless there's something else that you wanted to be sure we capture in the notes. Oh maybe we should capture next steps so next steps. I think are evaluate the poll requests to make the transition. I think it's important you mentioned that not knowing or making sure that the packages that people rely on are still there. We want to look at feedback from the best group to see what packages people rely on so we can make sure that any decisions we make are not going to break people. I was there I was assuming that we rather even than soliciting feedback that what we do is we make our goal that that we don't lose any packages in the transition. That's a good idea. I was thinking, whoops, excuse my bad. I was thinking that confirm the package contents only changed the day to the day to K, not any of the, any other package definitions package inclusions. I think you've got a good point. Ask the dev group dev list. If there are specific package requirements, which can't be retained, right if we find, hey, the failure to include open JDK means that we lose these things these packages that were implicitly installed, but now don't get installed by adopt open JDK. Do we need to explicitly install them. So I guess what that really needs is needs an integration test. We also verify that the size of the image is horribly different. Oh, good point right confirm image size is not dramatically larger right if we've, if we've suddenly bloated it with far more packages that increases its potential to attack surface right good. Okay. Great. All right. Are we discussing the open J nine as a separate. I think we should do it as a separate and I'm ready to start that now you ready for that discussion. Okay well so first let's give an overview for those those who may be not not entirely aware so open J nine is a different garbage collector if you will my garbage question is the wrong way to say it's a different virtual machine. It's a virtual machine implementation right. So it's a competitor to hotspot hotspot, the de facto virtual machine image. And what it has as a benefit is that it. It is designed for small environments. Fast startup environments, and low memory environments. For example that makes it particularly interesting for places where we may have less memory than than typical my raspberry pies, a pine board or those kind of things where a constrained environment. The fast startup time is particularly interesting for use when testing and, and, or if we're running things like the Jenkins file runner where it starts a Jenkins instance perform some action and then stops cutting the startup time is is very interesting there because it cuts the cost. Do you think that Jenkins might be interested in faster start up as well. Right, right exactly places where where reducing the cost of startup is a hell matter a bunch. So open J nine is interesting for that however. This is because it's a different virtual machine there can be bumps and bruises on things places where we were unwittingly dependent on the hotspot virtual machine and need need some code changes however open J nine initial testing look quite promising. It has one other feature which allows it to do. There's a, there's a word for it in the compiler world, where what you do is you do preload a cache preloading. Yes, yes exactly it's ahead of preload the cache of Java objects before before starting the virtual machine at the virtual machine startup and what that that the idea then would be, we could not and do a start Jenkins in the Docker image build process and stop it. Stop Jenkins. And include the resulting files in the image to reduce startup time even further. It's, but that's not if I understand correctly, not a currently supported technique by the by the build process that we have. I think there was an issue filed by another, I don't remember the gentleman's name. He was going to look at kind of some of the stuff that he had to do to get it working. And then he was going to do a PR for it. Okay, all right. Yeah, so for me that that one because it's, it makes open J nine interesting. I assume it would be more interesting for agents for example, than for then, then as much for the master because sometimes we've got a femoral agents where it's crucial that we start them and stop them very quickly. By the way, that's open JDK has Docker images for you can use as a base with open J nine. Oh, good. Okay. All right. Another factor in switching to about the JDK. Oh, right, right. In fact, and that was one of the motivators for Jim Crowley I think was, Hey, how can we, if we, if we switch over to adopt open JDK we get the benefit of their, their standard images. Very good. Thanks. Now that's, that's all that I have right now I haven't done any evaluation of open J nine I haven't seen a pull request yet. I think next steps there are to discuss, discuss the issues with in the dev mailing list and test and experiment now what one of the thoughts I had was agents and the master. There was a report I remember on the mailing list of significant improvements in master startup time. I believe the person who did those tests was using this preload cash to make the startup time, even better. Any other things that you wanted to note there, Alex. Okay, Natasha, I see that you had joined. Thanks very much for joining us. Natasha is a contributor from our from the Google summer of code. Hey, were there topics that you wanted to be sure that we put on to the agenda Natasha. Um, so, this was like a couple weeks ago, Oleg asked me so I had gotten some, like feedback on the plugin installation manager. And so all I could invited me to like just discuss that on one of these calls and I know like last time the meeting was canceled or I don't know exactly what happened so yeah so I if there's time I wouldn't mind like talking over some of the feedback that was given. I think let's go ahead now this is a great time if you don't mind taking it now I'll take notes and we'll let you go ahead and and provide a summary where where we're at with the plugin installation manager and what do you think the next steps are etc. Go ahead. Okay. So, yeah, I guess like we can start kind of like current status so once school started, I haven't really been doing much work on it. I did have like a couple questions this was like unrelated to this particular feedback but I think the next step was like releasing basically the first official version. And I was always like a little bit nervous to do that because I don't know if like if basically once you release that then you have to support, you know, backwards compatibility so I don't know maybe Alex would have some input like do you think that's good to go or is there anything else that you think should be included or taken out before I do that. I thought it was at a really good state. I saw you done phenomenal work over the summer. I think it's I think it's ready for a first release and and yeah you do have to think about backward compatibility and stuff but you know at a certain point you're not going to be making a ton of changes. I would think that just adding features. I think it should be okay. Not too bad to support it and plus remember it's a, you're not the sole person that has to support it either. So you have a whole team of contributors who can help to just remember that too. So the repository is is open right it's open in the sense that it's a public repository so others can submit pull requests for your you to evaluate or now Natasha the we did get a transition to the GitHub from wiki for documentation to get I assume that the plugin installation manager hasn't gone through that transition yet so if someone wanted to contribute a pull request to you for that change. You'd at least I assume be willing to evaluate it have I understood correctly. Yeah, so I guess let me understand so I know all I can asked about that too and are you talking about like transitioning from Jira to like GitHub issues, or are you doing something else. No, not for issues so it's good question. So issues will you can continue to track wherever the documentation typically is in a read me file or some other place. So the plugins provide their have from a long history provided their documentation on wiki dot dot jenkin ci dot or dot IO or Jenkins dot IO. So that wiki though we've taken it read only because of spam problems, and because we found that we prefer to maintain the documentation right inside the inside the plugin notes own repository. I think you're probably actually already putting the documentation there we just have to make a minor change to your palm file, and it will start publishing automatically onto the site plugins dot Jenkins.io. It won't know because it's not a plugin. Ah, okay. Oh, I don't know if there is a wiki entry right now. Is there Natasha. I don't think so I think at least all the documentation I've written has pretty much been directly on GitHub. Okay, so no issue then that's that's let me put a note for mark weight investigate how tools are documented. So then that probably means if anything, if we want to add further documentation, it might be put it on Jenkins dot IO or put a link link on Jenkins dot IO to the actual documentation on GitHub. Yeah, I'm not sure. Like, I'm not sure like where Jenkins file runner, for instance, it's docs. Right. So that would be a good documentation stick. Yeah, the topic about cool documentation. I will put that on the docs agenda for tomorrow morning. Thanks. Natasha back to you. Okay. All right, and then. So just in terms of some of the feedback that had been given. So all of that is posted on. I'm interested on the getter chat. But so some of it I think is not as relevant or I think, you know, if I guess it does. In some ways, I'm pointing out that maybe I should make more things clear on the on the documentation. But so I'll just kind of go over some of that. I think so I guess like the first question that I had was. So in terms of like, if you like input for the tool, if you have TXT file, it'll kind of accept like the following format like the plugin name, the version and then like a URL. If you want to download it directly from a URL. And so one of the problems that I had sort of had was like, so those are separated by colon and but then there's also kind of like a colon and like, if in your URL to so I think that that more or less, it was like kind of hard for me to figure out like the best way to, I guess, purse that. And so one of the things that like I had done was just like, and I think this is what it was already doing. But if like, if you have, say you, if you do input of URL, then the version will just be ignored. And I think like the expectation would be that people would just leave that. No, or just like have an empty string there. Um, but it could you could end up in some situations where people like don't do that or it could be sort of confusing because yeah basically if you have a URL, then the version would just kind of be ignored and the if you're downloading it from your all you could actually have it if you did include a version where those versions don't match. So I don't know, do you guys have any feedback on that because I tried to make it like sort of clear so I think like what I had said is like, basically that you should include the quote unquote placeholder for a version. But like what I meant by that is just have that no. And so he like pointed out that yeah you could end up with sort of. And this is true anyway that you could end up with kind of like these like weird scenarios. So, um, yeah, do you guys have any feedback on that. Are you using a split split up that that if I are using like reg X. Um, I think I'm using is, I think I'm using split. The second parameter that you can pass the split do a limit. Okay. The limit to three years and I don't know if that solves the issue but it's something that you could try. Okay, I might be doing that. Um, I can't I spent actually over in a while since I've like looked at that I'd have to double check and see but I remember that was one of the things when I was first creating it that was like seemed a little tricky. But yeah I can check that. So I'm, I'm not overly worried about I, I think the choice to put colons is the separator between the of the things that follow plug in name is the right choice because you keep compatibility. And for me that was the crucial thing so I wouldn't, I would lobby against switching separators. I'm concerned about the pay if you if you specify the version and the URL you get exactly what's at the URL that's for me that's desired behavior. I would not want you to silently apply some rules to the or apply rules to that optional URL to attempt to use the version number URL is is not used in the other the other formats that typically use plugins dot txt file. They say plug in name and version as far as I recall, you can do URL, or you can. Yes, I would, I would say just kind of given an order of precedent of the URL is the highest precedent. And then the version is secondary precedent maybe that's what you put in the docs. Okay, I would specify the URL you're getting that URL regardless of what version it is for what version you specify. Okay, URL, a specified version you get that version. Okay. Okay, that makes sense. Yeah, I think, I think basically kind of my take my one takeaway was like, maybe I just need to make the docs a little clearer. Because it seemed like some of the wording I had was like a little bit confusing. Hard. Hardest thing for me. Yeah, yeah I feel like it's one of those things you don't realize it's confusing to other people and until they start looking at it because you've been looking at it for so long or you just kind of expect that people should know, but this is not always a good assumption. Okay, so let me see what some of the other feedback is. Okay, so this is he said, or he recommended. Versioning the plugin input txt file, which he said this will allow you to make updates to the parameters while easily maintaining backwards compatibility. Many public APIs do this, for example, Docker composes YAML files. Do you guys think that that would also be like a good idea. I don't object, but that means you've now introduced a syntax that none of the other tools understand because so versioning the plugins text file I think means add one or more lines right that declare what the version number is of this text file right. Yeah, that's my understanding. So if you want you to store off the version that was previously used and then compare it or what was, I don't remember the feedback on this item. Um, I think Alex I think it was that it's added, it's added inside the file right so there's no need to store it because it's in plugins that txt itself. It's a it's a syntax so there is a comment format isn't there Alex that the hash mark is used as a comment. I'm just wondering what he wants done with the version. Um, yeah I think it was just a if like, okay my understanding is like if it if I change something about like the format so in the future, like that would just help with kind of knowing which which format you're currently on. Or if you're trying to use like an older format. So I guess like in some ways if we always say like, it has to be backwards compatible going forward, but maybe there's this. If you want to continue to add things maybe you'd be helpful for you to know I'm, I don't know. Yeah, so you guys don't think that that's necessary or it just doesn't it's different from the way a lot of other. You said, just kind of like the way it's done now and in other places. No objections for me to adding it but I would just add it as a parsed comment. Right the format the file format already accepts comments. And if if you said, hey, we're going to buy de facto standard. Make the partial if if the first line starts with a hash mark, a space, the word version colon and then some string that will be treated as the version of the of the file format. Then you haven't broken compatibility. And if in the future someday you said I need to make a major format change. People could say all right the version number is now version two instead of one. And you could then honor that in parsing the file. So long as so as you don't object to using it as a as a de facto standard by by declaring it as to be a comment in the current format. The other thing that could be done is if you do need to change formats in the future you can add a command line parameter. And, you know, version two parser, or whatever you know dash dash version two or something like that. So, okay, would be, would be fine. I don't know. I'm hesitant to have you added as a non comment, just because then other tools that read plugins that txt won't know what to do with it. Gotcha. What other tools that does that include. So the, the install plugins.sh, or is that the right script name Alex inside the Docker file image there is a script that parses plugins that txt and uses it to load the defined plugins into a Docker image. I think yeah. The plugin tool is going to replace that. I agree. I mean, not for a period of time necessarily, but we definitely want to get as soon as a, you know, a one point on release is done, we want to start PRs and stuff. And testing and so forth. So, yeah. Okay. Are there other places where, because I think, yeah, in terms of the plugin, the plugin install plugins bash scripts, the, yeah, the goal would just be that this would take the place of that so I'm not, I'm not aware of others but given the breadth and the depth of people's use of Jenkins. I'm confident there are other places where that format has been used. Okay. And then the next piece of feedback so I, I haven't ever used terraform so I don't know, I guess I didn't really understand this quite or I didn't have enough context for this. He said, and I don't know if this would be a plan with this tool anyway, but he said, should you expand your tool to interact directly with Jenkins, a great feature to add would be terraform support. I would represent all the desired plugins and HCL lossy declarative language for infrastructure code, which would easily, which would lead to easily automated use of your tool. I don't know if you guys understand that feedback. There's a terraform being used to define a declare, to give a declarative declaration, a declarative definition of cloud infrastructure. And that lets, for instance, we use it to define a whole bunch of machines that we'll use for training, and then automatically tear them down when we're done. And, and so terraform in that case, just lets us declare I want this many machines of this type with this installed on them, etc. So that's way beyond the your current scope. Okay. Okay, yeah, that was just. Yes, some of the feedback he gave. And then the last sort of thing that he had said was, so we had gone sort of back and forth about some of the default behaviors so in terms of like, which plugins you and the dependencies that you install. So, ultimately, what I ended up doing was making it by default to install the dependencies that are listed within the data in the update center. But the problem with that is that sometimes those are a little bit conservative or maybe a little bit. I don't know there's much like newer forms, but with the previous tool with the like always getting the latest dependencies the problem with that was that those aren't always deterministic so it changes as later plugins come out. So, so the last piece of feedback that he said and I think that this is, I guess like a good idea that I haven't done yet but he said that he was a fan of the deterministic route by default with the optional ability to go and go update auto update all. So, yeah, so I think basically he he said that he's a fan of having software that does the same thing, you know, today and six months from now, but it's good to also get the latest version. Because that's most likely, like the most secure. And yeah, then he could perform, like updating, like I guess on his own time. So I think that was most of the stuff I don't know if you have any other. I guess there's a few other things. Yes, yeah. For my clarity Natasha plug in installation manager today has chosen the deterministic path. Yes. Okay, so you read inside the metadata from plug in a to decide which of its which version of its dependency should be installed and I assume if I declare explicitly one of those dependencies and its version you use my explicitly declared the implicit one from the update. Right, right. And then but there was like a lot of, you know, feedback on that to where people, we also wanted to have compatibility with what's done now. So yeah, there's also the option where you can always just take the latest if you want, but by def that's not the default. So by default it'll be it should be deterministic and you should get yeah whatever those versions are and then if you do want like a higher version or the latest of specific dependencies you could specify that. And then yeah if you if you do want just take to take the latest of all, then you can specify that to you. Excellent. Thanks. Thank you for that summary. Thanks very much. Okay, so. Yeah, I guess that's most of that so I don't know if you guys have any other feedback or anything I mean if I could probably do like a release today if now that I feel a little bit more confident that it sounds like it's ready I think and yeah I just hadn't really once school started. I had a lot more distractions so I haven't been able to dedicate as much time. I actually you've done wonderful things thank you very much for your contributions in the community and Natasha. I think it's time to do one that oh one that was not the last release. Right, we're going to we intend to continue releasing so calling it one that always had plenty of time to to bake plenty of time to settle. Certainly there will be more things discovered and it feels perfectly reasonable to call it one though. Okay. Great congratulations anything else Natasha. No I think that's it from my end. Sure. Alright, thank you very much. So Alex the next topic we had on the agenda was Docker multi arch anything you want to report there, particularly given the adopt open JDK discussions. Not at this point. I still need to review kind of what adopted open JDK. And how that would work for the multi arch stuff. We have a lot of scripts in place right now and might just need to review all that. Great. Okay. And anything else on the windows installer status. We've talked about Jenkins core automation and the code signing certificate being the, the crucial thing there anything else that needs to be highlighted. There's a pull request in place on the packaging repository. I kind of move my changes into there and Olivier is using that as part of his release automation. So he's building the installer. And so forth on his relief infrastructure. And so yeah we're just waiting on the setting. Great. Excellent. Okay, super. Thank you. The next topic I had was October fest and the platform topics. I am thrilled to note that we have over 50 first time contributors that have come on to the project in its plugins or other core or other tools since the start of October. Over 100 pull requests. We've got only a week left. Here's your chance, keep promoting it keep encouraging people to look at the newbie friendly bugs. It's an impressive set there are still over 200 newbie friendly issues that people can look at this little dashboard presents them like this. So you can choose the component that you want to use that you'd like to help. You can choose the severity across the top. And then when you do that, it will show you the bugs in that type so let's look for instance at my favorite the platform labeler and it's three open newbie friendly bugs. And here they are they are actually three feature requests automatically label Linux Mint automatically label Fedora Linux and automatically label clear Linux so if somebody wanted to contribute. You can use those. Only a week left on October fest. Any questions with regard to October fest. None for me. Great. Thanks, and we will defer the, the configuration is code topic until Oleg returns hope to see everybody in two weeks. Thanks Natasha thanks Alex. Thanks.