 Hi everybody, welcome for this new Jenkins from meeting. We have few things that we have to discuss today. So the first one that I want to announce is that Fastly will sponsor the Jenkins project. So they will give us $1,000 credit per month that we can use. So the good thing is that we can use it for our website, like Jenkins.io, plugins.io, documentation site, and so on. What I initially wanted to use it also for the mirrors, I don't think we'll have enough credit to do that. So as a first iteration, I just proposed to work with the people involved with Jenkins.io in order to enable the CDN for that. And then we just add more websites one by one. But yeah, so basically, the sponsoring is secure for at least one year, and then it would be automatically renewed. The only thing right now is, so I got approved for the sponsoring program. The only thing is, I still have to find the correct Fastly account, because apparently my account is not, I don't have the credit on my account, but it's something that I'm trying to solve with Fastly support. But yeah, that's a really great improvement, and I'm really happy to share this. So if you are involved and you want to participate, I can also add you to the Fastly account so you can also have, I mean, I have access to the dashboard of configuring that stuff and so on. So that's regarding Fastly. I don't know if it's me, but each time I move to automated release at the end of the meeting so I can keep you busy and keep you during the meeting with someone to systematically quit at the second level. So I will just put this in our. So it's the question regarding Fastly and using a CDN. I mean, I hope that you all know how it works. So yeah, but basically it's just a tool that's create a copy of the website on servers closer to where people are located. So it drastically increases the speed of the service. And so we don't have to replicate the same. So it will be really interesting I think for people in Asia as they are quite far from Jenkins.io websites. But in the end, it would beneficiate everybody. So that's a great move. So the next topic that I wanted to discuss was and it's kind of also related to the automated release, but it's who has access to the Kubernetes cluster. So right now, in order to deploy a new application, you have to go to Jenkins and press dash charts. I mean, everything is explained there, but you define using hand file the application that you want to have running on the Kubernetes cluster. And everything is going there. Until today, I was the only one being able to run kubectl command. So I was the only one to be able to, let's say, delete the ports, restart the content or whatever, if something was wrong, what's happening. And so basically I decided to add two new people, one of them is the team Jacob who helped a lot with the Kubernetes cluster since several months now. And I also asked Marty Jackson to participate. So the idea is to review how the configuration of the cluster and make suggestions about how we can improve the process and how we can make it more secure. So yeah, that's the main and change there. So if you see anything interesting, please feel free to ask. And yeah, thanks for your help here. While I was also working on the Kubernetes access, I also did some work on Azure. So I also granted access to Marquee and Team Jacob on the Azure access. Right now it's mainly Azure function for Team Jacob and Kubernetes project for Team and Marquee. So I put in place a process so we can add more people depending on the service. I will just try to keep the number as low as possible. So if you really need to have access to the Azure account, I'm really glad to give you, depending which kind of access you ask. And then once you don't need those access, I really invite you to mention that and say, okay, you don't need it. So we can, let's say for example, disable your user account. So it just renews the risk of having someone accessing the account. But yeah, meanwhile, I did some work on having more people on the Azure accounts. While I'm talking about the Azure account, there is also a, I'm not so funny, but we are having some issues with the Amazon account provided by QHDs because the sponsoring was approved by Amazon was for some reason assigned to other QHDs accounts. So we are currently investigating why the credits, I mean, why the credits was used by the other services, the other accounts, and we'll soon find a solution. But yeah, this really brings, this really highlight the fact that we need to move the Amazon account to the CDF, as it will simplify the management of it and it will be clear what it's, what it's, the Jenkins OSS and what is this in this case. But yeah, we thought that it would be easier and quicker to do it work this way, but we may, maybe we were wrong, but yeah, this is something that we have to solve now. Any question until now? So I will just continue. So otherwise, as you saw on the RC, the main activity has been working on the Jenkins core automated release. We made a lot of progress and we are quite close to the final solution. So just a quick overview of what we did. So regarding the release process, so really releasing Jenkins, not packaging, but releasing Jenkins, we had additional steps to really visualize which certificate we are using to sign the WAF file. So now if you have access to the release you have access to the service as long as you are in the VPN, you can double check that we are signing with the red certificates and the right GPG team and the next part is working in the packaging part and in this case, we are so as a reminder, we are packaging right now for Debian, Red Hat opens use and Windows and so the idea is to build a package, to sign the package and to publish the package. The main work now is first, but it did that we are publishing the package in the right location. So for that we deployed a virtual machine, a copy of packages in the radio and we are publishing packages there, checking that they are currently signed, they contain the right file and so on. We are almost at the end, I think the last time I checked, we only show us with the Windows packages, but it's something that will be fixed soon. Otherwise, the main other area where mainly Mark is still working on is to test the release process. So we have different things that we can test here, we can test that we can correctly build packages. For that, I have the code composed and I have few scripts that I have to put in a Jenkins file so the idea is to be sure that we can test the different packages, we can sign them with a DOM certificate and a DOM GPGT. And the next step is to test that we can also install the generated packages in different distributions. So for that, Mark opened a PR and so basically was able to test for Debian Ubuntu, it wasn't possible to test for CentOS because by default, CentOS does not allow you to run SysMD inside container. Am I right, Mark? You are muted, Mark. You are correct, but I took the added step of putting an install test for CentOS and for OpenSUSE without a test for services. So it can do the install without SysMD and it can then use the RPM verify tools to check the thing. So that piece we're doing, it still can't check that the services start and stop because CentOS Docker images and OpenSUSE Docker images don't by default provide SysMD. Okay. So one is not a blocker to go live with the release process. This is something that will quickly stabilize for the modification for next iteration. But yeah, that's not a blocker for now, but if you have some time to review those pair, we'll put some link in the document after the meeting. If you have some time to review and you want to help on those tests, you can automate those tests in either CI or the release environments. But also either in CI.jntl.io or release environment or somewhere else, which makes more sense maybe. Yeah, that's the right moment to say. So on my side, the next step will be to document a few things like what it looks like to, I mean, what are the different steps to release, basically where you're supposed to go, which button you're supposed to click and what are the things that you have to verify in order to be sure that everything is working well. So once the documentation is written, we should be able to really update the different credentials in order to go live. So just to be clear here, the different credentials that we decided to not put to still use temporary credentials are the SSH key used to upload packages to packages in CI.jntl.io. So in the current state we want to be sure that we don't accidentally push our testing packages to the real prediction server. We also have to define to specify the Mavin repository that we are going to use for the release. So basically we just have to grant permission to the current user that we can clear for the release. So SSH to upload files to the Mavin repository and I think it's pretty old. Maybe review some settings but do something that needs to be highlighted in the documentation. Is there a question so far? Yep, so I can continue. So one of the things that I've been asked to Marty was to review to have someone else who did not work on this, I mean who did not work a lot on this part, to have some external eyes and so we can just try to see if everything seems to be fine, secure enough. And so Marty now should have, when it has some time we'll have, should have all the permission to audit the release environments to make suggestions. So we won't go live as long as we don't have green lights and yeah we work in the process to have as many review as possible but we're all getting closer. I will be setting up an audit documentation an audit spreadsheet that I'll be performing the audit and I'll share it with I'll share it with you and then you can decide who else should actually see that audit I do think it'll be good that once we do a cluster audit we publish it and sort of say you know what we found transparent but I'm going to leave that up to you. So basically to me the rules will just be like for the document that we set up to take notes so whoever is interested to participate can read the document but as long as we don't go live we do that. Got it. And that's pretty old thing for me. That's yeah that's that's old for the Jenkins Core Automated Release so do you have any other topic that you want to bring or you want to discuss? I mean if you're all good then I think we can close the meeting earlier. So one time two time thanks for your time and see you on our scene.