 Bonjour tout le monde, bienvenue à la meeting de l'infrastructure weekly de Junkins. Aujourd'hui, c'est le dernier jour de janvier 2023. Sur la table aujourd'hui, nous sommes six, moi-même, d'Amérique Portal, Bruno Varton, Marc Waite, Kevin Martin, Stéphane Merle et Hervé Le Meur. Nous avons six boulettes. Oui, nous avons six boulettes dans les notes. Nous allons commencer avec l'annoncement. Weekly 2389. En progrès, checklist en progrès. Il n'y a rien à dire, il n'y a pas d'issue. Non. Un de mes propres yeux a l'air déjà. Oui, c'est bien. Cool. Un autre annoncement. Artifact caching proxy. Donc, c'est un topic, c'est un topic de priorité pour aujourd'hui. Mais l'idée, je propose que nous annonçons juste maintenant et que nous prenons les détails dans les tâches de l'arrivée. Mais nous planterons, aujourd'hui ou demain, d'établir l'artifact caching proxy pour tous les billets de plug-in sur CI Junkins. Le but est de diminuer, dès que possible, l'amount de data élevé par le système de l'application de CI Junkins. L'email sera envoyé à la liste de développeurs, à moins une heure avant de faire ça. Nous avons une dernière mile pour finir, mais tous les tests de performance que nous avons faits, étaient vraiment, vraiment bons. Donc, oui. Ça devrait être une bonne direction. Juste pour l'information que je propose, avant d'arriver à Stéphane, on pourrait créer un issue dédicatif juste pour le switch opté, opté, opté, opté, opté. Donc, parce que cet issue va servir comme une sorte de documentation. Parce que l'une des choses principales est que si quelqu'un a un issue, c'est plus facile d'avoir tous les contributaires pour ajouter des commandes avec un lien spécifique. Et le body, l'initiel de l'initiel de l'issue, va montrer, hey, si votre build est slow, relance-t-il bien ou pas? Checkez ça et ça. Et vous verrez le temps réel avec l'impact là-bas. Parce que, oui, il y a peut-être un ressenti de slow-build qui pourrait leader à l'agent de prendre le temps pour être spawn, qui est toujours relative de l'ACP. Et la variabilité de des tests et des performances, et depuis que le timing est pour le commande main qui int coordiné et les tests, on n'a pas d'une faillite façon qu'on met en place, en regardant les máscales des lignes spécifiques. Non plus du tout, on n'a pas de manière de dire que l'on a fait pas de temps Il n'y a pas beaucoup de temps à construire, pas beaucoup de temps à tester. La information est là, mais pas facilement disponible. Donc, le but est d'avoir... Provider un manuel rapide sur l'issue dédicataire, juste pour aider les développeurs. Calendar, si vous avez un autre annoncement. Non. Donc, la prochaine... Donc, j'ai un red flag. Je vais séparer les containers docker. Nous avons juste publié 2.379 comme une image de container, pas 2.389. Je suis un peu perplexé par ça. OK. Un sujet separate, pas pour cette rencontre. Il faut investir. OK. Est-ce que vous pouvez juste ouvrir une issue sur l'issue dédicataire? Je vais ouvrir l'issue dédicataire. Oui. Je suis juste perplexé. Merci Marc. Donc, nous allons regarder ça après. Donc, la prochaine semaine, la tue... La tue, nous allons avoir 2.390 weekly releases. C'est correct? Oui. C'est correct. Nous pouvons être insolents. Nous ne serons pas présents. Nous serons à la première fois à la fin de la semaine. Ah oui. En annoncement, c'est un bon point. Oui. Je pensais que c'était un grand évent. Oui, c'est correct. Donc, je pense que c'est une vraie question. Est-ce que nous devrions canceler la tue la semaine prochaine? La tue? Parce que si vous êtes tous allés dans la Belgique sur la tue et la sondage, est-ce que c'est OK si nous continuons la tue la semaine prochaine? Nous allons garder un petit point. Oui. Plus un avec Stéphane. OK. La tue, c'est un bon point. Merci Eric. Merci Stéphane. La tue la semaine prochaine, est-ce que c'est la semaine si je suis correct? Donc, 2.375.3. La tue la semaine 8 de février. Est-ce que c'est correct? C'est correct. Et Alex Brandes est le lead de la relance. C'est mon récollection. Cool. La tue la semaine prochaine. Donc, c'est 21. C'est celui-là. We also know by people that we also know by the community that they had had 1. So, after this, we had 1 last week. Foulks for looking. It was the 25. It was announced day before and we don't have any other public announcement so afin de migrer à l'interesse de l'Igenkin SAIO, tous les travail en charge de déployer les réalisations des images d'Igenkin SAIO. Les images basées, les images inboundées et les images de l'Igenkin SSH. Nous n'avons pas vu ce fameux log de Git polling. Nous avons ajouté des réalisations sur un agent docker qui s'est apporté automatiquement. Il y a deux updates sur l'Igenkin SSH et l'Igenkin inboundé plus tard aujourd'hui. Tout est en train. Le travail formateur a été archived. Il a été réveillé. Maintenant, nous allons le voir en temps. Mais oui, bonne news. J'espère que nous ne devons plus avoir plus d'informations sur l'image d'Igenkin SSH. Merci, Stéphane, pour l'aide. Tout le monde s'intervient. Pas de question. Valid certificate for trusted CI. C'était déjà fait la semaine dernière pour le certificate initial. Et maintenant, le renouvel est automatisé en code de DNS. La prochaine étape, nous devons mettre en code le renouvel pour l'Igenkin SSH. Ce que nous savons, c'est que nous n'avons pas managé le challenge de DNS pour l'encryptage dans l'architecture virtuelle de Poupet. Nous avons utilisé le challenge de DNS seulement dans notre cluster de Kubernetes. Maintenant, ce que nous avons appris est que nous savons comment définir un zone de DNS et d'indiquer une technique Azure qui aroma au code de DNS et de l'accompagnement de la configuration pour conserver un renouvel correct en CRIP. Cela signifie que l'account technique n'est pas managé d'un autre record que l'un de ces zones. L'on a bien travaillé, donc nous devons faire le même donc on va bénéficier d'une rénewal automatique de la certification qui a été créée manualement. C'était aussi un grand effort de team dans différents secteurs. Merci à Team, merci à Survey, merci à Stéphane, merci à Mark, et merci à Vadik et Daniel pour pointer sur les éléments corrects. Juste note, nous avons dû aller dans un petit peu d'eau dans les modèles sur la perte et les modèles pour la poupette. Et encore une fois, nous avons face à la facture que la poupette commence à être vraiment de l'air et commence à m'inquiéter. En termes de maintenance, ce n'est pas une simple étape seulement pour installer un peu de paquets, mais c'est juste une photo de nourriture, pas d'action directe. Qu'est-ce qu'il y a ? On a retiré le plug-in déplicé sous les barres de l'instance, donc nous avons ajouté un message sur le Genkins Controller, comme tous les utilisateurs. Nous avons retiré le plug-in à l'aide d'une machine virtuelle. Nous avons wenté sur le UI, un install plug-in restart controller, et c'est ok. Ou sur les images du docker, pour la semaine, c'était présent, c'était retiré du image du docker. Et quand la nouvelle image du docker n'était pas installée dans le plug-in, nous pouvions bien l'installer. Dans le cas du image du docker, c'est parce que le plug-in lifecycle installé sur l'image est différent de l'installé sur le Genkins. Il y a un guide, un pull request, pour un guide sur how to uninstall it sur l'official genkins.ci slash docker qui peut bénéficier de ça. Mais je n'ai pas oublié de le faire, donc je pense que ça devrait être au-delà de Genkins, pour l'aide de la personne qui l'a écrit, mais nous pouvons l'aider dans l'arrière. C'est Kevin et j'ai ce sujet. Nous savons que le docker pull request est à documenter comment on installe le plug-in, et je pense que l'on va l'alimenter sur www.genkins.io comme part de l'official documentation. C'est compliqué et on va probablement trouver une meilleure façon de le faire pour les images du docker, mais maintenant, nous devons décrire ce que nous avons. Oui, je ne pense pas qu'on va trouver une meilleure façon, Alas. Je pense que la façon dont ça fonctionne est de changer tous les choses sur Genkins, ce qui est... difficile. Je pense que le R-sync est minus-minus-delete, mais je sais que vous et moi avons une différence. C'est juste que si ça ne fonctionne pas, si le plug-in est encore sur l'image de le docker, ça sera réinstallé sur le Genkins. J'ai une solution. Vous créez un R-sync temporaire monté sur Genkins.io et vous êtes prêts. C'est pas mal. Ce n'est pas un start-up plus rapide pour Genkins, parce qu'il faut séquiver les files. Mais, ce n'est pas sûr que si quelqu'un essaie d'installer un plug-in pour l'expérimentation, vous devez juste réinstaller le contenu ou le code, et vous devez avoir le même set de plug-ins sur l'image. C'est intéressant. J'aime ça. C'est une recommandation, mais vous avez besoin d'enaut de mémoire pour charger le set de plug-in incompressé dans la mémoire. C'est... Et avec certains de nos plug-ins being hundreds of megabytes, ce n'est pas une chose désirable. Il n'y a pas plus de 800 megabytes de production pour être assez honnête. Vous avez... D'accord. C'est une étude. C'est une étude. Hum... Artifact caching. Donc, both AWS plus DigitalOscen on one side and Azure on the other side have been fixed. Hum... I'm not sure it's worth going into details on what happened. A lot of things changed. The last very well-known state was working well beginning of December. And then the migration of GFrog changed a lot of... a lot of things. So we had to fix these elements. We also had issue low-level with Kubernetes on AWS. I broke the cluster by updating a Terraform module bit brutally. And it has, let's say, major changes not backward compatible. DigitalOscen was still working well and in the case of Azure, we face something we don't understand. It was slow as hell and suddenly it worked. So the good thing is that now everything works and we can proceed. Everything has been logged on these issues. So thanks a lot again the team effort. A lot of... Let's say... I forgot the name. I already did a lot of EV lifting in 2022. Stefan helped me a lot on pairing last week. So thanks everyone on that element. The word you're looking for is the rubber docking. Wank. Fair. That's fair. SQL queries to run on plugin illscore database. Thanks a lot for helping Adrienne, the plugin illscore system. Sounds like he solved his latest issue. IRC, but Jenkins admin is offline. We kicked the pod, updated to the latest image and it worked again. Any doubt? Thank you. Thank you for the applying services. Sorry? Thank you for the applying services. We don't have any issues about it but Daniel mentioned it on Jenkins IRC that the applying service was... Yep. The dashboard wasn't accessible. We would kick... We've killed all five replicas and actually started work. Yeah, but still we tried to save it. So it was easy at the end but we did try to find out something. We can't tell also. Thanks folks. The thing is we can't tell if any data was lost. By data lost, I mean not the database itself but the data sent by telemetry to the service while it was in that word state. The data might be lost if it wasn't committed properly on the database. It sounds like the logs were incomplete so we don't really understand what happened there. So thanks Daniel for pointing that out and helping us. Now the three of us have administration access to the applying dashboard service. And with this... Sorry? There is an unknown about it. This service is sending logs to Sentry. A good point. We don't know in the current team how to access Sentry. I can't say anything. I've asked Olivier on IRC but no response yet. We might have to contact Tyler. OK, in any case we will see Olivier physically Friday so we can kidnap him until he answer to us. No food for him. That's a bit more difficult for Tyler. I'm not sure that our employers will expanse a travel for kidnapping Tyler. But we never know that IO account. We need to get access. Olivier, Tyler. Marc, are you aware of that Sentry service? I'm aware that there is a Sentry service and that Tyler was deeply involved in it. And Baptiste Matos I believe also is aware of it because there was a part of it that was used for for the thing called essentials. But I don't know if Baptiste's involvement was actually in this particular aspect of it or just related to essentials. OK. We should also move the database to the one. Absolutely. That's in the new to do now. A date of change. No, but yeah, I can add it to the new to do. Now for me, it's another health desk. OK, OK. To be migrated into our flexible instance. The reason of changing is because that is a standard post-grayscule instance that has some limitation. Since then, we have created a new post-grayscule server instance which currently hosts already free database plug-in ill service rating and key cloak. So that will be a matter of creating the database migrating the data and changing the configuration of the application. Advantage of the new kind of server post-grayscule flexible is that it's flexible as its name implies. It has high availability possibility and that's also a single entry point for us to manage databases. It costs less. The only downside that we discovered is that you cannot use multiple virtual network on Azure to reach the same database instance. So when like some people there you try to migrate some services from one network to the other you will have interruption of service. So you need to find creative way for not breaking the service. More to come in the future. What a teaser. Good catch folks, thanks. No question about walk being done. Sorry, about walk already done. Now we switch to the walk being done. We had an issue about renew the signer certificate for Jenkins. So we absolutely need to walk on this one. The idea was to walk with Olivier and Mark, especially Olivier, if we can see it. Mark, I saw that you updated and you had information. Yeah, I think so I've confirmed that I can log into Digisert and I can see the certificate that was issued. So I think you and I, Damien can do it and create a runbook for ourselves. It just needs some more investigation. I propose you and I'll spend some time tomorrow and possibly Thursday. And then if I remember correctly, you're you're at Fosdom already on Friday, correct? So yes, but if tomorrow and Thursday, we make progress. Great. If we have questions, you can always ask those questions to Olivier when you see him at Fosdom. OK, so for me, it it feels like we're at a good point. We've got the weekly release done now. So tomorrow we could start on it and the next weekly release will be a few days yet. So if we make some mistake, we can we have time to recover. OK. Is it OK if we delay the usage of the new certificate after the LTS? Because yes, yes. We spot them then weekly, then LTS. It's very risky. I'm I'm I'm perfectly fine with that. Then I would think what we ought to do is let's accept that you and I will work on it after the LTS next week because I don't want to touch the working configuration. And I can do research that doesn't modify the working configuration, but I don't want to alter anything in the working configuration until after that LTS. That sounds fine to me. And so it's is it OK for everyone if we keep those two issues open? One is about documenting the process while the other is about renewing it. Yes. Is that OK for everyone? Yeah, I I I was embarrassed to realize that when Olivier and I did this the last time three years ago, we obviously did not create a run book. I know that he and I did it. And so so. But but there's no entry. There's no documentation that I could find anywhere. So on it after the. 2 dot 375 dot 3. Yes, thank you. No objection on my proposal. It's just I fear that with or everything I don't want to back and to take any risk. I like that. I think that's and and we've got another what? At least 30 days before it expires. I think it may have been 60. I don't remember what did you search warning was? I think it was 60. I think it's March. It's beginning of March, so we should have. Plenty time, but after the LTS, that should be good. Right. Yes, 60. So January 29, they alerted us. We expire in 60 days. 60 days is plenty of time for us to to do this to give ourselves another week. Expiration 16 or 60. 6 0. 50 plus 10. It's just my French here. I understand. But I prefer. I understand. Exactement. I'm pronouncing. Numbers is a bad choice. It's a 6. The digit 6. 5 50 plus 10. 10 times 6. So 6 times 4 times 20. Like. I know that's wrong, but minus 20. And. OK. Thanks Mark for documenting this. So same. Let's work on it. After I will, I'll take care of moving the issues of the correct milestone. Don't want to bother you. OK. Next issue, walk in progress, bump the terraform module for AWS EKS. So bumping that model version still add consequences until today. It has been updated with the fixes we had to do on the EKS cluster last week to make the AWS ACP work again. Some of these elements were manually done to quickly fix the issue. We now have before closing that issue, there still have terraform changes to do. The main problem that has been documented is that the load balancer tried to automatically find the backend IPs. However, it uses a tag tags to watch which subnet hosts the correct backend IP. And it should only have one. But two subnets are tagged by terraform with the same tag. And it's a remnant from all the backward compatibility changes done on the terraform EKS module that we bumped on a major version. So the latest version should have everything required to manage these tags. But right now I've moved it manually, which means we could still have the repo AWS breaking. So I documented everything on that issue. If anyone see an issue and I'm not there, please look carefully on what has been done manually on that issue. That's basically going to AWS console and remove a tag like you select a load balancer, then you go to the associated network and you remove a tag and five minutes after it's fixed automatically. You don't have anything else to do. That one should be fixed. I plan to finish working on it. This milestone unless someone object. Anyone interested on following up is welcome to mention themselves on the issue. I'm most finished, but ACP is now working. So ACP itself now that it's working everywhere. It now has two replicas on each of the three clusters. So we now have six spots running each one with its own caching. The goal of replication is that when we operate clusters, we don't want people building on CIG and Kinsayo starting to have download error with the maven builds. So we can operate and the thing will first restart one and then the second. Second important thing is that each time you start filling the cache, it's slower for the first build. The first time, the time that the ACP instance that you are reaching when running your MVN command. If that instance does not have your artifact on the local cache, then it has to contact GFrog, follow the redirects, get the file, serve it and persist it on the local cache. So we saw random let's say times for the first builds. What is sure is that one, two, eventually three builds are a bit slower for dependency resolution because you have to fill the cache and that depends on where is the agent running your maven command located and even for a given build you can have different agents. For instance, if you run Windows container that will spawn on Azure and that will reach one of the two Azure ACP while you might have Linux 11 on Digital Ocean and Linux 17 on AWS. Once the cache is fully used, then we saw a great increase in dependency resolution time. Like it's clearly faster than GFrog, which is a really good news. The amount of speed difference depends a lot on the builds. So we cannot give a general rule. Sometimes it was the same order of magnitude. Sometimes it was free time faster. So it depends. Since we have a distributed system, it's not deterministic. You can have variation. The good thing for us is that it will decrease not only the amount of data that we download from GFrog, but also the amount of time with pod agent being spawned. So that should help. Eric, can you explain the deployment plan that we want to follow for which project, which scope to deploy ACP by default? Currently, we intend to use it on build plugin, the build plugin function used by almost every plugin on Jenkins CI organization, Qtab organization. And we also intend to adapt other functions shared by Naroie to be able to build the Bum and the other core builds like Jenkins, ACP and other various builds. Function to start testing on Bum, HTH, Jenkins Core and other non-plugin maven builds. And the Bum build is enormous. That's the one that runs what 100 or 200 concurrent parallel tasks, each one checking out large chunks of code and performing many tests. So I think the Bum bandwidth improvements should be substantial. Right? That's got to be expensive on bandwidth because it's enormously expensive on compute. Makes sense. The plan is that, as we said, we'll add a dedicated issue plus an email for plug-ins ACP activation. Je voudrais aussi finir la fonctionnalité que je veux ajouter qui est l'obligation d'ajouter l'artification artificielle par ajouter l'artification artificielle à l'application de l'application pour que les développeurs puissent s'occuper de leurs propres requests sur le demandant. Alors que j'ai besoin d'assurer que le Kitabap que j'ai utilisé pour atteindre les niveaux qui sont installés partout où c'est le même pour les tools Kitabap que j'ai utilisé pour atteindre les niveaux. Paripaire, opt-out. Et un autre opt-out de l'application qui marche aujourd'hui va changer l'artification artificielle de l'artification artificielle sur le demandant de l'application de l'application et le code de l'artification artificielle devrait utiliser l'artification artificielle à l'application de l'artificale et c'est l'autre moyen qui marche aujourd'hui de l'obligation de l'application mais celui-ci est un peu plus cumbersome que d'avoir un label sur l'artification de l'application de l'application de l'artificale. Mais je veux vous rapporter que c'est incroyable juste de pouvoir ajouter le label et l'obliger. C'est pour le file de Jenkins par un argument utilise l'artification de l'artification donc donner donner la décision qui va donner différentes manières d'obliger si il y a un problème. Donc maintenant, nous allons, au moins pour une période traditionnelle, nous allons laisser les développeurs pouvoir s'obliger si ils sentent que c'est en cause de Mayhem. Après, parfois, quand tout va être construit sur la proche de cash et nous allons avoir prouvé que c'est en train de marcher comme prévu, nous allons retirer cette possibilité de s'obliger à un moment en temps. Parce que nous ne voulons pas quelqu'un qui commence à construire beaucoup de choses qui vont directement aller au Gifrock selon la sensibilité de ce sujet. Mais maintenant, c'est une période de transition pour l'obligation de l'artification que s'obliger doit être là. Donc, est-ce qu'il y a une question qui n'est pas évident, attention point, ou est-ce que le plan d'affection est OK pour tout le monde là? C'est un bon plan. Et je peux rapporter que les 8 ou 10 ou 12 plug-ins qui ont l'artification d'artification d'artification sont tous construits successivement plusieurs fois et ne font pas de régression. Je ne importa pas si elles ont l'imprové. Je ne vois rien que je pourrais statistically appeler une régression de performance. Donc, c'est génial. C'est cool. Donc, l'initiel subset est un set de 10 plug-ins, including the one we have. Hang on, je vais vous donner un exact compte. C'est... Si nous cherchons les attributs, je pense que c'est 8 ou 10, quelque chose comme ça. Je compte 14. 14. 18, 12, 13. D'accord, c'est à l'arrivée. 13. Ce n'est pas le 1000 plug-ins qu'on a, mais encore, c'est une représentation de différents plug-ins. D'accord. Exactement. Certains sont très petits et très importants à moi, d'autres sont très grands et très importants à moi. C'est très important à toi. Alors, nous confirmons le 1er Stefan et le 2er R.V. et l'A. Nous avons checké comme équipe que nous avons accès à beaucoup de métriques. Dans Datadog, nous pouvons regarder les usages de ressources à la pointe de vue de l'application. Nous avons accès à des logs et les logs accessés de l'content nous permettent de savoir pour une certaine requête si cela a été installé sur le cash. Ou si nous avons le timing, nous pouvons corriger le timing si cela a été installé sur le GFROG. Aussi, comme vous l'avez pointé, ce matin, nous avons aussi la possibilité de checker sur le portage Azure, les métriques sur le système de file utilisé pour le cash qui a été dédié. Parce qu'il y a des différences. Nous devons éventuellement avoir de précision. Maintenant, c'est 50 GB et nous utilisons seulement un. Mais ça peut être un incliné. Donc, nous devons suivre ce portage. Et les IOPs, l'amount d'opération IOP par seconde. Maintenant, nous avons les défauts de la classe de l'IOP qui a un threshold. Cela peut burser punctuellement. Mais la qualité de l'association de file système n'est pas très high. Mais pour maintenant, nous ne pouvons pas savoir parce qu'on utilise quelques plug-ins. Nous devons voir une plage complète CIG et GINSAI avec tout le bâtiment. Donc, nous devons regarder ces métriques de Kubernetes d'un point de vue de l'asor système, un point de vue et suivre eux dans le futur. La plus, nous augmenterons l'usage. Mais ce qu'on voit maintenant c'est que l'engine X utilise beaucoup de mémoire pour avoir les mémoires les plus fréquentées utilisées dans les mémoires servies par soi-même. Les mémoires sont aussi cachées dans le système de file comme Linux naturellement. Donc, cette partie est une autre layer de cachée de mémoire qui protège et qui fait que c'est safe d'y arriver beaucoup de l'IOP. Mais avec le bâtiment, je pense que le bâtiment sera plus impactif. Mais nous avons prévenu la taille de la contenue pour être sûr que nous sommes OK. Donc, maintenant, la mémoire montre que les mémoires ne font rien. Donc, c'est une bonne news pour le test. Nous l'avons fait. Donc, pour être sûr, je l'ai compris. Donc, vous êtes déjà confortables que vous avez des mesures sur le base de données pour comprendre la caractéristique performance de la proche de cachée. Si nous étions à overloader, vous pourriez voir ce que vous avez indiqué dans les mémoires de données que vous avez regardé. Exactement. Nous avons l'air d'améliorer la performance. Comme maintenant, la discurse que nous avons utilisée est de la hausse de l'IOP. Et nous pouvons très bien augmenter leur classe. Donc, si vous avez besoin, nous pouvons nous avoir des mesures qui sont toutes bonnes. Great. Merci. OK. Donc, c'est c'est merveilleux. Donc, on va probablement avoir quelqu'un qui regarde ces mémoires quand on a l'air d'améliorer le bombage pour essayer. Parce que le premier bombage va mettre beaucoup de load, je dirais, sur quelque chose. Je pense que l'éloignage de l'Optin va s'éloigner pour que l'Optin de l'Optin soit très bien augmenté. OK. On les a éloignés. Mais nous encore avons encore plus de ressources de l'éloignage. En escalant, en escalant recentement, en augmentant l'éloignage de l'Optin, en changeant l'éloignage de l'Optin pour un meilleur l'éloignage de l'éloignage de l'éloignage de l'éloignage. Plenty. Donc, on est très optimiste sur l'outil, mais nous allons avoir à regarder les mémoires, ce que le mémoire dit. Quoi-qu'il y a? OK. Donc, mon propos est que nous avons la dernière réquestée pour le label. L'une de ces réquestées est de merge. Nous pouvons immédiatement envoyer un email aux développeurs qui vont laisser 24 heures avant d'appeler le changement. Est-ce que c'est OK? Il laisse un jour si quelqu'un complète ou si quelqu'un objecte de dire que ce n'est pas dangereux ou si il y a quelque chose important ou que je ne veux pas utiliser l'ACP. Ça fait du sens pour vous? Je ne sais pas si quelqu'un objecte ce que nous ferons. Nous nous apprendrons à éviter l'ACP par établir un flag qui n'est pas d'éloignage d'improxies et d'évoluer les deux forces. Nous ne pouvons pas l'éloigner et nous le mettons dans la même brigue comme Olivier et Tyler comme nous l'avons dit. Ça dépend de l'objectif en réalité. Donc, on verra. Oui, je comprends que ça pourrait être vraiment frustrant si quelqu'un dit que j'ai eu cet issue et que nous n'avons pas l'éloignage mais nous devons écouter aux utilisateurs. Donc, nous ouvrons la discussion et nous verrons si il y a un objectif. Si il n'y a pas d'objectif, nous pouvons procéder. Je serai le premier et le plus frustré d'un personne si nous n'avons pas l'éloignage d'éloignage. Nous avons vu ce qu'il y avait. Nous avons vu ce qu'il y avait avant. Nous avons eu un variant de ce qu'il y avait sans aucun compléance. Donc, Olivier a déployé quelque chose comme ça précédemment et nous avons réveillé ce déployement quand nous l'avons vu qu'il n'a pas semblé d'aider la performance. À ce moment, nous n'avons pas de banque avec la consommation. Et donc, je pense que nous sommes prêts d'annoncer et si il y a d'objectifs, oui, nous donnons de temps pour d'objectifs, mais ça serait un objectif très important de nous arrêter de déployer ce déployement. Nous avons dû mettre notre banque à l'aise. Ou une grande check. Si on veut mettre le déployement. Oui, c'est une solution. Je veux dire, si quelqu'un met 25K par mois, je n'en pense pas de ne pas déployer et de payer le déployement. Je veux dire. Ils n'ont jamais offert ils n'ont jamais offert de charge. Si on les a offerts, si on les a offerts, je suis sûr qu'ils vont exercer. En tout cas, est-ce qu'il y a quelque chose d'autre sur l'ACP? OK, donc la prochaine priorité est de déployer ces items. Et puis, nous allons commencer d'expérimenter le déployement de l'accompagnement et nous allons les réprimer la prochaine semaine. Les statuts, puisqu'on les a offerts, on peut avoir un délai. Depuis que nous avons une réplique de réplique de GIFROG, la prochaine semaine, on devrait déjà montrer quelque chose. Mais peut-être une semaine n'est pas enceinte. Donc nous devrions attendre deux semaines avant d'avoir vu un progrès réel. OK. Si quelqu'un objecte la prochaine question, sur l'accompagnement d'accompagnement est en train de faire. Donc... Je l'ai fait hier hier aujourd'hui, donc ce n'est pas fini. OK. Tu penses que tu seras capable de marcher dans l'accompagnement? Oui, parce que je le sens super facile. Donc j'espère que je serai capable de faire. OK. Je ne peux pas dire ça. C'est le même. C'est le même. Donc... On a fait des recours que certaines de nos actions GIFROG ne sont nécessairement à la date. Dans cet exemple, nous avons utilisé Github App Token Action. Le proposo est d'améliorer la dépendance sur ces repositories. Donc la dépendance va facilement maintenir le tract de ça. Pourquoi ne pas l'update CLI? Parce qu'avec l'update CLI, nous devrions mettre beaucoup de codes pour chaque action GIFROG. Dès que dans une guerre idéale nous devrions l'accompagnement de GIFROG à un pire de genk et de spills. Le proposo était de l'utiliser la dépendance et juste d'assurer que l'accompagnement de GIFROG est en train de l'améliorer ces packages GIFROG. Qu'il y ait de l'objectif et de l'inclurement. Ok, donc nous l'avons à la prochaine milestone. La prochaine demande est de publiciser le nouveau cluster dans la nouvelle networks. Donc Hervé, est-ce que vous êtes ok de rapporter les phases d'apprentissage et l'apprentissage? Je peux le faire si vous n'êtes pas... Non, non, je ne peux pas. Le cluster est en train de l'améliorer et l'impact de l'accompagnement est en train de l'améliorer. Et la prochaine étape est de l'immigration de tous les services qui sont en train de l'apprentissage dans le public public. Ok. Donc, l'issue mentionne la liste des services qu'on peut avoir besoin de l'updater. Certains services seront migrés au nouveau cluster public. Certains services seront migrés au nouveau cluster privé. Comme l'apprentissage de CI, après le code change et après le LTS, si c'est ok pour tout le monde. Certains services ne seront pas migrés. Donc, on va juste vérifier avec Olivier. Mais le proposant est de ne pas migrer le Grafana Prometheus stack. Parce qu'on n'est pas en train de l'utiliser. Prometheus semble être dans une mauvaise forme. Notre installation, pas le software itself, le software itself marche très bien. Mais nous avons un Datadog, un Datadog fully-fledged. Nous n'avons pas de risques pour le Datadog en passant. Donc, maintenant, au lieu de payer des ressources pour le storage et le compute sur le Grafana que nous n'avons pas utilisé, je propose que nous ne migrions pas au nouveau cluster. Nous allons détruire tout le cluster en réalisant ces ressources. Et puis, nous pouvons commencer dans le futur le sujet de si nous avons besoin de Grafana stack pour collecter des traces pour le CI Genkin ou des traces additionnelles, des collections de traces log que nous ne pouvons imprimer ou ne voulons pas avec ce Datadog. Ce sera un autre sujet. Mais maintenant, le but est d'éviter le duplication quand l'un des deux outils n'est pas utilisé par nous. Il a été utilisé en passant et ça a été une grande aide. Mais nous n'avons pas vu depuis un an. En termes de la timeline, est-ce que c'est ok si nous mettons les publicités sur hold pour les 10 jours ou les 10, 14 jours? C'est le temps pour nous de finir en marchant sur le bombage. Et éventuellement, si nous avons de temps, nous pouvons commencer le plan pour les publicités. Est-ce que c'est ok pour vous? Oui. Ce n'est pas... C'est bien sûr. Nous pouvons absolument prendre de temps en préparant le plan et en réveillant la liste des services. Et on update l'issue mais je propose que nous attendons pour la prochaine week, à la liste. Et nous allons avoir un sub-issue avec le database. Oui, absolument. Nous devons trouver un moyen pour avoir le database qui est sur le système d'ordre pour être riche quand nous migrerons. Nous avons expérimenté les éléments. Donc, c'est partie de la discussion. Il dépend de la plan. Nous voulons essayer. A.C.P. s'adresse à plus de choses comme Asba. Qu'est-ce qu'il y a ou quelque chose qui est prêt pour cette entrevue que vous voulez mentionner ou est-ce que c'est ok? Je ne me souviens pas de ce que nous disons sur ce topic. Non, c'est ok. C'est ok. C'est presque pareil pour le clé privé. Ok. C'est été préparé mais nous allons en faire un peu plus tard pour faire un premier déjeuner. C'est bien. Il marche bien maintenant. La prochaine émission est de jouer le tournoi dans nos images d'agent. Stéphane, pouvez-vous nous donner? Vous savez que je ne le sais pas. Je n'ai pas pu faire la dernière week. Et je l'ai oublié. Pourquoi vous l'avez appris? Mais c'est fait. Et vous voulez faire quelque chose pour le fermer. Mais je l'ai oublié. Déployez-le pour la production. Oh, ce que vous avez fait la dernière semaine, si je suis correct. Donc, peut-je vous placer l'issue? Oui, avec plaisir. Merci. D'ailleurs, merci pour l'endler, Stéphane, parce que pas seulement vous avez fait le tournoi déployé la dernière semaine. Mais aussi, je l'ai oublié. Si j'ai oublié. Donc, le tournoi était en 0,55. Oh, oui. Et l'agent en template 0,56 donne un gdk pour tous les gdks. On avait le tournoi plus tard pour 8, 11, 17 et 19. Et aussi, ce que l'on a fait le tournoi. Donc, merci beaucoup pour ce tournoi. Et enfin, la dernièreissue est réellement Repo Genkin, CIOG Mission. Donc, on s'occupe de l'ACP. Je l'ai trouvé une charte urbaine qui nous permettra d'avoir l'HALDAP. Donc, je suis maintenant jouant avec ça sur le cluster local. Si possible, ce n'est pas pour tout le monde. Je propose que nous voulons tester ce nouveau HALDAP sur le cluster public. Donc, si nous devons enlever l'authentification, nous devons migrer l'HALDAP en tant que nouveau système. Parce que ça nous permettra d'avoir un bloc de bloc de bloc facilement. C'est tout ce que j'ai fait. Je suis tard en essayant de l'écrire et nous sommes en table, Marc et Haït qui travaillent sur l'authentification pour la communauté. Je n'ai pas encore l'action à l'adaptation de Damien. Maintenant, l'analysation des rapports indiquent que l'alignation ne va pas réclenter la majorité des problèmes. Donc, le rapport que nous voyons signifie que l'accès que ça change n'est pas les problèmes principaux. Et donc, nous essayons de résolver les problèmes principaux par d'autres moyens. Mais les repos ne sont pas les problèmes principaux. N'a-t-il question sur ça? Non, ok. Nous avons quelques nouveaux problèmes. Donc, l'adaptation de l'adaptation de Jean-Kinzayo de la dépendance du projet. Donc, ce n'est pas la priorité, mais merci pour l'opérer. Parce que, pendant l'opération de l'adaptation, nous avons vu que cette image n'a pas été réclenée depuis des mois, si pas des années. C'est toujours en utilisant pas seulement les 9, ce qui est comme si j'avais Jean-Kinzayo en train de gagner le GDK6. Je suis juste un peu exagéré, mais c'est pas la version LTS de la mode. Bien sûr, c'est pas la version qui peut avoir des effets de côté. Donc, ça me fait un peu de temps. Et bien sûr, toutes les dépendances internes dans cette image. Est-ce correct? Ou est-ce que j'ai oublié quelque chose d'autre? Non, ça ressemble bien. Donc, nous devons... J'ai eu l'issue d'adaptation du GDK6 et peut-être d'autre pour réclenter la collection de Sentry pour peut-être le GDK6, je ne sais pas. Je ne sais pas, c'est un peu juste ce genre de flot. Pour flexibiliser l'application de Jean-Kinzayo Sentry. Sentry, le placement ou l'accès? On va devoir créer des souhaits en termes de planir. J'assume qu'on ne va pas marcher sur celui-là pour les prochaines 2 semaines. Est-ce correct? Oui. Donc, ça va aller au backlog? Oui. Découpez le code. C'est fine, mais oui. Je veux dire, ça marche. Il n'y a pas d'urges pour le faire, jusqu'à... On a un CVE, un GDK6, un GDK6, un GDK6, un CVE, bien sûr. Je suis sûr qu'on a des. Et pour remettre Jean-Kinzayo, pages n'ont pas d'accessibles et d'indexes n'ont pas d'indexes. Fun 1, c'est comme si le processus de déploiement n'a pas de déploiement des pages quand on déploie, c'est juste de contenus. Donc, chaque fois qu'on remet une page de Jean-Kinzayo on a besoin d'une opération manuelle. Je ne vois pas ce que c'est un problème, mais il doit être documenté sur les pages de Jean-Kinzayo dans la section de contributation, disant que si vous ouvrez un call-request, s'il vous plait, il doit être documenté sur notre site, avec un livre-run, qui dit qu'il y avait un file, etc. Et on automatique ça. On peut, mais le problème, c'est un problème connu qui a existé depuis longtemps. Mais ce n'est pas un problème, ce n'est pas un problème pour moi, c'est un futur. Oui, c'est un comportement connu. Le bug ou le futur c'est une question subjective, mais c'est un comportement connu depuis longtemps. Donc, oui, on peut automater ça, mais je dirais que la priorité est basée en automating ça. Bien sûr, mais j'ai demandé pourquoi ça se fait comme ça. C'est juste parce qu'il n'y a pas une raison particulière pour se faire comme ça. Tu es correct. Daniel's answer serait mon answer, parce que c'est comme ça. C'est une réponse terrible, mais c'est la vraie. C'est juste la façon dont c'est écrit. Olivier's answer, on disait mais c'était deux ans plus tard. Ok, la dernière fois que quelqu'un de la communauté voulait retirer une page, c'est pas Jean-Kin Sayo. Alors, basé sur le record, la historie automatique automatique n'a pas besoin de perdre des données, c'est-à-dire qu'il faut construire un certain niveau d'accès avant d'avoir une chose complète. C'est aussi mon point de vue, parce que vous avez un site web sur une image doc sur le papier qui marche, mais dès que vous devez rouler, c'est compliqué. L'issue avec Jean-Kin Sayo, c'est pas une machine avec un contenu et un instant. Ce serait facile d'automater en ce cas. Dans le cas de Jean-Kin Sayo, vous avez un système distribué qui a localité et qui peut parfois s'assurer que le file soit élevé. Et ensuite, vous avez un système distribué de CDN qui peut être décaché. Vous avez deux systèmes distribué qui dépendent de l'un à l'autre. C'est-à-dire que, si vous voulez automater les délicieux dans ces cas, vous perdez vos nets de sécurité. Je suis sûr qu'ils peuvent faire quelque chose avec un label, créer un PR et tout. Non? Mais au moins, j'ai des réponses. C'est un message historique. Maintenant, je comprends tout ce qui est frustré. La raison est que je ne crois pas moi-même. Je ne crois pas quelqu'un dans le 6 de l'heure pour pouvoir automater cela avec le succès. Je ne veux pas le faire maintenant. Mais au moins maintenant, je sais pourquoi c'est comme ça. Il y a un peu d'intes sur comment retirer la page. Exactement. Manually, dans la baguette. Ok, on est en train de penser. Mon goal était de donner des éléments pour comprendre pourquoi. Maintenant, on peut penser sur comment automater le succès. Et pour moi, le premier et immédiat step que nous devons prendre est de documenter ce processus. Dès l'activité et du travail de l'Ontario, ce genre de choses ont apporté plus en plus. Et quand nous avons documenté et que nous sommes en train de automater le procédure, nous pouvons automater facilement. Je suis sûr que vous aurez des idées brillantes que nous n'avons pas parlé de pour faire cela. Je n'ai pas adopté cela. Mais nous devons atteindre des layers de confiance de nous-mêmes. Nous devons regarder sur le site quantifié dans la question pour faire un procédure sur ces URLs. La question est quand ? Mais oui, maintenant, documentation. Short terme. Documentation Both jenkins.io plus clean up this page to test the whole operation one time. Long term automate clean up. One of the ideas that has been cancelled by Olivier was to build a jenkins.io docker image with docker root within that would have removed the need for that bucket and it would have been fully stateless on our cluster removing one constraint that worked very well but the time required to build the image and deploy the image and the constraint of our auditability with Kubernetes management records. The combination of everything made it complicated and slow. That's the main pain because security advisory need to be published quickly and the amount of time required to build the image and deploy it was out of question when publishing security advisories. So that's why I think Herve's ideas might be a better and good way automating both cleaning up on the buckets and the cash cleaning. Any question? New issue Frequent PagerDuty Alerts disk space is below 1 gigabyte we pick about that 2 weeks ago I've put on written way and now we have actions on that mainly updating CI, jenkins.io and also controller setup to be sure that all age and virtual machines are ephemeral especially the windows one and then if we keep having the image we will have to find if there are failed builds or we will have to increase the disk size that's the summarized version if you want details on why and what it's written on the issue, don't hesitate to ask. Finally, ask Linux foundation to renew our GERA license. As Mark pointed out the GERA license we have is need to be renewed for issues jenkins.io to continue working that will be a Linux foundation ticket asking them to update and they will take care of that. If it's okay for you I will take it but I don't mind having anyone else bearing with me. I think Mark already I signed himself. Oh, okay. Bonne question what will happen when Atlasian will build their user but it's question for later. Yep we will stop the service I don't know that's a good question. Okay, sorry I was a bit slow today because of the ECP. I don't see other new item something else I got my choupi orbit that's fine it's down there. Okay, so I will stop sharing screen I will stop recording and then see you next week