 Hello everybody. Welcome to the weekly team meeting for the 22th of October. So today we are Olivier Hervé and Hai, it seems. No mark, my turn. First of all, no announcement yet. Nothing up on the planning weeks. So let's jump straight to the operational parts. First point, AWS cost management. So thanks Hervé for managing the high meme labeling issue. So now, some label convention on CI, the Jenkins that I have changed. The goal was that we should not use high meme machines that are beefy and cost really expensive machines when you only want to build a few Docker containers. So thanks for that work. We are not seeing any costs change yet because it has been applied only recently, one or two days ago, to remember correctly. So let's wait for next week and next week we should be able to compare the past week in terms of costs. Something else that came yesterday is that team detected that the current GVM options that are used for some acceptance testing on Jenkins core, even though are using high meme machines, which are 64 gigabytes, there are still parameters for a gigabyte machine, which means the tests are slow compared to most of the developer laptops. So we should be able also to improve the speed of these builds, leading in less using these machines because they will be released and stopped sooner. Next step regarding the cost management, the two elements we have identified that could be highly valuable for us are configuring CI Jenkins IO to use spot instances for the AWS instances. That's supported out of the box. There is an issue for that. And we started to work on digital ocean. So we entered that LV, Olivier and I, we all have access to the digital ocean account. And we have asked our partnership to apply the credit so we can start straight away. So on that topic, I received no response from digital at this time. So yeah, we are still waiting for the credit. Okay, we could bump gave in maybe later today when he will be awake just in case. If we don't have answer, we can still start creating another cluster on those usm machines. That will be another topic. But that was not identified as a priority for now. Regarding the transition of the account. So based on the feedback from the club is it, it sounds like we won't have to migrate the resources, which is a good news because that will be less effort. At first sight, that should be only accounting and billing changes. So worst case, we might lose the access for one or two days on the AWS console. That will be the worst case scenario. That means we don't have to plan now immediately for that change to migrate and create new virtual machines and migrate data and all this tedious stuff. Do we already have an estimation date for that migration? No, we have to reconsider that. Cloudbees asked us to do that as soon as possible. I have to, that's on me. I have to propose a date. The proposal would have been end of November. So it lets us some time to decrease the cost still to be sure we are safe. Okay. The first step of the migration does not imply your risk financially speaking. That will happen when, so we need to first transition the account, then ask AWS to apply the credits and then let the CDF take control on the last step. The last step will be critical. Any other question on the AWS cost management? That sounds good to me. One, two, three. Okay. Next subject. We have to upgrade the NGINX ingress on AKS. So the bots proposed some things in some time. And so we had to work today on that one. So the plan is that RV and HI plan to do that Monday, Monday afternoon. Statues will be updated in the next hour to tell the users and I will send an email to the Jenkins developer. We should not expect, based on RV's research and the double check we did, we should not expect any service interruption, but still better to have a notice for the users just to be sure. If something goes wrong, we might have the services being cut, all the services could be services hosted on AKS that could be cut for a few minutes. No data loss if it's the case. Yeah, that's a pretty critical component. Yes. And upgrading it is usually really smooth because we have high availability on the NGINX controllers. However, here we are speaking about changing API implementation for defining the ingress rules. So that one was a big thing on the Kubernetes cluster. And so it's just that we have to prepare us correctly because the migration path is not really smooth to be quite honest. Whatever ingress controller you choose. But based on RV's research, it will be easier as initially anticipated. For reminder, the value of that is to ensure that we have the latest NGINX version running, which is really really critical for us. And the second reason is that we need to upgrade to Kubernetes 1.20 soon. So that is a mandatory part for that upgrade. Any question about the NGINX ingress 2.3? Okay. Issue, triage, nothing to say. We did a big effort this week and the past weeks to clean up and remove all the issues. So yeah, if you continue to see all the issues that seem like either an error of Jira project and that should be migrated to the Jenkins project or that should be closed because not up to date, don't hesitate to wait and close it with a message so we can clean up and start working again. That's all on that part. Is there any question about issue triage on Jira specifically? Okay. This week, a bunch of work has been done on update CLI. So thanks, Tim, for trying using it on the BOM update. It sounds like you underlined some use cases that we have to fix on the CLI side. Olivier and I worked on fixing some things that were not blocking but making us lose time on the usages we have on the platform, especially on updating the backer images for CIG and Kinsayo. There is still some work regarding changing files. That's a weak point of update CLI ability to change a specific line based on a pattern or line number. That should help and add way more use cases. So we spent some amount of time this week since we did not have something really critical. So we took the opportunity to work on that part. Thanks, Olivier, for waiting on the update CLI PR. On that topic, I identified a very nice library that I could use to also handle XML files. So I'm almost really there. So that could be a good use case allowing changing XML if you want to keep track of dependencies inside BOM XML. So that bunch of the project we have on both Jenkins and Jenkins infra. Is there something to say that that could forgot or any question about the updates CLI work or usage on Jenkins infrastructure? One, two, three, okay. Last object I had in the list for today, CIG and Kinsayo. Since one week we have Maven 3.8.3 released on all the VM agents that has been done transparently next to the usual Git updates and JDK updates. There is a pull request for the Linux containers that should use the new Maven 3.8.3. And there is still a pull request to be made on tools, but usually we update VMs and controllers first. And once it's okay, then we can update the tools because the tools is for the fallback situation. Thanks, Tim, for the work on Azure VM plugin. So it sounds that should fix the BVO we had since the past weeks where after applying a change on the Azure VM configuration, we had to use the UI and click on save configuration, which is not really infrastructure as code compliant. So we have to confirm that though. I haven't spent that much time on this, but the change applied this week were applied successfully. So we assume that it fixed the issue, which is really cool. And finally, a not thanks survey for notizing that some of the labels were a bit shady, such as the window label for the agent, which is hard to understand for newcomer. So yeah, as part of the IMM labels changes, the window has been changed to follow the same convention, which is I mean docker-windows is a bit more understandable than window for me personally. So I really like this change. It's really minor, but still, it's a good way to allow newcomers to not feel lost on that area. And I'm not even speaking about the bunch of documentation update that Hervé did this week. So thanks a lot because Olivier and Hervé are too lazy for that most of the time. Is there anything that I could have, that I forgot to speak about Cia, Jenkins, or any question? So as far as I can tell, the tools, the Java, for instance, is now hard-located slash op slash JDK dash X and similarly at the root of the Windows file system. Thanks very much. No more tool installers, no more downloading 100 megabyte installer every time we need an agent. Thanks. We still have kept the older downloads and I think that will be good to keep them as a fallback though. And the pipeline library has been updated to use them as a fallback. So if there is no Java installation working, it should be there. However, the recent Jenkins score issues that we have to fix on the pipeline demonstrate that the pipeline library still has a long way to be improved to not break builds when we change the location. There is still a hard constraint on that part. Thanks Marc. So that should be okay. I think we can go to the meeting time for the next meeting. Yes. So that's the last point that I would like to bring. For me, Friday is super difficult to be available on Friday. So I opened a poll. Apparently, you all completed the poll on community Jenkins and I also put the link in this document. It sounds like Tuesday is the best time for everybody. So I propose that we don't have a meeting next Friday, but the Tuesday after. So the next meeting is around 10 days, something like that. On the 2nd of November, 3rd of November, if it's okay for you. So next week, but the week after. That's an excellent choice for me. That's the day prior to the next LTS release. So great place to check in. Be sure we're ready for the LTS. Yeah, for me, Tuesday is one of the best days because we have been here. So yeah, thanks everybody. Cool. We'll run starting next Tuesday since we will have the Ingressing Unix controller at the next Monday reporting that upgrade Tuesday, even if it's a quick one, but just to start it and avoid having too much time between two meetings. If it's okay for everyone, of course. Yeah, that sounds perfect for me. So that will mean next Tuesday, is that correct? That will be the 26th of October at two past 30 UTC time. Yeah, I'll choose the 26th of October. One is the day light same time in the U.S. Because I know that in Belgium, it's on the 3rd of October. Since our times are scheduled in UTC, I think we can just ignore the United States meddling with clocks and just stay with UTC. My concern is just for the people to remind that it's on UTC time. Yeah, that's I think you're perfectly fine. We should just a good reminder. We are UTC time and government should quit meddling with clocks. Thank you very much. So I have to update the calendar. Sounds like we cover all points. And Olivier, I'm in my calendar now. Are you okay if I just do the change right away? That's perfect. Okay, so beginning next week, the Jenkins infer team meeting moves to say it again. It was 26th of October at 2.30 UTC. 26 at 2.30. So 30 minutes later than the current time and it is UTC. We're set. Thanks everybody. So it sounds like we are good. Thanks everybody. Is there any last question, last remark, team Mark Rvé? Cool. So have a nice weekend hall. Take care.