 So hi everybody. Welcome for this new Jenkins infrastructure meeting. We don't have a lot of topics to the agenda. So yeah, we'll just do a quick recap of the main thing that happened over the last week. So the first one is I spent some time to fix package Jenkins.io machines. So basically what happened is one years ago when we upgrade from open to 14 to open to 18, we had to upgrade multiple packages. And MirrorBrain, which is the tool that we use while our mirrors was not packaged for moon to 18. So Tyler made a specific package. And so we were missing some dependencies. And so the open source project is also maintaining a specific open to repository for MirrorBrain. And so I just upgraded to the latest version available on that repository, upgrade PostResql. I made some improvement on the database and Apache to increase the number of connections. So now everything seems to be stable. And the response time of the update center in package Jenkins.io seems to be stable since last week, which is a really good news. So it means that, I mean, it's not as more, it's not anymore as urgent to work on that machine as it was last week. So I'm going to leave it in that state for now. The other major thing that I did was regarding LDAP for the Jenkins.io. So we were using a certificate provided by Namecheap. That certificate expired last Thursday. And so I switched the certificate to Let's Encrypt. The major change here is that the LDAP will have to read, re-read the certificate every three months. I'm not sure yet that the current configuration supports how to reload, so we probably have to reload to restart the container every three months for now. I mean, this is the current, yeah. Just set a cron job that deletes the pod every two months. Yeah, that's what I'm thinking because I'm pretty sure that, oh, so no, the thing is that it's running, so the LDAP is running on a pod. So I was more thinking to configure a liveness probe like the certificate is expiring less than a month, just keep the container and restart a new one. But yeah, that's the main thing. But at least for now, yeah, means that we switched to Let's Encrypt. I did a bunch of tests. The only places where LDAP client was broken was on the account app, I think, but accepted that everything seems to be working fine. So that's good. Any question so far? No. And so the last topic was, which is the last topic that I want to talk is regarding the automating Jenkins releases. So I had a few discussion with few people and bigger one with Daniel. And so basically we discussed about what we would need in order to release security releases from the new environments. And so basically the main requirements are being able to promote artifact between map and repositories because the security work implies that either the you, the work with the security team or with contributors. And so usually they maintain a specific branch and they have specific artifacts. And so they want to be able to promote from a specific repository to the official one. Another limitation is that we need to be able to merge the code, but not between fork but between different Git repository because they are using a specific private Git repository for the security work. And so we need to have some kind of Git promotion between the Git repositories. And so yeah, so the two main thing that you have to implement are basically promotion between a specific release to the security one. The good thing is we have until June, I think around June to finish that work. So yeah, it gives us some time to plan that in advance. So I created a bunch of G-Ride ticket that are related to this. I can put them to the Google notes, but yeah, that's pretty all. Any question on this topic? So yeah, so that was pretty old. So the last thing that also moved on the infrastructure and this is more related, this more some work done by Alex and Mark. So they also added the S390 architecture and the PPC-64 to see how the Ginkgo.io, which means that we can also start working on those infrastructure and build on those. We can also build on the ARM-64, I've tested that with at least a plugin build. So that works as well with the Amazon. That's perfect. Right, and I'm actually using it now, I think in the platform labeler. So series 390, S390X, PPC-64LE, and ARM-64. Did the update to the build plugin fix the issue where it was not being assigned at the actual nodes? I've got a double check, good question, Alex. I think it did, but I'll have to double check. Okay. Okay, so I accepted this. Do you have anything that you want to bring to discuss now? There was a couple of failures in the incrementals. It'd be good to get access to the logs so that I can see if there's something that we can fix to make it more stable. Which looks? For the functions, I can see the function, but I can't see the logs. Sure, I'll do something that I can give you, access. And Olivier, I'm preparing, one of my goals for this week is to submit the changes, the tests that I had written for automated release packaging checks as part of the standard build, but I can't see the definition of the build process. Are we building off the master branch or off the Infra910 branch when we do a release build for a weekly? So right now we are using the branch Infra-9900 something. So we are not using the master branch. The main reason to this is because because we can still rely on the master branch to release stable, so that's why. So basically we merge all the changes to the master branch once we are fully managing all the releases. Yeah. Great, so I'll submit the pull request to that branch. That's great, thank you. Yep, that's all. Otherwise, so yeah, Tim, I will look for your permission. You should have access anyway, so maybe I did something wrong. I'll check after the meeting. And otherwise, if you don't have any thing that you want, I mean that you want to discuss here, I propose to go back to RC and close meeting here. Thanks for your time. Bye bye. Bye. See you. See you, thanks.