 Welcome, everyone. Thanks. This is the Jenkins platform special interest group and it's the 26th of March. Thanks very much for being with us. I'm going to share my screen so we can see the agenda. And you should see the agenda on screen. Do I do you see it? Oh, everybody's muted. That won't help. I see it. Great. I just opted out to note. Okay. Thanks. Thanks everybody. All right. So here are the topics that let's first review topics so open action items. GSOC 2020 custom Jenkins build service discussion with Slayton. That's this is deferred and Slayton's not in this session. So as a follow up, we had a special session for this project and the solution actually happened this morning. So something like three hours ago. We had three students over there. And we discussed a lot of topics. So I believe that this item can be closed. Great. So I'm just take it off the agenda. That's Windows service wrapper. We discussed everything. The last meeting. I don't have any specific updates there. Except the fact that now it's a separate GitHub organization. So we are setting common environment for that including additional GitHub apps. The new release flow. Most likely we will move to Azure DevOps because the project is based on .NET. So we may use its ecosystem. And yeah, that's in progress. For user regards to GSOC, everyone is welcome to participate. We've got two proposals so far. Maybe we'll go a bit more. So let's see. Excellent. Okay. Great. All right. Thanks. Great. I'd like to put platform SIG roadmap proposals on the agenda. We may want to put other topics first. I've got a number of proposals there just to be on the agenda. Are there other other agenda items that I should be adding here? Jim, for instance, anything that you want to address on power PC or series 390 support. I was just looking for status mostly on the progress of power and S390 being incorporated into the infrastructure. And then, well, we have the open action item about the PR. So we'll be good on that. Great. All right. Let's, and so let's put that in. Alex, anything that you need to put on the agenda. I know we've got Windows installer as a past topic that may have finally broken loose because we actually have a code signing key. Yeah, I haven't heard. I need to talk to Olivia today about whether he's tried. I don't know if he's received his certificate yet. But once that's in place, there might be some debug and stuff. Okay. So what I'm going to suggest is let's bring those topics. Power PC, etc. above the roadmap discussion because I think the roadmap discussion is more conceptual than it is project status. Any objections. Any other topics. Okay, good. Then let's go ahead. So we've got the topics open action items. Yes, I'm still embarrassed that I have not submitted the jet for Docker operating system support. Apologies. Windows support policy Oleg I assume no Jeff for that yet. Yeah, so we started some discussions about what we want to do for Windows service rapper and other components. So for me it will be a natural outcome. Right now I'm moving some bits of documentation to Jenkins IO. And when I complete that maybe I will write something for Windows and propose it maybe not even as a Jeff, but as a new page. Well, Jeff is cool, but Jeff wouldn't. In place that there would be discussion. And for now, we do support we have usual suspects. So we can just figure out the basic level. Let's see. But they like them. Good. Okay. And then Alex on the Windows installer. I'm just going to put here checking today. So okay if we know that code signing has made its first progress in months. That's really I was delighted that it is so marvelous. Okay. Yeah, so to be specific, we got the certificate which we tried to use already. So we need to deploy it. Thank you. Then we've got the Docker build rework PR. And finally some some intense interest recently intense and frustrated interest from Daniel back recently at the during the recent security release. Something went wrong and he spent 30 minutes waiting for a build right and that was that's that's not a time when you want people having to wrestle with slow or or long running builds. Yeah, so for that PR Oliver didn't look at it and improve it. The PR. Yeah, I think that link actually works. 922. He did look at it and improve the code changes. So I don't know exactly what you guys's processes in terms of emerging at PR. But it'd be great to merge it and then work with Oliver to actually implement the new infrastructure because we, I think, Alex you, you let me know that we got the arm resources up on AWS right. Yeah, that's correct. I don't know how much tested that they are available yet. Sweet. So it looks like we have all the architectures that we'll need now. You know, that's 390 power, actually six and arm. So it'd be nice to kind of start start implementing them and connecting everything up and see this PR will actually work or not the PR work but you know actually see implementing work. So what I would propose is someone who has trusted access on that repository to basically create a dummy merge request or pull requests based on yours so that it actually will run the Jenkins file updates and so forth. And then we can verify that it's all working in the infrastructure and then we'd be able to merge your PR. I think that's a good point because you're right that the Docker for the, the Jenkins file is not honored, unless you have trusted access right. Yeah. Okay, and that's all right. Good. Okay. How about I'll take that action item or Alex, do you want to look up the list of people who have trusted access. I don't know how to get that list. Yeah, I can look at that. I'm pretty sure I have trusted access but I'll check. Yeah, Alex should have it. So it's Alex me Mark Olivia. At least from usual suspects of platform seat. Okay. Great. Excellent. All right. Anything else on on that particular action item. Okay, great. Let's proceed then. So all that you'd said gsoc windows service wrapper anything else we need to note here in our notes. No, I think that's fine. I put some items generally. Okay, we'll look at more details may when we publish the pro. So, so there is nothing specifically impacting Jenkins project right now, except the fact that there is a bunch of features in coming and we already behind the versions. Because I didn't have time to submit a great request and we just covered a couple of regulations. So I put it on hold. But in principle, we do service record now is much stable. And we have new dotnet versions. We have new dotnet core native executables, which are quite heavy. But we can consider them to dependence on the dotnet platform. For example, for windows installer, it could be reasonable because for windows installer, we can just replace windows service wrapper by native executable. And if it weights 30 megabytes, okay, it's not a big deal for the installer. So there is definitely some positive impact on the Jenkins setup. But we still need to process that. So with that, go ahead. You have questions. The question was, would that would then avoid the windows installer needing to declare a dotnet dependency? Is that what you're saying or Oh, Yeah, so specifically for windows installer, I mean MSI packages, we can do it right now. Because right now, we agreed that we drop it. It's sorry. We drop 32 bit system support so we can just embed one installer for md64. Well, assuming that we don't target windows on arm and other bits. And just that's 30 megabytes. So instead of 70, you get 100, but you don't need dotnet. So for MSI installer, I think it's no brainer that we can switch to this mode. Alex, does that sound reasonable to you? I love the idea because one less dependence. Yeah, I mean, most windows server platforms that people are going to be running a master on will have dotnet already. So that's, it's not as big of a problem as it used to be, but it definitely be something we can look at for sure. So our main problem is dotnet is about specific behavior, because right now we have executable 4.6.1. So basically the recent dotnet version, but we already hit the problems with TLS implementation, these other bits, so they got results recently. Thanks to next time, who became Windows Service Rapper maintainer also, but still for me native installer would be a preference to that. But we also have Windows Service Rapper bundled two extra times in Jenkins, one in Jenkins code directly, another one in Windows agent installer model. And there it's much more challenging. I'm not sure what exactly would we do there. My personal preference is to just detach it to a plugin, but it may impact the installation experience so I'm not 100% confident about it. I think that are those two additional bundles that you to additional bundle locations also included in the Windows installer, would they naturally be there so we would increase the size 90 megabytes instead of just 30. So basically yes, if we proceed as is, because currently there are two jobs. So, yeah, not to executables included directly within the Jenkins work file as a resources, and our windows installer includes a third time. And we don't care about that because right now it's something like 500 kilobyte. But if you wanted to do the same approach as needed executables everywhere, it's a big pain. So, for me it's now go and I will be doing that only if we detach windows agent installer, and maybe Jenkinsmasters Windows Service installation functionality to a separate plugin. Got it. Okay, because yeah, right now you can install Jenkins as a Windows service after running it as a work file. To be honest, I have never used to this option so I cannot say who would need it. So detection to a plugin doesn't sound like a bad idea. I agree. It's if people are going to run as a service they're going to use the MSI in my opinion. Well, MSI or just standalone installation. But yeah, there are obvious issues because right now if you want your Jenkins to install itself as a service, you need to run a Jenkins as administrator. And there are so many reasons why it's a bad idea. Right, that's one to continue. That's bad to the level of crazy ideas. Should I run Jenkins as root on a Linux machine? No, should I run as administrator on Windows? Probably not. Yeah, okay. Great. Anything else on Windows service wrapper? Okay, Jim, let's take it. Power PC in series 390. That's more of a question for you. I was looking at the JIRA board. And I see that you were commenting on those issues. I was wondering what was like mostly the status with that about getting everything connected. Yeah, so let's take the two stories that have a really positive spin first. PPC 64 LE and both PPC 64 LE and S390X are serving mark weight very well. They're awesome. I have agents connected. They are running builds and tests of as Java as Linux and Java and Maven labeled agents. So I use them freely. I'm also running specifically builds for get client plug in, get plug in, and platform label or plug in. Now the one the one flaw in this at the moment is I'm using OpenJ9 on series 390. And that makes me a little nervous because that's the only place that I'm using OpenJ9. I've had no problems with it. I think I should use adopt OpenJDK on S390, but I need to be sure that it doesn't degrade performance. I need the JIT that gives me acceptable performance. And now Jim does is the JIT available for Java 8 on series 390 using adopt OpenJDK. It is. So the, from my understanding the on Java 8 S390 you have to, you'll need to use adopt Java with I think OpenJ9. So OpenJ9 is just a JVM or is it a package? Every other way they call it, but so in adopt you have the hotspot implementation and you have the OpenJ9 implementation for Java 8. And I think it's the only Java version that has this is Java 8 hotspot from Oracle is missing that JIT. I think I want to say OpenJDK Java 8 OpenJ9 it definitely has a JIT. I want to say the hotspot for that version might have the JIT. That's something I can go out and reach out and make sure it does. Yeah, and that would be a that's so I'm already using adopt OpenJ9 implementation on S390 and works great. So that one I can confirm it's fast. It's actually faster than some of the other machines I'm using. So I'm really impressed. You basically want to make sure you hotspot. Okay, so you want to make sure hotspot runs. Okay. Right. And I know I know past 8 you won't you won't have a problem with this. I just I know 8 is tricky. Okay. So I'm going to drop an action item for there, there for you Jim. There we go. Got it. All right. Very good. I could do the experiment, but it's a lot simpler for me if you answer even if you're willing to provide the answer that's great. No, that's 100%. So after we get that test done, what are the other blockers, I guess, or other stuff that needs to be added I saw. I think something about automating the infrastructure on the JIRA tickets and then connecting them to CI, Jenkins IO and Trusted CI, Jenkins IO. Right. So, so first, first step we need is we need the other hardware for PowerPC 64 LE. Right now the the we're using a jump post to a transient or to a temporary machine right and it works. It just it has a complication that is much harder to use than if we've got a standard it's available just directly through SSH. Yeah. And I can, I don't know how fast I can move up the temporary host I think the lawyers are still looking at the terms of use sheet for power because technically I guess they didn't have one. The S390 Linux one community cloud did. That's a lot more common. I, you know, I'm really a S390 kind of person the power is mostly just, I know a couple of the power team. So the power team doesn't have one or didn't have one so they're in the process of making and talking to the lawyers to make a whole new one, or not new ones, the first of its kind. So what I can do is I'll reach out to them see if I can punch a hole and maybe do like a, you know, port, you know, 22 or 222 for you guys so that eliminates the need for the jump posts. Would that help you guys kind of in the meantime for that. Let me talk to, let me take the action I am to talk to Olivier, because we've, you are, you are bringing the, the same story that we had with the code signing right which is as soon as we get a legal team involved. There is an indeterminate period where so let me talk to Olivier Bernin about using a jump post because for me it is working. And it just it requires a little bit of a little bit of setup. But let me talk to him about that to see if he's willing to, to use that kind of setup in, in the meantime, CI Jenkins that I own trusted CI. So let me put that as an action item for me. I'll also follow up after all to follow up with status for the legal document anyways. Also just ask him if they could punch a hole for SSH. Is the agent just use SSH or is it use other posts or other ports I think you mentioned you could set up either or Yeah, well so it's certainly easier to use SSH because then we manage it directly but that's true we could use Jan LP couldn't we all like we could use Jan LP we could use WebSockets though for WebSockets it would be preferable to wait till the next LTS because we have a bug fix which is needed to stabilize the demo it's currently an experimental feature. I think that we could also use a remote and cover patch Kafka though I'm not sure how it would help in this case. But if we need to pass through firewalls through proxies maybe looking at WebSockets is a good idea. And I think that it would also helpful to the Jenkins community because some of the pudding for this feature would be reasonable. Yeah okay so that's that's an Olivier topic as well. And this one is good. Okay. Yeah, good point. After remoting 4.3 right. It's not only remoting 4.3. So it was introduced in the new LCS baseline. So at the moment Sage Inconsidue is updated to 2.222.1. And this version includes WebSocket support. As you know about one bug basically messages beyond 64k they're not delivered correctly. This bug has already submitted the updates for that it's LCS candidate, but it won't get into the release until the next month. So we cannot try out of the communication. It will likely work, but it won't be stable until the two in one month. Right so for large 64k byte. Just a second. Yeah I'm looking for the ish number. Yeah, and I can I can attach it later that's very kind of you. That's great. Okay, good. So, so that. And now Jim I'd propose we talk to the next topic series 390. And there I think the next steps are. We have the S 390 X host, and it's final hardware ready to use. So I think there the action and for me is Mark talk to Olivier on next steps on those tickets on that ticket. Thank you all like, because it is definitely working for me now I and the we've also got the open J9 question. Excuse me open J9 question versus hotspot on Java eight. And that Jim that's just one we didn't answer on ultimately if we have to use open J9 for builds we can. I assume open J9 executes hotspot or byte code. No problem from Java eight since it's running Jenkins just fine. Yeah, I don't I don't think I think there's just a performance issue I don't think that you know if you run, you know hotspot or whatever that doesn't have the jit, it'll just be slow. It should run fine. Very good. Okay. Excellent. Anything else on series 390 and power PC. Oh, that was it for me. So Docker PR status and progress. So this one is Mark and Alex. And Alex I think you described it very well it's Alex to create or find someone to do the shadow PR. Yeah, I'll do that. I'll do that today. Thanks Alex. What will the shadow PR do just to trigger builds or trigger the. It will allow the actual Jenkins file to be used from the PR. We, we don't have because Jenkins files can do things that can be dangerous we block Jenkins files from PR is being actually used. Unless the person has specific status on the repository. Okay, makes sense. Yeah. We do this every so often when it's something like this. I mean we've done it on the Docker agents PRs and stuff like that when there are changes that are incorporated into the Jenkins file, just so we can verify that things look good on the infrastructure. Anything else on that so I've got Mark to do compatibility testing and compatibility review. There's a piece of me that always worries about any change to, we may need some form of upgrade guide. I don't know that we have a vehicle to look to deliver such a concept so keeping things rigorously compatible is is much better. Anything else Alex from you on the windows installer. Now just waiting to get the certificate in and release process up running so I can make sure all the stuff is working. Right. Very good. Thank you. Thanks very much for your work on that. Great then next topic I had was roadmap proposals. So good that we've got Oleg with us today. So what Oleg is done is he has proposed and it's been accepted by the governance board that we will use a concept of a roadmap in the Jenkins project, and it'll be posted on Jenkins.io. I like this crucial piece road maps have places, not dates. So, so they don't describe when things will happen they describe destinations we're striving to reach. There are three, three terms identified current, which is things that are in progress right now. Work is being done near term. I think of that as either in progress or very, very soon to start, and then future which will be sometime but we envision this is a likely destination. Hopefully after we get done with things that are on current and near term. Oleg, are those fair ways to describe the roadmap concepts or would you like to use better words. No, I think that's fine. So the terminology is up to review on my plan is still too far formula file a job. Because right now it's in the Google dog but it's open for feedback. Everything is, as you described, and another specific that the roadmap basically in progress seeks some projects and other entities within the project to come up with their own project items. We do not want to force any kind of roadmap on contributors. We don't want to make it extensive for everything, but operating entities like platform specialist to their modern welcome to come up with their suggestions and to put them on the public roadmap so that they can improve visibility of their projects. Thank you very much. Now, I just realized that based Jim on your description we should probably put series 391 on the list because that seems like that's the strongest focus for you. And our PC is great, but is that a fair reordering in terms of. Yeah, yeah that probably the best idea. Okay. So we have three three platforms that we think we should add support for I didn't put arm 32 anything like that. We've got a picture for these and I think all of these I would call current or near term current because work is in progress for those two. And Alex arm 64 call it near term call it. What I was saying, I mean, it's just a matter of trying it on one of the AWS instances. All the software should be installed and ready to build so we just need to try it. Okay, so I'm going to put it as near term. We don't have a PR yet that's proposing it we need some experiments so great. Okay. Well we do have a PR that the PR that that Jim has arm 64 in it so. Okay, great. All right so that's excellent. Anything else on platforms that should be listed here. Is everybody in this meeting okay with those three as as sort of a platform roadmap roadmap items from the, the, the sake. And principle yes. It looks good. Okay, cool. Next topic then was JDK's here we've got today we have open JDK in our images as provided by the operating system vendors. And one of the proposals of the in was either to add or to change to use adopt open JDK so that instead of relying on vendor provided sent those debut and etc. We switch to JDK provider images that are built by adopt. That one feels to me like it's current because, well, or is it current we have a PR pending on this one. I don't think so. It's the best to call it in your term. Yeah. I'm still working on reaching parity with what you guys offer for base images and what what doc offers for base images for the official doc images, they have all the base images you guys support in the unofficial repo. I'm still working with them to get the PR approved by Docker, the, you know, Docker official library, official image library, so that we can use the official images, not the unofficial. Oh, got it. Okay, so once that comes the PR should be easy enough to swap in and swap out or swap in, you know, swap out the from statement to adopt. Excellent. All right. And then open J9 for Docker images. Jim, do we have a PR on that one or is that one's that one's also near term. I think you guys do have a PR for that. I think did it get merged. I think I think that one got merged. I think that if you look at the base, you know, base folder in bank is I think there's an open J9 specific image. Oh, is it an experimental? It's only in the jackets for eval right now, I believe. Okay, so it's so it qualifies as current if it's an experimental for my mental model. Good. Excellent. Okay. And then Java next. This one I think is future, because we don't have any, any plan beyond Java 11 right now. I think we can predict safely some diet someday in the future a new Java LTS will arrive. Oh, that's right. Matt's sicker topic. We've got somebody in the Jenkins project that is actively involved with, is it may be no leg I forget where but he's deeply involved in the open JDK releases. And we'll ask him to present at a future meeting. So, we had some meetings before but I agree with Mark after Java 11 GE we stopped doing Java related topics. So assuming that there are contributors who are interested to work in this area and who work on want to work on future Java. It would be nice to have a start school or whatever, because there is a lot of changes in my recent sessions. And we still have lots of sick made increased subscribe to Java releases. So, I believe everybody gets notifications about this candidates and releases. Right. Speaking of Java next I think that we should talk not only about mainstream Java. You should also talk about other gvms. For example, I'm a big fan of Quarkus and grad. I think that we could start discussions about them as potential mainstream. Because, for example, running Docker images would be interesting. I had a great. Well, good for to type for Jenkins for the runner. And Quarkus obviously running Jenkins with such many work is a completely different story, especially if you want to get to native executable, which would be also interesting. Well, I don't think it's really possible for Jenkins to be honest. But at least exploring such options maybe doing some prototypes could help. And it's probably an area of collaboration is cloud native seek if it gets recovered at some point because Quarkus is basically cloud native Java resumes completely different packaging. But at the same time you can improve startup speed significantly you can also solve a lot of other issues. I think it would be nice to at least consider that. Not sure about putting it on road map now, but it could be good clickbait. Right. Well, it's certainly Java next as a future item so your thought if this would be an umbrella where we could in the future choose to do a Quarkus or a growl in addition to to open JDK. Great. All right. Alex, are you okay with Windows installer being on the roadmap and how would you would you call it near term future or current. Probably near term because people will start using it actually once the automated core releases are done so I'm sure there'll be feedback and and some items that need to be updated and taken care of. One that we've never and I that's great with me one that we've never discussed before was automate core releases but I think somehow that that fits conceptually under under the platform SIG as well and I think it should be on on the roadmap. Any guidance there you're okay if we it is already on the roadmap. I do not specifically split items to six of it. It's probably a subject for feedback. I created a section a section for platform support or platform and operating systems. But yeah automated core releases is basically on the Jenkins core site. Excellent. Good. And then one more that we had discussed last last time two weeks ago was HTTPS and HTTP to support with jetty. I, my thought was, this is one where we were we were. We had issues in recent releases that need more tests, right. More tests. More checks for safety and sanity. And it felt like this should be one that we put on and propose as a near term objections there. That sounds good to me. All right, we've gone we've gone beyond the typical time that we'd like to any other topics we need to discuss here before we call this meeting done. Oh, I guess I should tell you what I think the next steps are with roadmap. I think the next step is mark propose those roadmap items to the roadmap PR. There's a political request. Oh, good. Okay. Yes, so my intention is to actually get a roadmap for integrated tomorrow. Okay, well assuming that I get any time to get it over the line. Okay, after that, the approach will be just submitted for request. Because roadmap date is just a Jason. Great. All right, I will put that on my action item. Check most likely. So, got it. All right, anything else we need to we need to discuss in the platform sick today. Okay, thanks everybody. I think we'll be posted once two hours from now. I'm going to go ahead and end the meeting now. Thank you. Thank you. Thanks. Thanks.