 Hello everyone, welcome to the Jenkins Weekly Infrastructure Team Meeting. Today we are the second of April 2024. Around the virtual table we are six persons. We have myself, Damian Duportal. We have Mark White, Stephen Merle, Bruno Verarten, Kevin Martin, Sander Wilmer, welcome everyone. Last week we cancelled the meeting due to an update center outage, multiple outages. We will get on these outages later with the issue replace BlobExfer by AZ Copy. So here we are, we have two weeks of work from the past milestone. Everything has been updated. So last week, the weekly release 2.451 has been released in time, except that the packaging part once finished had to be cancelled and the last steps were run manually. And then due to the update center outages, which was the cause of failure or blocker, we had to wait around two hours before everything went back to normal and was available on all mirrors. Sorry for the inconvenience. But that release was released in time, and Stephen, or as I don't remember, was able to update infrascii and it was visible for everyone. Is there something about questions, comments, things I could have forgotten about last week release? Nope, okay. So about today's release, everything worked release and package at the first time. However, we had issues with the Docker image. Windows images were at the first try, but the Linux port are still having issues with Docker Hub. So I've sent to Docker a second email because we never had any answer on the first one to the open source team. I'm a bit worried because I saw that the open source product manager has left Docker two or three weeks ago and Bridget, our contact is currently seeking, is open for work on LinkedIn last time I checked. So I don't know what is happening at Docker. I'm going to try with other channels because we don't get any answer by their email challenge, but we need a careful high here. I will add an announcement or a point, a specific point for the Docker API rate limits after. Back to today's release. Now everything is ready for the Docker port. The changelog has been published. Thanks everyone. So we are ready to roll that new weekly release, Stefan, as soon as you are able to, today, tomorrow, and that's all for this announcement. Is there anything else about today's weekly release specifically? Nope. Is there something about the Docker rate limit? No. So on the weekly release, the process works smoothly, smoother than it's been for a number of weeks in terms of a number of disruptions and nothing for me to add on API rate limit. Ok. So the reason why the packaging step is not failing is because the probability of the packaging steps running the SyncSH script and in concurrence of the update center, both scripts are sometimes running concurrently. But now with the changes that has been done with the easy copy stuff, the Sync.sh went from around 15 to 20 minutes once per hour to less than two minutes. So the probability of both things running at the same time has decreased. It can still happen though because the date center runs every five minutes. So we can have collision. We will need to improve the way it's working and specifically we will need to focus. But at least it's why it worked today. Just to have in mind that things have been improved and are going to improve later even more. About the rate limits. We have HTTP for since March. It impairs our ability to deliver Jenkins images. Core, weekly LTS and security releases and agents. So every docker images we are delivering to our users. We have to retry a lot of time with replays specifically fixed on either Windows or Linux. So even if we have increased our amount of images, for instance, we have less 222 windows images on SSH agent recently. We have new GDKs new CPUs that has been introduced by Bruno S390X out of preview, etc. So we increase the amount of layers that we are pushing during any of our images publication. However, we should not have any rate limit at all. Not sure why. We also had a change one month and a half ago where Trusted CI in charge of that publication had the network changes when it was migrated to the new Azure sponsorship and we only have one outbound public IP because we use the NAT gateway to avoid unnecessary network problems. There might be secondary rate limit on docker hub un document. So as such the rate limit which is happening today is clearly related to the outbound IP. Trusted.CI only has one outbound IP. So why I am mentioning that outbound IP because we might have a quick hack to do right now that will be adding multiple outbound IP to specifically Trusted CI gateway to spread the request. Maybe that will push the thresholds when we hit the rate limit that should be quite easy to do just a few bugs per month that could allow us to not having this issue in short term in autonomy. However we need an issue the problem is not ephemeral ephemeral and second email to docker OSS program waiting for an answer. We need feedback from docker. I propose that we don't start planning solutions for now and we wait until next week. If next week we don't have any answer from docker we will have to start brainstorming on the alternative we could have if the multiple IP solution doesn't work. Is there any question things to add of no discussion points on the docker rate limit? One last announcement Jenkin Sinfra is not Sorry Damien I take it back I do have a question Yes I assume that if we had to fall back to providing container images through additional providers we could it's just a bunch more work I know that Bruno has been providing container images to Google to get hub if I remember correctly there are other container hosting services not just docker it's just all of our users are certainly using docker today using hub.docker.com That's the part I don't want to discuss this week I just want to postpone the discussion because that can implies a lot of changes for end users For us it's easy to do it's not a lot of efforts but for end users that might be a lot of efforts So that's why I would want to get this one just as a last resource and last week we will have a platform SIG meeting after our info meeting so if we need to start the discussion I propose that we bring that topic if need be to the SIG platform meeting SIG. Is that okay for everyone? Any other questions or pointer? No other questions from me, thanks One last announcement We are not affected on the Jenkins infrastructure by the recent CV Exit That happened last weekend Yeah It's a good thing to stick to LTS version so you are up to date but not too much On the age at least for Linux distribution may have consequences such as being affected However we have checked all of our images we are all using Exit 5.2 which is a version released before the infamous Chia Town started to commit on the project so hopefully we are not affected On the Jenkins let's say Docker images we have one image affected but not exploitable that's the Alclinux Chideka 11 Docker agent image It doesn't have SSH neither system as a matter of safety we have released a new version just to be sure other than yep So it's an intentional choice only Java 11 and that container image will be dead beginning October of 2024 when we drop support for Java 11 Yep Arch Linux is not a long term platform for the Jenkins project Absolutely Any other questions? I had to destroy four virtual machines where I run Debian testing and Debian unstable that I use it for testing but it's easy to destroy and recreate and I did Just for information if you want to check if you are affected or if you have a do not run exit-version at all if you do it install a Trojan horse if you have an affected version in your machine Yes Yes, that's one of the commit from Deatang So the recommended way is to locate where is your exit binary installed with command-v exit or which exit and then you run the bash internal strings command on that file and you grep on the version or you look at the packages engine such as dpkg-l pipe grep exit or pacman-q grep exit etc Don't even run ldd if I understood correctly Absolutely don't That also open a lot of other backdoor Honestly, the upcoming weeks will be fun because now people are looking at what's that user, which is clearly not a user but a group of persons with bad intents what did they do on different and numerous open source project during the past four years and for sure we will have surprises in the upcoming weeks so Everyone be careful, communicate only privately if you see new things before the order don't use the Jenkins Infra channel please use the private security channels if you need something or if you detect something on the Infra and we will keep the virtual machine and packages up to date a bit more regularly than usual Yeah, I am curious where you learn many of the sites are still saying check your version with xz-minus version so Good to know not to do that Thank you There is a mention on the initial open-wall article where the Microsoft engineer would discover the problem said oh, I see don't run ldd and don't run the dash-dash version on the initial posts More and more posts are telling people not to do it Yeah, that's a tricky one Something else on xz Other announcements Nope, okay Okay, it's 20 minutes Yeah, I'm trying to accelerate Upcoming calendar We have a weekly next week 9 April that will be 2.453 Tomorrow we have LTS Release Candidates and in two weeks 17 April 2024 we will have the next LTS Wednesday We also tomorrow have LTS baseline selection Oh Next LTS baseline tomorrow Right And as far as I can tell 2.452 looks very good because the preceding 8 or 10 weekly releases showed no issues and therefore choosing the most recent is look safe Nice Do we have an un un Securited Redancer is no So Is there upcoming event where we will have Jenkins contributors or Jenkins Infra contributors Yes, CDCon is April 16, 17 and 18 in Seattle, Washington and Basil Crow and I will be attending Basil Crow Nice Sorry, it's CDCon Okay Other events Question about the calendar Nope Okay Just a quick summary on the cloud budgets because we are beginning of the month I've had Azure we have clearly decreased Azure consumption in January and we are around 4.2K per month that's the current consumption more or less a few bucks so let's keep that consumption steady we have so the work of survey on the storage accounts on 200K but we consume 200K more on other areas so it's a neutral operation but we can keep that on a steady thing which mean as per the projection if we keep that consumption rate we should be able to meet to go back on the expected average provided by the CDF in September which mean last trimester of this year should be only bonus so if we keep with the same consumption we should be below what's the CDF expect from us for this year it's a bit early to tell them but right now we are keeping this steady Is there any question on this one? No congratulations, thank you thanks to everyone for keeping us in budget it makes things much easier in discussions with CDF thanks everyone for the effort here about as your sponsorship so the new account we've set up last year we have currently 32K credits left we have consumed almost 7.5 we have an almost steady rate of 2K per month we could increase that consumption on some elements but we haven't looked at this yet I believe that one is good enough for now we can lower it too with the spot instances if they are lower us too yes but right now it's free credit for us so I propose that we don't focus too much on this one we keep a steady consumption for now and we'll see later we can increase the usage because these are virtual credits so spots are not stopped but no problem and also we have limits on the credits these credits are only available until a certain threshold so we might have to check in 2 or 3 months if we don't need to increase suddenly or ask Microsoft to make these credits expire one year later thank you so you just answered my question do they have an expiration date and the answer is yes and we will double check that we're burning on the expiration date that we won't leave money on the table money unused but we'll do that next time we meet, great, thank you c'est ok for you Stéphane relative to the spot instance I'm sure Stéphane will be able to consume way more credits soon with RM64 oh yeah with pleasure don't worry on Claude B. Sparks so in February we were able to decrease the usage mostly due to less bomb builds but March has had a lot of bomb activities so of course we saw an increase here we've seen a few a few bomb optimization that could happen but the goal here is to decrease or and eventually suppress that consumption in the upcoming trimester with 2 main elements the migration of the update center on Azure and mirror bits on Cloudflare and also we have a new AWS sponsored accounts that we should start to use specifically creating a new cluster for CIG in Kinsayo moving the bomb workloads out from Claude B's into the new sponsored AWS account right, we need to connect, there is an issue about this I'm a bit late on that topic the priority for the upcoming 2 weeks on my side Word on Digital Ocean we still have 17 1000 credit left as for today the rate has increased in March because with the ACP work and the amount of builds were able and the Kubernetes upgrade we started to use the Kubernetes cluster on Digital Ocean again so clearly compared to February 300 credits which is good because we are consuming credits and without bad surprise I didn't add it the other cloud budgets such as Fastly or those because they are sponsored if you want I can for the next time don't hesitate to send me a message about this so we're well under the donation that Digital Ocean provides of 20 000 right? at less than 1000 a month we're doing just fine we could actually consume more on Digital Ocean to, if that made sense absolutely that could be an alternative for data intermirrors or other solution if we need to move things away or if we reach the end of AWS credits that we need to migrate somewhere else these credits do not expire so that's a good thing any question on the cloud budgets Ok, on a fait beaucoup de choses, on va essayer de l'enlever comme rapidement possible. Tout d'abord, je prends un démon sur l'ordre sur la table. Les tokens de CloudFair API sont expiés, donc on a renouvelé les tokens et tout est retourné à normal. Cela a eu un impact durant les 24 heures passées pour la notification du calendrier. La prochaine fois que l'on le voit, c'est le jour prior de l'expérience. Je pense qu'on doit faire la même erreur. Tout le monde est concerné. Chaque fois qu'on crée un nouvel calendrier, nous avons un petit démon sur ce que nous faisons maintenant. Et la plupart du temps, nous devons penser à ajouter une notification de 3, 2 et 1 week. C'est tout. Il y a été un command de spambot. Merci pour tout ce qu'on a fait. Il y a été un nouveau plugin. « GUnit plugin fails to download and causes Jenkins setup without to fail. » C'était la conséquence de l'autre week outage. Cela a été fixé. Merci pour tout le monde qui l'a reporté. Nous allons se couvrir durant l'outage. « Latest commit pour contributo-spotlight not building properly. » Je pense qu'on a expié le credential. Je vais juste vérifier. Non, c'était une restriction de network. Et depuis qu'on a migréé les agents de contributo-spotlight de l'un type d'agent de l'autre qui a changé la network. Ces nouveaux agents n'avaient pas le droit d'ajouter le file storage. Nous avons évoqué la limitation pour l'application de la network. C'était fixé. « Inexpected content in get Jenkins IOPlugin same update center outage that has been fixed. There was a Git repository to recover. They can overbuy the Jenkins CI GitHub organization administrator. Same un archiving Jenkins CI DOM4G. Another spammer. Thanks again for clinic GitHub. Last week we had an LTS 2.442 that was successful and successfully applied to the platform less than 24 hours after. Third spam bot, ok, that's a lot of spam bots. We had an almost expired service principle and we were able to rotate it. That one was used by Infrascii to create new agent on Azure that was taken soon enough and changed with success. So, good job team. We start to have a good rotation procedure. Jira specific operation. Thanks Mark for helping me on this one. Permission for Jenkins security scan repositories. We had people from the GenSec team needing to access this. So, we were able to create to add them to the Jenkins Sec team in Jenkins Infras. And now they have the expected permission on the repo. So, no more action here. Une expected delay is building small plugin on Linux agent. So, that one has been closed because since the new ACP 1.0 I will also describe this later on the work in progress. But we saw that in fact the delays were mostly due to digital ocean agent running in Europe. And the Maven central repository is on the US east coast. And the delays and slowness are because we had to redownload a lot of artifacts through that link that creates, yes, 8-12 times slower. And we can reproduce it for assaults us in Europe if we don't have Maven central cache. It's clearly slower than for American colleagues. And there is no dual replication of that one. So, if you are in Europe or in Asia you should have a Maven cache running on now that will clearly improve your Maven builds. So, that has been fixed thanks to that under a recent Kubernetes upgrade on the CP to run faster. So, thanks everyone because everyone was successfully key on that one. And we are back to results we had before the Maven central being moved outside of the factory. We know how to revoke OpenVPN old certs that wasn't an automated port but now we know how to do it manually. And we revoke and test it for Alex. And we also tested accidentally on one of the certificates which prove it work for revocations. So, now we have a documented way to doing it. We could automate, but that's not worth the effort. Just need to read the doc and update the text file. And finally, as part of last week update center outage we did a lot of changes on Poupet for the pkg machine and that allowed us to finish the cleanup of MirrorBrain by adding back MirrorBrain user and some of its resources and cleaning up and securing the machine even more and removing all things from the past. One of the main changes on this one is that now the user www.data cannot log in anymore either through SSH or even with a bash it's been no login as it should be. So, the user that run Apache on that machine is not able to have a shell anymore and is not having access anymore to any SSH key that could have been quite an issue if the Apache version we run there was having a CVE for instance. That was a thing from four or five years ago that has been fixed. Every system needing to update the pkg JenkinsIO or update JenkinsIO are using the MirrorBrain user which is a different user with a different set of permissions now. That has been quite a set of issues so thanks Erveille, thanks Stefan, thanks Marc for helping on this one because that has been a bad week last week. We have a bunch of issues that weren't planned mostly people trying to create account on their own JenkinsIO as usual or not using the community forum. Ok, quick pause here. Is there any questions or things to add on the test that we were able to finish during the past two weeks? Ok. So, I'm going to start first with the BlobExphere as a copy then ACP and then we can continue on priorities. So, BlobExphere with as a copy. Erveille, do you want to do a summary? Should I do one? I propose I do a summary of what have been done and you do a summary of what are the next steps before closure. Is that ok for you? Ok. So, last week, last Monday one day before the weekly and two days before the LDS we decided to effectively start using ACP instead of BlobExphere on the PKGVM in order to synchronize data to get JenkinsIO that was a way to untangle a bunch of old scripts and prepared let's say laid ground for the update JenkinsIO migration. As a consequence we had a non we couldn't roll back a change that has been made on the permission on the files because it started to go over all the PKG JenkinsIO data tree. That is a lot. And finding the exact set of permission wasn't possible. We didn't take a snapshot of the file system before that operation so we weren't able to roll back the change so we had to finish that change and go forward. In any case it would have broken so we could have rolled back eventually on the first past 5 minutes but we would have had to break everything again. So we could improve in the future for such changes but there were so much unplanned issue on this one that we had to fix it that took 2 full days until the LTS but now we have an improved ground. The main issue was the permission a mix up between mirror brains and WUW data users that were used concurrently one by trusted CI with the update center and the other by older releases it's because that machine has pkg and updates which are 2 different services but the scripts are tangled here and also that machine has been managed manually during 3 years before we were able to enable pupet agent on it again. So the consequences of everything made what should have been a minor and ephemeral mistake on the easy copy way of specifying source and directory AirSync and CP are different already it's already a nightmare easy copy has it's own way of specifying recursive thing and what should have been a minor mistake took way a bigger scope but at least that uncovered a lot of issues that we had to fix. So everyone is back and now the 3 of us on the SRE team we know every details on different scripts and we remove half of the script and now everything is code managed so we are back in time and the good thing now the outcome is that the hourly sync.sh script that takes care of a full sync between the machine and all the OSUSL and archive mirrors is taking less than 2 minutes thanks to easy copy now handled by Poop at your breaklist so everything is smooth and as code exactly no more concurrancy and everything is cleaned up the bad outcome that made me so mad that I was ready to buy a plane ticket to Redmond and go there with baseball bats is that easy copy breaks the Linux yesterday in so you must prefix each colon inside a script by column pipe otherwise it breaks all the Y loop or every tricks you do with yesterday in on pipes yeah that was a very tricky one yeah that's a non-pozics thing and that one didn't help it opens standard input and then closes it oh that's very bizarre okay which is absolutely not not pozics compliant but now we know that using easy copy with yesterday in there not so we have a trick on the script and yeah and that's all survey your turn what are the next step before we can close this one I have an open request to remove BlobixFair from docabildare image and I have some remaining SIS token maybe storage ok so next step you said removing BlobixFair from docabildare pair in progress removing SIS tokens and some storage accounts so I got a request for this one first we need an exhaustive list even if it's not automated or as code and second we have to announce this so we can plan it carefully is that ok for you like you did last week for the initial operation is that ok detail in the issue is there any other question on this one nope ok now I'm moving to artifact caching proxy we were able to deliver a new version of ACP 1.0 featuring server side fallback to incrementals and apache central so instead of letting Maven retry on the different fallbacks on client side we decided to do it on server side pro it's way faster way way way faster inconvenient is that it's a slightly different dependency resolution mechanism than Maven for our contributor outside infrastructure or when we do continuous delivery of plugins or when we release Jenkins but no one want to use cache when doing release of Jenkins you are bound to a lot of problems quickly so we decided to say it's only on the CI part and we accept that given the performance improvement is there any question about that part that we deployed last week ok so now I can go on what issue did it cause because it caused some so let me add the free we have free issue related to this one ok first we are almost ready to close the initial issue that was a request from Bezel to add back the Maven central caching on ACP which we used to have month ago before we did the artifactory project bandwidth reduction for our sponsor now we have good performances there is still a few errors that we cook that might be ephemeral 50 errors I would want to check if we had these errors again or if it was just during the migration these errors are related to ACP writing temporally big files on the system because it's not able to have it fully in memory so it use the buffer and write buffer lines but since it's cached directly writing directly the buffer part to the cache so that one caused issues I'm not sure about the performance issue here we don't really care because we just have a second build that take care of it but I just want to be sure it's not related to memory usage and we don't have to tune fine tune more before closing that should be a one hour analysis this week so I'm keeping it open anyone interested is welcome to read the documentation I've added on the issue and we can check these metrics on Datadog quite easy so it's almost closeable closeable almost one last metrics analysis and HTTP 500 errors then we have a brand new issue which is not ACP itself however that has been shown that has been appointed by a usage of ACP we are caching inside Artifactory artifact that should be on Maven Central and that were overriding Maven Central since years we didn't add, we didn't see any issues because Maven Central used to be a mirror and Artifactory was resolving the artifact priority by prioritizing the mirrors and just using our additional but now, since it separated ACP only use what is inside our system so Mark I believe that Basil proposal makes sense, we should as soon as possible to un block, to remove this error and un block bomb release we should get any Maven plugin related elements that used to be either mirrored on Maven Central or deployed with a specific Jenkins version because it used to be 4 years ago I propose that we move them to a specific repository and remove all these elements until we reach a nice state, so we don't delete them but move them somewhere and if we see a project or a plugin having issues they can add on their POMIX ML a specific local repository that we could archive or artifact or old public so we can act swiftly remove the errors without putting any project build at risk what do you think that sounds very reasonable to me, thank you we have remnants of old apache Maven plugins in Clash Public that should be moved to a specific custom repo mostly forks we might have other surprises after this one but at least that's the way forward Oli Afner was open an issue a few weeks ago about ACP not proxying the incremental artifact the new ACP features that's caching but Oli is blocked with the previous issue so we cannot confirm it's sold for him so now we have this one on hold on hold blocked by the issue above that's all for ACP is there any other question need for clarification I try to be as brief as possible nope ok ok ok ok ok ok ok ok ok donc il faut que ce soit c'est possible c'est possible comme nous l'avons élevé sur production avec l'un des meilleurs de Cloudflare, locatés en Europe. Nous devons probablement avoir besoin de l'un des meilleurs de l'Union Européenne et de l'Europe. Quels sont les solutions? Nous devons décrire les solutions comme nous avons utilisé un digital au sein des meilleurs ou des vols-bags et quelques éléments. Hervé a travaillé sur le benchmark de performance. Il va avoir des notes sur ce sujet. Nous avons eu une discussion sur la synchronisation de ce sujet. Hervé, je vous remercie. Je vais vous rapporter sur le benchmark. Oui, je dois décrire ce que j'allais faire. Ce que j'allais utiliser, c'est probablement le Végétal K6. Un point intéressant que j'ai demandé à Hervé pour le reportage, c'est que depuis qu'il a fait quelques tests la semaine dernière, il a misé les coûts. Tu as dit que c'était en utilisant 20 machines virtuelles, c'est vrai? Oui, je n'ai pas réussi à décrire exactement les coûts, mais il devrait être moins de 10$. Je ne vois pas d'autres ressources. Je ne peux pas décrire à ces ressources. Je n'ai pas réussi à identifier les coûts concrets. Ok. N'hésitez pas à ajouter des screenshots de ce que vous voyez dans l'issue. S'il vous plait, documentez-vous. Nous pouvons le faire ou nous pouvons avoir un different point de vue. C'est le point important. Nous ne devons pas le faire seul. Nous devons documenter le plus vite possible. C'est le mandat. Je n'ai pas eu de temps pour le voir aujourd'hui. Ce n'est pas un problème pour tout le monde. J'ai fait des erreurs pendant plusieurs temps. Tu as fait des erreurs la semaine dernière. C'est un emploi d'amélioration que nous avons besoin. Ce que nous découvrons, c'est que nous pouvons détruire les ingrédients publics et faire des services plus rares par un benchmark de performance. Nous avons besoin d'améliorations pour les services de performance. On a un peu d'effectifs de benchmark initial. Nous pouvons améliorer la qualité de l'AKS cluster. La qualité pour les publics. Il y a des détecteurs Azure qui recommandent des improvements. Il y a un 3rd system pool node. Nous avons vu que la qualité de l'AKS cluster peut être améliorée, car il a été vraiment checké. Nous pouvons aussi vérifier les metrics des ingrédients et l'impact, car les ingrédients sont shared par tous les services de web. Ce n'est pas seulement celui-ci. Donc peut-être nous devons ajouter plus de nodes et plus de replicas pour les ingrédients. Nous devons voir les limites des ingrédients. Il y a des ingrédients, des contrôles, des nodes pool. Nous avons des recommandations et des metrics. Nous devons commencer par collecter les logs de l'ingrédient, les logs de l'AKS. Nous faisons ça pour les services de la back-end, mais nous trouvons que ce n'est pas le cas pour les ingrédients. Nous devons voir quelque chose d'autre dans le Datadog, mais ce n'est vraiment pas le cas. Nous devons vite accesser, spécifiquement quand nous devons voir l'impact de l'impact de l'ingrédient. Finalement, nous devons fixer la collection de metrics de Datadog pour MirorBits, MirorBits et HTTPD. Nous devons également obtenir les Jenkins.io et de nouvelles updates de Jenkins.io Nous n'avons pas de metrics montrés. Nous voulons voir le spécifien, mais il ne voit pas le code, donc nous n'avons pas de metrics. Est-ce un changement dans la configuration de Datadog, des bugs, quelque chose ? Nous ne savons pas, mais nous avons besoin de ça, sinon le benchmark de performance n'est pas le cas, parce que nous ne pouvons pas voir l'impact sur MirorBits et HTTPD de ces benchmarks. Il n'y a pas d'impact, mais c'est tout. Ce n'est pas le cas pour nous, mais pour fixer, donc nous devons le faire avant le benchmark. Est-ce qu'il y a une question, une clarification, des points que j'aurais oublié sur ce sujet ? Ok. Alors, rapidement, sur les priorités, nous avons AWS. Je suis tard sur ce sujet. Je dois mettre sur le compte. Nous avons les crédits de 60K et nous commençons à faire des plans. Il n'y a rien à faire. Mais ce sont des priorités de stop parce que le but est de commencer à choisir les crédits dès que possible. Stéphane, pouvez-vous nous donner un summary sur le port IRM64 ? Oui. J'ai trouvé un travail sur l'infra-ci. J'ai préparé un pro-request, mais j'ai juste besoin d'approval et je vais pouvoir suivre le checklist pour s'assurer que c'est correct. Je suis désolé, j'ai essayé de remercier le nom de l'opposé d'Aura for God. C'est pas grave, c'est de plug-in sur l'API. Hervé, je n'ai pas vu votre message. Vous pouvez le faire si vous avez besoin Merci pour les updates, c'est ok. Nous avons tout ce que nous avons besoin. Vous n'avez pas besoin. Ok, cool. Alors, IRM64, c'était Pair. On a plug-in sur l'API. Donc, une fois change, on va vérifier que ça va générer une nouvelle version et déployer. Vous avez fait tout ce qu'il y avait ? Désolé. Je pense que la prochaine étape sera d'essayer pour le contrôleur de l'IRM. Donc, à propos de nouvelles noeuds pour ne pas avoir les mêmes noeuds pour le contrôleur et l'agent et essayer. Oui. J'ai coûté à moins une chose que vous avez besoin de rouler. Découper Docher Ashikop. Oh, oui, j'ai une remise de celle-ci. Job sur l'infrascié et vérifier d'autres pour nettoyer si il faut. Je suis sûr de Docher Ashikop parce que je le vois. Il n'y a pas d'autres noeuds parce que j'ai utilisé d'autres contrôleurs. Il y a l'agent d'utiliser d'autres noeuds qui sont entrés. Non, ce n'est pas possible. Oh, ok. Non, ce n'est pas possible. Je vous challenge de le trouver. Non, je pense que c'est un petit centre qui utilise la noeud qui utilise le même nom. Non, je vous challenge. Si vous vous challengez, vous êtes probablement correct. Je ne vais pas jouer ce jeu avec vous. Mais ça veut dire que vous devez faire un dernier sweep d'images favorisables qui pourraient être arrimés. Je pense que non. Je vais devoir vérifier. Le plus important c'est que j'ai encore besoin de Docher Builder. Ce n'est pas possible. Je ne peux pas mourir parce que c'est utilisé sur CI. C'est-à-dire que dans CI nous devons bouger de Docher Builder. Oh, ok. La prochaine étape serait sur CI et c'est l'infos. Vous êtes d'accord. Non, vous êtes absolument d'accord. C'est un sujet différent. Désolé, je n'ai pas de focus. Je vais me retirer. C'est là-bas. La prochaine étape est bien. Merci. Les autres soucis. Nous avons eu un nouveau de James sur le directeur dans les updates de la noeud. Ce n'est pas possible. C'est un point de passe que l'on puisse tout simplement imprimer sur ce poste de bulle dans l'esprit de l'impos. Lors de ce point, ça va dire que la question s'arrivera avec le premier de l'exemple. Désolé. C'est tout pour moi. C'est un point de passe qui va se les prendre envers. Et je vais vous parler de la question de la production. CIGEN-KIMSAIO, donc nous avons besoin d'enlever ce couple, sinon le site de plug-in ne peut pas être créé quand CIGEN-KIMSAIO est terminé. Il y a aussi un enjeu d'incrémentale sur l'incrémentaire que j'ai récemment coûté, je n'ai oublié d'ouvrir l'issue. Je vais vouloir commencer ceci et d'involver Stéphane et Nora à un moment donné. Je vais vous laisser savoir, mais je vais prendre le temps en hand of week. C'est une priorité basée. Marc, j'ai besoin de votre aide sur le projet GiraTest. Il me semble qu'on devrait... Nous devons juste l'enlever. Je pense qu'on a une conclusion dans la discussion. J'ai apprécié de l'involver en plus, Damien. Je pense que l'answer est qu'on peut juste demander à Alex de confirmer qu'il est bien. Nous ne ferons pas prendre plus de procès sur ça. Ok. Oui, j'aimerais très bien que ce soit bien pour vous en termes de temps. Oui, vous pouvez le signer pour moi. En fait, je vais le signer pour moi. Cool, merci. Hervé, vous êtes là ? Vous pouvez nous donner un update sur les deux nouveaux mirrores ? J'ai besoin d'enlever le RDS. J'ai besoin d'enlever Sébastien Framostico et des maires avec tout ce qu'on a besoin. Avant d'enlever le RDS, il y a un nouveau mirrore dans notre système. J'aimerais le tester localement avant d'enlever le RDS. Nous devons l'enlever avec l'utilisateur et le password. Nous travaillons comme prévu. Et puis, nous devons annoncer que le nouveau mirrore est disponible. Nous devons avoir à peu près 1 ou 2 nouveaux mirrores. J'ai besoin d'enlever ces deux sujets sur le milestone ou vous voulez enlever et ajouter seulement si vous avez des feedbacks ? J'envoie. Je sais que j'ai besoin d'enlever. Nous avons une demande spécifique de JC pour l'enlever d'enlever. J'ai proposé d'enlever ou d'enlever quelqu'un d'autre. Mais maintenant, l'advantage de la balance vers l'effort ne nous permet pas d'enlever. Si c'est bon pour tout le monde. Je vais enlever 2 ou 3 semaines. Dès qu'il y en a d'autres, nous devons enlever quelques extraits. J'ai pensé que ce serait pas le plus une chose. C'est un item de l'action. Nous nous avons... Nous avons... Beaucoup d'administres de les délire à l'artif de la repositorie. Le travail doit être fait. Il y a des issues licences qui sont réalisés par le board. Merci pour l'update, Marc. Nous avons le FI-6 IPv6. Il faut travailler sur les encryptes dans le monde renouvelant le DSA. C'est une priorité basée. mais nous avons des certificats pour renouer dans les prochains 3 jours, je vais prendre care de cela demain parce que, au moins, Miros, Jenkin, Sayu et Mirosjenkinci.org domaines vont avoir leurs certificats expirés, ils ne devraient pas, je ne sais pas pourquoi, donc nous devons rapidement checker ceci, mais nous avons reçu un alerte 2 ou 3 jours ailleurs, et ceci aussi spécifiquement. Donc, nous allons faire une action toute à l'heure demain matin. Peut-il vous présenter ces hostages encore, Damian? Quels étaient-ils? Miros.jenkins.io et Mirosjenkinci.org. Ce sont des names des formes d'années, qui se sont réveillées avec Miros, Brian, en PKG, mais migréant un an plus tard, pour être les aliases de Get Jenkin, Sayu. Merci. Je vais juste vérifier que mon monitoring n'est pas vérifié leur certificat d'expiration de SSL, et ça devrait être, donc merci. L'expiration pour Get.jenkinci.io. Donc, il faut ouvrir une issue pour ces... Non, non, non, non. OK, Miros.jenkins.io, cette certificat n'inspire pas, au moins de mon web browser, jusqu'à juin 24, c'était juste issu en Marche 26. Oh, donc je dois vérifier les messages de Let's Encrypt, que j'ai peut-être... Donc, ça peut être que j'ai vérifié le bon site, mais Miros.jenkins.io a un certificat d'expiration d'années. Marche 26 n'est pas plus tard. C'est vrai, c'était seulement 5 ou 6 jours plus tard. Donc peut-être le mail... Oui, peut-être le mail a été priori à ce que j'ai vérifié. Oui, je dois vérifier, mais bonne news, ça signifie moins d'émergence. Oui, mais ça signifie que mon monitoring doit être extendu, donc... Ou on peut étudier l'expérience de la monitoring de Datadog. C'est ce que nous allons faire tous les deux, certainement, nous allons étudier le Datadog, si je ne l'étudie pas, absolument. Oui, sans question. Nous pensons que avec Adrien, sur ce point, tout est bien. Demian a besoin de rapporter sur ce sujet. J'ai tardé sur celui-là. Ce sujet. Deux next steps. Créer CI Jobs sur CI.G et CID Jobs sur FrostCI. Donc, comme c'est préparé et proposé par R.V., il semble que le plugin Hillscore est très compétué avec la génération API de plugin site. Donc, l'idée est d'entendre la compétition par avoir un nouveau travail qui génère les rapports du plugin Hillscore, plutôt que de servir un API sur un système non-available. Et ce rapport sera posté sur le rapport de Jean-Kin Sayo, qui est un web server simple et avalable avec des rapports publics. Et puis plugin site va commencer à choisir ces rapports. Donc, si le plugin Hillscore est terminé pour quelque raison, nous avons encore le plus tardé export et le plugin API site n'est pas bloqué. C'est un très bon improvements. Adrien a déjà fait le travail pour générer le rapport. Et maintenant, nous devons présenter les outils. Un CI Job sur CI Jean-Kin Sayo pour vérifier et, comme nous faisons tous les rapports, et nous avons besoin de créer un Job sur l'infra-CI avec la chaine d'apprentissage réel qui va s'occuper de la réelle vie et de la réplique des rapports sur la location propres. C'est-à-dire, pour plugin Hillscore, deux jobs sur CI et deux jobs sur l'infra, mais pas dans la même chose. Il y a vraiment un Job. Oui, mais celui-là construit l'apprentissage de l'infra-CI. Oui, ils ne sont pas dans la même chose. Oui, absolument. C'est un Job sur l'infra-CI. C'est-à-dire que c'est ce que vous venez de faire ? Oui. OK. Nous devons avoir en compte que l'apprentissage de l'infra-CI aura deux jobs sur l'infra-CI. Oui. Pas dans la même chose, mais deux. Absolument. C'est important pour le nom. Et enfin, nous avons un Job sur CI Jean-Kin Sayo, une réplique sur l'infra-CI. OK. Sur l'infra-CI. Donc, je suis en train de bouger sur l'infra-CI. Et si vous avez le temps de bouger sur l'infra-CI, n'hésitez pas à le mettre sur l'infra-CI. OK. Je suis désolé, ce n'était pas très longtemps. Nous avons juste un peu de nouveaux items que nous devons essayer pour voir si nous devons bouger sur l'infra-CI ou prioritiser. Marc a été trop vite. Donc, Jean-Kin Sécurité peut vous faire défaire à l'artifactoire. Jean-Kin Stat Repository. Et celui-là est Stéphane. Donc, je peux retirer le trajet. Donc, seulement deux nouveaux items. Le premier a été ouvert. Donc, il semble que l'artifactoire a des problèmes. Je veux dire, il y a des connecteurs. Résentement, il y a des problèmes. Il y a un issue de réseau. C'est difficile de dire à l'adversaire si c'est sur l'artifactoire qui a été utilisé pour ce travail ou si c'est l'artifactoire qui a été utilisé pour l'artifactoire. C'est une relation à l'ACP, la première chose. Parce qu'ici, c'est directement de l'artifactoire, directement de l'artifactoire. Il n'y a pas d'ACP involved. Je ne vois pas l'action négative pour nous, sur l'infrastructure. Peut-être que je vérifie le statut sur GFrog. On va voir. Alors, si quelqu'un veut aller en contact avec Jean, je vais leur répondre et vérifier. Mais je ne vois pas l'action négative pour nous maintenant. Éventuellement, si ça s'occupe d'une fois, on va en contacter GFrog. Donc, on va ajouter à la nouvelle milestone. N'importe quelle question. Et l'autre, c'est un co-issue de Bruno et Jean-Marc sur l'hosting, les différents outils que Jean-Marc Messen a créés pour collecter les stats contributaires pour la communauté. Il y a des différents et plusieurs repositoires, donc j'ai demandé à eux d'avoir les besoins. Parce qu'on a un peu de données. Donc, cela peut changer pour reposer Jean-Kincaio au lieu d'un repositoire. Ou on pourrait avoir le repositoire avec la histoire des données. Je ne sais pas, mais ce n'est pas mal. L'un est contenu dans le processus principal qui s'occupe d'avoir des données qui se renforment et les écrivent. Il semble qu'il y a deux autres repositoires qui pourraient être intéressants. Je m'ai mentionné pour l'infra. La première contient le code source pour les tools command lines. Je crois que c'est Golan Rochelle, je ne suis pas sûr. Et l'autre est un Ombrou TAP qui est une sorte de repositoire pour le tool nommé Ombrou principalement utilisé sur macOS mais il travaille sur Linux et Windows aussi. Et c'est un moyen de délivrer des command lines. Nous avons eu la discussion avec Garrett Evans quelques années auparavant parce qu'on l'a déjà utilisé et nous avons encore quelques command lines autorisés par les projets de Jenkins comme la version de Jenkins que l'on a déjà utilisé. Je crois qu'il y aurait l'intéressant sur la repositoire de Jenkins. Avec le GraphQL. Donc mon proposant si tout le monde est bon est que nous pouvons avoir un Synfra Ombrou TAP qui serait un genre de repositoire custom. Ce n'est pas les tools directement pour le user de Jenkins. C'est pourquoi il reste sur le Jenkins Synfra repositoire. C'est un set de tools pour les command lines et les tools d'inventualité scripts pour délivrer avec Ombrou. Et ça va involvementer bien sûr Jean-Marc Messon code depuis qu'il veut relinquir le code source pour nous. C'est le proposant. Je ne pense pas qu'on va pouvoir travailler sur ça sur la prochaine milestone. Si c'est ok pour un proposant pour poster dans deux semaines c'est le temps pour nous de reposir sur nos faits. Oui, et vous avez un nombre de propédateurs dans le Jenkins Synfra ? Oui, c'est une bonne news. Est-ce que c'est une question ? Non, non, c'est une affirmation. C'est une version Jenkins que vous pouvez voir. C'est parfait. Cela signifie que nous n'avons qu'à ajouter la formule ici. Oh, oui, Gareth a déjà fait l'évit. Donc, nous n'avons qu'à augmenter les tokens de GitHub pour éviter l'événement de Gareth et d'assurer ces tabs. C'est une bonne news. Je vais commenter sur l'issue. Merci, Serey. Je n'ai pas oublié que c'était déjà fait. On pourrait vouloir oui, et ce sera pour l'avenir. Mais il y a d'autres versions d'événement depuis que Gareth est maintenant manuellement optimisé par mettre sur le master. Bon point. Donc, ça s'ouvre beaucoup de choses. Je suis sûr que Bruno va avoir beaucoup d'événements d'événement de Gareth si nous lui demandons bien. C'est un bon to-hit. C'est-à-dire le mot en anglais ? C'est le king de l'événement de Gareth et de Gareth. Cool. Je n'ai pas d'autres sujets. Tu as des phoenix ? Si, j'avais 22. Je me souviens de tout. C'est important de le demander maintenant. Oui. Présentez-nous votre idée, Hervé. Donc, Alex Pondes a créé une nouvelle vidéo sur l'HDKI 22 qui dit que les quelques blocs ont disparu. Donc, on peut utiliser la HDKI 22 pour Jenkins. Nous pouvons utiliser cette version dans nos contrôles et dans nos agences. Mais pour cela, nous devons mettre un lifecycle pour les versions Fidica. Comme celui-ci qui sera disponible jusqu'à l'endemain de la vie dans 5 mois. Est-ce qu'il y a un point d'advice ? Je remercie avec Hervé cette discussion qu'on a fait à TeamWide aujourd'hui mais que nous aussi avons tous sur l'une de nos meetings week-end. L'initiel de proposer d'avoir une HDKI-age pour exemple est compliqué parce qu'il y a des éléments de surprise pour le développeur. Mais depuis que nous avons fixé l'endemain de la vie dans 5 mois et quelques jours pour l'HDKI 22 ce qui fait sens pour dire nos policies de l'endemain de la vie que nous ajoutons comme l'HDKI 22. Si vous voulez utiliser ça, vous pouvez. Mais vous devez savoir que ça va terminer je pense que c'est en septembre 2024. OK. Hervé, est-ce que vous voulez ouvrir un problème pour cette question pour summariser ça ? Oui. Merci. Mais nous clairement expliquons l'EOL. Il doit être créé par merci. Qu'est-ce qu'il y a ? Non. Pour être migréable postpone 2 semaines re-use existing Sorry, je suis en train de prendre l'endemain de la vie. Tape de Jenkins Infra. OK. Je n'ai pas d'autre chose sur mes côtés. Donc, c'est l'endemain de l'endemain. Je vais finir l'update milestone sur les problèmes. Merci pour être patient avec ce long d'endemain. Nous verrons avec j'expecte une nouvelle d'endemain. Bye-bye pour tout le monde et à la prochaine week-end pour tout le monde d'avoir regardé. Bye.