 this computer. Hi everyone, I'm Mark Waite, Oleg Nanashiv and I are here with the Platform Special Interest Group meeting. Thanks for being here. I'm going to start sharing my screen and let's look at the agenda. So welcome to the New Year edition of the Platform Special Interest Group. We're going to work on the Christmas mode taking the number of participants. That's right. There aren't many of us. That's okay. It's the day after the New Year's holiday. So we'll talk about open action items. Give a report on the adopt open JDK proposed transition and that project. The adopt open JDK open J9 image progress. If Alex Earl joins us, we may talk about Windows installer. We may need to skip it. Then we've got a general topic on broadening platform support and Google Summer of Code 2020 project ideas discussion that Oleg has agreed to lead. Any other topics we need to add, Oleg? I don't think so. I still need to catch up to use all the stories because I was busy with Jenkins Vault and other things. Bill, and as I'm reminded, let me put an action item here. Mark, create an EPIC because really we've, I like that we're using JIRA as a way to track those things and they justify an EPIC because there are multiple tasks hiding in the, especially this hotspot transition or adopt open JDK transition or progress. Speaking of EPICs, actually we could add one additional topic. Okay. Renaming of agent Docker images. Oh, yes. Yes. Let's put that. I'm going to insert that right here. So renaming the SSH, I don't know that you say the agent Docker images. Exactly. So it's a part of Jenkins 424286 then I'll add a link to the agenda. Okay. Okay. So I spent some time preparing Windows agents and SSH built agents plugins and finally I'm ready to work on the images. Great. All right. So noted. Excellent. Any other topics before we actually start working through the agenda topics? I don't know. Okay. All right. So on open action items, I apologize. I still have the open item to create a JEP for Docker operating system support and platform selection rules. Two weeks and two weeks and I'll report on it again. Oleg, you still got the item for a JEP for Windows support policy. Now maybe Oleg there, the governance, the next governance meeting, is it one week from now, two weeks from now? Two weeks. It's on January 15th. Okay. So next governance meeting. So it would be really, this is a good time for me to create a JEP because then it's a category, it's a catalyst for discussion in the governance meeting in about two weeks. Good. Okay. Yeah, we have a pretty packed agenda already, but yeah. Oh, okay. At least having these topics would be nice. Though, yeah, one of the things is the JEP process that governance meeting basically doesn't have say in the JEP process right now. The JEP process is based on BDFL not on the governance above. Okay. So for discussion, I would rather suggest using chameleon list. And if you need to sign off, then yes, governance meeting like we did, for example, for web browsers last week, last month. Got it. Okay. So discuss in the mailing list. I will do that. Thank you. And I'm going to put these notes under the one that I've got. It's the longest lived action item I think I've ever had in my life. So I got to get on it. Thanks. Okay. All right. We also had an action item on the Windows installer code and signing it with Olivier. Have you had any word on any progress from the continuous delivery foundation or whoever it is that needs to resolve our code signing questions? No progress. I'm about pinging them, but basically it's a Christmas break. So I wouldn't expect anything to happen until the next week. Right. Okay. All right. Thank you. Now I am proud to note one action item has been done. I for sure can confirm that I've now been added as a Docker maintainer. Oleg, you are also a Docker maintainer, right? All right. So what we did a couple of weeks ago, we created a new GitHub team which basically streamlined support for all Docker images. So all Docker images are currently managed by a single team, including Alexa, Mark, Nikola Dolov, Kiki, and maybe a few other contributors. So basically usual suspects who used to maintain images before. And regarding Docker hard permissions, basically, maintainers do not need them, but it's the same team. Great. All right. Well, I would say that they might be required, for example, if you want to introduce a new platform and other things. But they're not required in general because we have continuous delivery for images for release tags. Right. And so is that for my information, is the continuous delivery using the trusted CI? No. So all the agent images are being released from Docker Hub at the moment. Jenkins official master image is released by trusted CI. Right. Okay. And that is where the official master image was the long ago story about our needing to have much faster response time from in order to generate that master image in case of security fixes. For instance, very trusted CI. Okay. Well, basically the same problem applies to agents. Why we didn't move for agent builds to trust the CI is mostly because of the access because nobody from platform sec and from document engineers had access to trusted CI. Now the situation changed and we could reconsider it, but it requires some effort. Okay. You generally need to rebuild the entire pipeline. Okay. So let me make a note of the trusted CI also like the master image. Great. Okay. It's not probably, I think it should because it means in that place to security concerns. When you have a security release for the mountain, you need to cut images. And we had a lot of issues with it before. So I would rather completely rebuild the pipeline for images. Got it. Okay. So is that one where an Epic would be beneficial on moving the agent image generation process into trusted CI? I think there was a due to task for that. I'm not sure about Epic. So if you create an action item for me, I will try to find it out. Okay. All right. Because we definitely discussed it again when we were doing Java 11 support work, because we hit all the same issues there. Got it. Yeah. I'm not sure whether it's an Epic and even if it's an Epic, I'm not sure whether we have contributors already at the time now. Okay. All right. Yep. One thing which may require us to act on this topic is windows images, because right now we don't ship official images for windows. We have Jenkins file, which basically publishes it on Jenkins for a while. It's a valuation instance for Docker images. But if you want to ship official images, then we need to trust the CI because in the current state of Docker Inc, I wouldn't expect Docker Hub to support the Docker images. I mean, windows images. Oh, okay. So just to be sure I've understood what you're saying, and I assume the day will come when we want to publish a windows image in Docker as windows. You want to publish them now. We cannot. Okay. All right. And the thing that is needed there is trusted CI work, not work on Docker Hub. Right. So Docker Hub just doesn't support windows images. And that part surprises me because the adopt OpenJDK, OpenJ9 folks noted that Docker Hub now supports Series 390 and PowerPC64LE. So automatic builds or platforms because you can publish a platform. But whether you can build the image, I'm not sure. Okay. And that, I don't know the distinction of that. All right. So, but nonetheless, in any case, we would, we need the control that trusted CI gives us of publishing our own images. Right. Yes. Actually, we also need to stop sending images at some point because right now all the agent in images are not signed. There is additional metadata which is added to images. And right now, I would rather consider our images as untrusted. And the official guideline by Docker that you shouldn't be building trusted images on Docker Hub anyway. Okay. So the other thing, let me make a note of that, we need to build, we need to sign images after building them. Well, we do not need to do that, but it would be definitely an improvement for some categories of users. Okay. So we should sign images after building them for trust, security, etc. And that again is needs, certificates, etc., on trusted CI. Did I say that? Yeah, not on trusted CI, likely it will be another release environment. So, okay. He's working on a release environment for Jenkins images, on, sorry, for Jenkins code. And once it's ready, most likely you will have to move for the entire Docker delivery pipeline to that instance. Okay. So my understanding that it won't be a trusted CI anymore once the project is completed. Got it. So, all right, there we go. All right. So did I, did that, does that state it reasonably well then? Yeah, I'll add a link to the documentation. Okay. I spent some time to write a documentation for this environment in December. So I'm happy that I can share a link. Perfect. All right. At least I tried to share the link, but it doesn't get wasted. Oh, so I'm getting in the way. There we go. Yes. No, it's fine. It's an issue with my laptop, I guess. Excellent. All right. Thank you. So next topic, are ready to go to next topic from the action items? So next was the adopt open JDK hotspot transition progress report. I've got the action item to create an epic and I'll let me make a note of that. The Victor, Victor Martinez and I had gathered some rough notes on that transition process and talked through them and it feels like, it felt like to us, there's a lot of work involved in making that transition, but it's worthwhile. My idea was to take this as, I guess, a baseline for a JEP proposing the change. Is that the right approach to, because it's bigger than a single pull request as far as I can tell. Yeah, it's definitely bigger. Firstly, because it involves not only Jenkins, but it also involves agents. If you want to complete the transition, so it's at least five to six repositories involved. Secondly, all kinds of release pipeline and testing questions go into equation and also the transition approach, because you can just add more configurations. In such case, it can be a bit relaxed. But if you want to change the default configuration, then it becomes quite complicated. And I'm not sure what's our intention. Do we want to change the default? My initial thought was that we should change the default to insulate ourselves more effectively from operating system vendors breaking their JDKs. However, that's trading one form of breakage for another, right? If we get an imperfect set of packages inside the Debian image, for instance, and it's not the same as the old packages, and some user depends on it, they'll be broken. So I'm open to open to either. It's just, it felt like if we just add a new one, we have an even larger collection than of Docker images that we support. And I'm not feeling especially strong that, oh, that's the right approach. Your insights, what do you think? I'm fine with just replacing open JDK with adopt open JDK. If we do so, it has to be JEP, that's for sure. It has to be signed off in the community, that's for sure. And timing wise, it's better to do it after we finish core release automation. Right, right. And I think that given the amount of work involved, there is no way it could be done before core release automation is done. There's just, there's too much to do in terms of new testing, worrying about have we, have we determined the correct set of things that we need to include and does adopt open JDK have the correct operating system definition for what we need. You can still introduce the image itself at any moment. So yeah, we can change the default maybe see in several months, but right now we can add more configurations. Oh, okay. So if you want to start evaluation, it would be a good step. I do promise that you will get a lot of adopt them, but yeah, we invested some time in order to make changes more visible. For example, we have change logs for images now. You can also do announcement in social media, we can post a blog so that we start the evaluation. I don't expect, yeah, I don't expect any major issues with adopt open JDK to be honest. But yeah, if we can make the image available earlier, let's do that. All right. Yeah, so in the epic, then it feels like capture rough notes as, as tasks in the epic so that we've got them there and can progress, see its progress. Great. Thank you. One thing which we're smashing here that say, Jenkins, your larger defense on adopting open JDK even now. So with regards to testing, we're actually having base images on the top of adopting open JDK makes even more sense at the moment. Well, and I'm using adopt open JDK everywhere in my CI environment. I install it as a separate, separate component and it runs everything j Java eight Java 11. So I have not done anything beyond Java 11, but I've, I've been very pleased with the results I've seen. Excellent. Okay. Thanks. Okay. Anything else on the adopt open JDK hotspot topic? Nope. Okay. Next one then adopt open JDK new image progress report. So again, this one gets an action item for me to create. This one is just a new image, right? There is no, it is not a proposal to change the default image to use open J9. That's just too large a change. We have a pull request already proposing. We just need to do review of that pull request, get it, the experiments running, user feedback, et cetera. I think we can do it along this hotspot images. Right. Right. Right. Right. Good. Yeah, the question might be on this pull request. But yeah, as long as we don't modify the default image, I believe that we have a lot of freedom. Excellent. Thank you. Okay. Next topic was renaming the agent Docker images. So is there something that you would like to share with, share with the group in terms of that one Oleg? Yeah. So basically it's the same like other stories. So we have obsolete slave terminology and these terminologies still exists in official Docker agent images we should. So we have Docker, Jenkins slash slave, Jenkins slash SSH slave and Jenkins slash General P slave. So the suggestion on the table is to finally get rid of all of them. The problem is that is basically visibility because Docker half doesn't support renaming images and it means that if you want to do so, we will lose all the statistics, all stars, but the rest should be fine. Okay. So and so but if we is the idea then that we would actually abandon the maintenance of Jenkins slash slave or is it rather that it would there would just be a new image called agent and it would be maintained in parallel with with the old name and new name both being published as releases? Yeah, I think it will be two images at least for a while. So we already did the migration as a part of Jenkins to the zero. We introduced Jenkins, GitHub organization before that we had Jenkins CI. And at that point, we just recreated the images. So why didn't do renaming before is because in Docker Hub basically auto build was all in feature. And if you wanted to disable auto builds, you have had to recreate the repositories. That's why we didn't rename these images at that point. But right now we can do that. Even if we plan to move to trusted CI or to release environment later. But we can just disable auto builds. So it's a lesser of concern at the moment. And I attempted to press it with this change, even before we have a pipeline change or changes. Okay. And historically, we did a renaming once there is a blog post by Baptiste Matos, which describes the process. So we will do announcements, we will duplicate the old images and maybe in several months we stop updating them. That's it. Well, yeah, while Docker Hub builds the images automatically, it's not something we care about. I mean, at least practically it creates additional work load and additional cost for Docker. And we much appreciate that sponsorship. But technically we can just copy and paste configurations. Okay. So the non supportive renaming Docker Hub is not a big deal. It's just we've got to run our process. Well, we don't even have to run our process. We can duplicate the pipelines on Docker Hub. It's just a double amount of builds. I see. Well, technically we can just update the repository. We can create a new repository, for example, for slave images, where we just extend original base images, mark everything is deprecated, put the documentation. But it implies a lot of work. So yeah, if there is a consensus that we want to do it, I can do that. Okay. Not this month, but yeah, we can start planning it. Right. Right. This is another one of those that I assume needs, we need discussion. And like you said, we need a promotion, actively notifying people, blog posts, et cetera, that, hey, here's this change coming. We're really getting rid of this. We're doing more work to get rid of this obsolete terminology. Yep. Got it. All right. Thank you. Images. I just think it has to happen. Because it's visible. It's been consumed everywhere. If you like, quite some downstream changes, for example, in Kubernetes plugin and other plugins, which document usage of these images. Yeah. Something we can do. Right. Okay. Yeah. All right. Anything else on renaming the Docker agent? Windows installer with slide not here. I assume we just make a quick note that it's blocked waiting, awaiting code signing progress. Okay. Then we've got broadening platform support just to note that yes, we have PRs proposing CentOS 8. And I think this was actually proposing CentOS 8 replacing CentOS 7. I've got to double check that off to look at the PR. We have a proposal to add an Ubuntu image and then notes from previous meetings on the capabilities that are available to do platform builds in other projects in case we need them. All right. Last topic, Google summer of code. Oleg? Yep. So I'm not sure whether we have enough people to discuss this topic here, but the idea that we're looking for mentors, we're looking for project ideas. Last year, we did several projects which were related to platform seek, for example, plugin installation manager. So hopefully next year, we will also have some projects and we invite all contributors to participate to propose ideas. So Mark has already proposed a few ideas related to the plugin. But if somebody wants to work on docker packaging, for example, on whatever other topics related to platform support is definitely something we could do. And so I saw that you had noted the concern or you noted in the mailing list about the proposal startup process. I had assumed that I was supposed to start them by opening conversations in the mailing list. But I think you had a correct observation that the platforms or that the GSOC mailing list is a pretty narrow group. Can you give some more insights on should I be hoisting these conversations into the Jenkins developers group? For technical dive, yes. So one of the reasons is because GSOC is made in place for GSOC coordination, not for technical discussions. Another reason that Google summer of code is just one of the outreach programs we have. We also have community bridge. We have outreach. We may have other programs like Alibaba summer of code with summer who knows. So by keeping discussions in the developer mailing list, basically keep your options open. Okay, great. All right. So I will launch future discussions there. Those are good places to do it. Thanks. I just made the proposal because you followed the process. I just proposed to change the process a bit. I like that actually. I think that's a good insight. I would love to have more feedback and you're certainly right that there are many, many more readers of the Jenkins developers mailing list than the Jenkins GSOC project mailing list. So yeah, that makes a very good sense. Yeah, regarding project ideas actually had two project ideas in mind. One is about the future Java versions because we definitely know that Jenkins doesn't fully work on Java 13. So it could be an opportunity to have a GSOC project focusing on new Java versions. So and 13 has actually officially released now, right? But it's not an LTS. And I thought I'd understood that they'd said that 14 is not necessarily an LTS either. Yeah. From what I heard, the 17th will be the next LTS. Okay. But even if it's not LTS, it may worth investing in profitability and something else. Right. Right. For yeah, safety for an eventual, because we can predict that there is an LTS coming, right? Whatever version they choose, there will be one. And it will have, well, as an example, they've, they warned us at Java 11, hey, we're going to turn off certain things. They then had to back off. But I would guess the next LTS, they're not going to back off. And those, what were they, there's still a number of messages we get about. Oh, I'm embarrassed to admit it. I don't remember. Illegal reflective access. Yes. Yes. Illegal reflective access messages that those maybe they had warned in 11, hey, we're going to make these hard stop. And they backed off from that. But now in in the next LTS, whatever it is, they may say, nope, those are hard stop. And we need to get those fixed well before that thing releases. Well, it's yet to be seen. Oh, okay. But yeah, at least exploring these options would be nice. Yeah. So if there are contributors who are interested to lead this project, I think it would fly really well. Yeah, maybe another site of the similar discussion is about Grail VM and other native images. Because if you had a native image for Jenkins, it would be a really good improvement. So I did approach that for Jenkins for the runner at some point. But the Jenkins for the runner is quite specific. But if we could find a ways to actually use it, for example, for Jenkins agents to speed them up, if you could improve class caching in Docker images, then it would be a really feasible project helpful for the community. So can you give me some orientation on Grail VM? It really compiles to native code? It depends on how you configure it. Because basically Grail VM supports native images, which are basically compiled and packaged including Java, or they can just do dynamic stuff, which is much less efficient, but much more compatible. Okay. But so that would be, if it went all the way to native image, conceptually, then I'm sitting on an AMD64 box, and it's running native AMD64 code, not through the Java, not through the Java just-in-time compiler. Yeah, something like that. Okay. Basically, it's one of the stories which we need to consider if we want to make Jenkins cloud native at some point. Because Java is not efficient in cloud native application on its own. It's improved. It's improving, of course, but if you take projects like Grail, like Quarkus, they provide a lot of additional features which help to use Java in continuing environments. Right. Okay. So it's- Quarkus in this case. I'm sorry, what was the other? I'll write it down. Okay. I still don't ask Quarkus like Quartus. Oh, Quarkus. It's like that, right? Yeah. Got it. So it's not something that targets specifically, but yeah, if we have people interested, for example, if you could facilitate it through Red Heart, because Red Heart is one of the main contributors of Quarkus at the moment. Yeah, we could definitely have for this project. Though it might be a bit over-complicated for a JSOC student, but we'll see. Okay. I was able to run Jenkins for the run of Quarkus just to maybe a couple of things. Which is really, to me, quite surprising because with all of the things that were such a challenge in Java 11, in the Java 11 transition, I would have assumed those plus many, many more would be a challenge in something trying to run a native image. That's really encouraging. Well, Jenkins for the runner has its own advantages because you know what you are going to run there. So the plugin ecosystem is pretty reduced there. Well, you can run plugins in a classic way, but it just doesn't make any sense. So in my case, basically, I unpacked everything to play dependencies and then compile it to this standard Maven plugin. Okay. All right. Yeah, it doesn't have this deployment options because Quarkus can split image layers so that you can deploy classes quickly and other cool things. But in my case, it was just a big bulk native image, which worked. Thank you. All right. Anything else that we need to discuss there with regard to Google Summer of Code? Yeah, we probably all said, I think, start-up time as a project. Oh, okay. Well, and I know we had talked, there would have been earlier projects and they're already on the list, aren't they, for log storage, for external log storage and... Log storage, no. We have fingerprint storage as a project idea. But yeah, I'm not sure whether it's going to proceed this year. It's in the draft and basically if you want to deliver on that, we need potential mentors. Okay. So external fingerprint storage is there. Mm-hmm. And there was the external storage project that had been attempted for external job storage or for external logs? No, we didn't have such a project. No. Okay. We were discussing them, but basically it down to lack of mentors. Got it. All right. Thank you. Okay. Any other topics on Google Summer of Code 2020? So if somebody has any ideas in mind, please submit these ideas and the projects can be quite complex. So it's not that we are looking for new different issues to address. This year, for example, we delivered features like login installation manager, we delivered the GitHub branch source, which are major features very important for the Jenkins community. So let's do the same of this year. I like that. I like that very much. Thanks. Okay. So I'll erase this topic again next week. Great. Yeah, let's see. All right. Thank you. That's all that I had. Anything more from you, Oleg? No, nothing from me. All right. Then let's call it done. I will stop sharing archived recording. That's called the meeting done. Thanks, everybody.