 Bonjour tout le monde, bienvenue à la Team Meeting d'infrastructure de Jenkins. Nous sommes le second jour de 2024. Donc, bonne année à tous ! Aujourd'hui, nous avons moi-même dameur du portale, Stéphane Merle et Bruno Verrarten. Hervé est off, cette semaine. Je pense que Kevin n'est pas disponible, et Marc va nous rejoindre plus tard. Allons-y, on commence. Donc, la relance du week-end, 2.43. C'était réellement réellement la dernière semaine sans aucun problème. Marc et High ont travaillé sur le texte. Et il a été déployé à l'infrastructure, comme tout le monde était dans les holidays. Hey, le christmas, les holidays ! Donc, pas de problème. Cette semaine, le nouveau week-end réellement, à moins les packages et les images docuées, ont été poussées. Je pense que le change log peut être poussé demain, si Kevin n'est pas disponible aujourd'hui. Eventuellement, Marc, notre équipe, peut s'en prendre. Et l'infrastructure, Stéphane, c'est à dire que vous êtes prêts à déployer l'infrastructure sur l'infrastructure, tout à l'heure que vous voulez. C'est-à-dire que l'image a été publiée ? Oui, cool. N'oubliez pas, il y aura un grand changement de plug-in. Je vais parler de ça plus tard. Vous avez un pull-request sur les images docuées sur le plug-in de coverage. Donc, n'oubliez pas que vous devez déployer l'infrastructure sur l'infrastructure, si vous voulez, vous devez déployer mes pull-requests. Vous pouvez les déployer avant ou après les changements de la cour de week-end. Pas de problème. Mais vous devez déployer ça aussi. C'est un plug-in déployé, changé par le nouveau plug-in, en replantant. Juste le point sur les statuettes de billets. Donc, le décembre était 7,35K, donc juste un peu plus, mais juste un peu plus de dollars en décembre. Donc, nous étions assez bas sur notre goal pour 2023. Donc, félicitations, tout le monde. C'est un bon travail. Et cette semaine, pour maintenant, le forecast est encore irréliable, parce que c'est seulement deux jours, mais le forecast devrait être moins de 7K pour ce mois, grâce au travail du sponsor. Le chiffre du sponsor en itself, nous avons presque atteint le milestone de la 1er 1 000 dollars consommé. Juste pour vous donner un ordre de magnité, nous avons 40K sur le chiffre du sponsor. Donc, ce sont des crédits donné par Azure, et nous consommons celui-là. Donc, nous allons avoir 1K, presque, pour le 40K. Donc, c'est plus que ce qu'on a diminué sur Azure, bien sûr, parce que, comme un souvenir, c'est une instance non-sportée. Stéphanein High a demandé l'obgradation de Cota pour l'instance de spot aujourd'hui. Donc, nous allons passer sur le chiffre qui va nous permettre d'utiliser plus de crédits. AWS, un peu moins que les derniers mois, nous sommes sous 9K. Merci pour le monde, le monde mondial, particulièrement basé, parce que, en marchant sur les bails de bombes, et seulement pour construire les bails nécessaires, nous pouvions réduire presque 1K. Donc, merci pour ce grand chiffre, folks. La conception générale est à 0,3K, donc la même rate que sur Azure. La forecastation est à 8,2K, même si la même forecastation de 2 jours et de 31 jours du mois est incroyable. Digitalization, nous avons assez pour les prochaines 2 semaines à la rate générale. Nous avons discuté avec DigitaloCN, je vais l'émerger plus tard, mais ils devraient appliquer les 20K nouveaux crédits pour cette année, plus tard ou demain. Donc, nous devrions être bien sûrs dans cette période, ce qui veut dire que nous devrions pouvoir s'occuper de notre current workload et même augmenter des usages dans le futur. Donc, c'est une bonne news. Comme des magnitudes, nous avons consommé 38 $ pour le 1er jour de janvier. Est-ce qu'il y a des questions sur les annonces? Hop, OK. La prochaine semaine, nous verrons les autres. Donc, il n'y a pas de conciliation de la rencontre. Donc, je serai là pour le gérer. Donc, il n'y a pas besoin pour quelqu'un à prendre. Donc, je crois qu'on peut vérifier le calendrier de l'arrivée. OK, pour tout le monde. Donc, ça veut dire que nous devrions pouvoir relier le 4.0. Oh, c'est trop beaucoup. La prochaine semaine, la prochaine juillet. Je ne me souviens pas quand est-ce que la prochaine LTS comme d'habitude. Je crois qu'on devrait vérifier les websites de Jenkins. Parce que nous avons perdu. Nous devons être careful. Nous avons perdu 1er LTS pour relier le dernier mois. Donc, j'ai préféré vérifier le calendrier de l'arrivée de l'arrivée de Jenkins. C'est le candidat de relier la prochaine semaine. Ah, cool. C'est le calendrier de l'arrivée de l'arrivée. Nous sommes là. La prochaine semaine, vous avez dit le 10 janvier, le candidat de relier. Le candidat de la prochaine LTS. La prochaine fois. Je crois que la prochaine LTS sera le 24 janvier avec le 2.426.3. La prochaine LTS 2.3. Sorry, 2.426.3. 426.3. 4 janvier. Cool, merci. 24, 24. Oh, 24, sorry. Le 23, 24 est difficile pour le monde le mois de janvier, bien sûr. Parce que nous sommes en 2024, 23 et nous sommes en 24. Merci. Donc, rien pour l'infrastructure la prochaine semaine. Nous devons être careful le 24. Est-ce qu'il y a quelque chose dans l'arrivée de l'arrivée? Non. C'est bon. Donc, pas de sécurité, pas de sécurité. La prochaine événement de la prochaine LTS sera la première. La prochaine, 1, 2, 3, 4, le février, le février 2020. Les brosses. Est-ce qu'il y a d'autres événements de l'arrivée de l'arrivée ou d'un autre élément que vous voulez discuter ou d'un autre élément ou... Oups. Ok. Donc, on commence sur les marques d'issues que l'on a faite. Pas la réplique de l'arrivée de l'arrivée de l'arrivée que j'ai à réopérer. Désolé. Nous pouvons finir le mouvement de l'arrivée de l'arrivée de l'arrivée de l'arrivée de l'arrivée de l'arrivée pour les nouveaux crédits sponsorisés. Comme nous l'avons mentionné dans l'arrivée de l'arrivée de l'arrivée de l'arrivée de l'arrivée de l'arrivée. Est-ce qu'il y a une question? Nous avons deux issues qui n'ont pas été planifiés et qui n'ont pas été planifiés parce que l'utiliseur a demandé une question et n'a jamais répondu quand nous nous avons donné des directions. Donc, c'est terminé. Maintenant, je vais prendre les issues sur l'ordre. J'ai eux ici parce que la priorité n'est pas facile et je propose qu'on spécifie la priorité sur la nouvelle milestone. Est-ce que c'est ok pour tout le monde? Donc, pour tous les items que nous allons couvrir, nous faisons un statut et nous disons si nous allons marcher sur la prochaine milestone. Donc, nous allons savoir si nous avons deux postes. Ok, pour tout le monde. Let's get started with a quick one that should be closed today. The goal is to replace the now deprecated plugin code coverage API by coverage. So that was opened by Alex, thank you. And it has been done. I did it on the CI Jenkins IO and checked on trusted insert. But I closed it last week, but I forgot that it's also on release CI and infrascii. The pull request has been open, as you can see on my screen. So now, since Stefan has to update at least infrascii with the new date, if it's ok for you, Stefan, to take care of this and the same time so one restart only for both plugin and core and simple release. Yeah, ok for you. Perfect. Ok, I'm assigning the issue for you since you are the the taskmaster for the plugin updates. Ok for you. Perfect. Ok, let's remove myself. And that mean you can close that issue once the new once you stop seeing that message and you stop seeing the code coverage plugin that might we might need to uninstall even though with Kubernetes there is an automatic uninstall if the plugin is not provided on configs code. So that might or might not work but worst case, it's uninstall and restart. Ok. Any question? Ok, so that issue is going to the next milestone. If you need help, do not hesitate. Next issue, CI Jenkins IO install coverage page extension plugin. I want to move this one as the last because I want Mark to be there. If he's not there, we will delay of one week. Crawler build fail. Thanks Alex. Alex coked that the crawler was failing since 22 of December. The crawler is a job that which role is to aggregate a set of metadata when running and publish the resulting JSON file sign it if it's on the trusted environment and deploy it to the update center. Then each of your Jenkins instance retrieve that signed JSON file and know how to install what we call Jenkins tools such as JDK, Maven installation and stuff. The job in charge of this was publishing to the current update center but fail to publish to the currently working progress new update center it was failing with a file four or three error. I initially did a mistake and thought it was caused by the recent easy copy to Blobix for credential changes that everybody was working on before Christmas. That's my mistake because there were unrelated change. I then thought it was my fault because I changed the network rules of the trusted CI agents when moving to the new sponsor chip system. However, earlier today while diagnosing this I discovered that that essay is available publicly so that rules out the IP of the agents. Finally it was just a simple error. As you can see we wrote the expiry date and it was the day before the day of the NAS. So that means we have to update it. That part is fixed. There is also an error on AWS that I haven't diagnosed yet but at least easy copy now works. I've reported an update center issue which is related to that new system. And so they are in order to close that issue we need to fix the AWS free S3 error and add a calendar event for the next rotation. Or an update CLI. Yes, absolutely. Yeah, in that case it's only yeah that can be updated easily. So yeah, good idea. You seem eager to do an update CLI. Do you want to try with me? I don't remember but the day we wrote that expiry date I said we better put that on the calendar or doing an update CLI and I should have done that. Look what I'm doing. We will pair on this. Of course. I should shut my mouth. That should be a shell script. That should be okay. That should be quick. So that one is almost there but will be worked on for the next milestone. I remember correctly we did that twice. There is two expirity dates on two files. Six, I should say. That you're absolutely correct. But for now we were using only calendar events. Next issue unless there is a question. Next issue, some builds and CIGN can say you using TDK21 have out of memory errors. I wasn't able to understand where does it come from. It's really weird. It sounds like it's something inside the builds. I don't understand that part. Something to check eventually will be what kind of agent is used and maybe this agent need more memory but that's really weird. At first sight, it needs a bit more diagnose. I've added some link. We need to work on this. I don't know the priority and if it's a blocker or not. Right now, I consider this... I'm moving this to the milestone but that's low priority at first. I'm not sure what is the issue here. It needs specific maven, java, Jenkins. At first sight, low priority. We need help to diagnose. Let me take note. I need you to help me take note, folks. Please. Let's keep it on current milestone at low priority unless argument added to make it more important. Then on ci.g trusted and cert. We need to do it for infra.ci and release. Crawler build fail. As you copy fixed. Experi date of the SAS token to do xaws to do add update CLI. Remind us an update. Thanks. Next... Oh, that one is closed. Kristen, who will be the next LTS release lead, need access to release CI Jenkins.io, which implied first access to the VPN, which they did. And also the proper authorization set on the LDAP to allow authenticating on release CI and being able to build and cancel jobs. That has been done. So I've closed the issue and I can move it to the down issues. Is there any question on that part? Okay. Next one is declarative pipeline migration and plug-in no longer compiled. I have no idea what this issue is. So let's open it and discover all together so we can try age. Oh, I remember. Okay. And mark volunteer on doing the upgrades. Oh, that should be closeable then. That's been merged. Okay, so we can close it. Is there any objection? If we misunderstood or miss something, please reopen with a pointer. So that issue is closed. Yay. I love the smell of closed issue in the morning. Yes. Closed issue. Sorry, I'm a kid. G-Git cloning, not converting and lines on Windows. So a second contributor confirmed that they see a difference when a container agent is used, meaning ACI agent, Azure container instance agent, versus using Azure virtual machine agent. That could be our packer image which could have different setting than the ACI Docker images, or that could be the plug-in in charge of spinning up the agent and setting environment on the agent process. That still had to be changed. But at least that's a confirmation there is something that could be done on the infra level. Last meeting, Mark say that he was taking care of this one. I believe it's assigned to him. So we will move that issue to the next milestone and we'll check with Mark. Next week, if Mark didn't have time, we will have to put our hands dirty on this one, even though it doesn't look like its priority. Because as James said, yeah, that's also up to the developer to change the end line on all files of their repository. So that is not blocking, it's just not inconvenient. Let's... So, moving to next milestone, still assigned to Mark Wait. Note, a second contributor confirm seeing difference between Windows Container Agent and Windows VM Agents could be related to Agent Setup, to Infra Agent Setup. Let me know if I'm capturing and if it's clear for you and if I'm capturing well what we say. Or Plugin setting up the agent or Jigit itself. Is there any question on the Jigit cloning, not converting line ends? Oh, okay. Next issue, Remove G-Center SSNAType from public virtual repo. So, it has been confirmed by Mark directly to Gfrog that we saw a decrease on the boundaries and on the usage. So, the goal is met. This issue is not closed yet because we want to confirm in one or two weeks. So, we let Mark take care of closing once it's okay because he is the person dealing with Gfrog and communicating on that part. And also, I still have an action on my side. I need to remove the SSNAType cache from the public access just to be sure that no one tried to reach it directly. Is there any question? Let's wait for Mark to confirm that we keep having on-with decrease as shown around Christmas and shared with Gfrog. One last item for... Hello, Mark. Hello, Damien. Happy New Year. Happy New Year. Excuse my tardiness. No problem. Tu es venu à un bon moment. C'est une bonne chose que j'ai attendu pour toi. All right. Good. Okay, what do I need to be doing? Just to confirm on the removing G-Center and SSNAType repositories from Artifactory, I believe we were able to see improvements one or two weeks ago based on the logs you retrieved from Gfrog. Yes. I still have to remove that's one last minor configuration item. I need to remove SSNAType cache from public access. That's a minor item. And then that means you will be the master of closing or keeping it open until we are sure we have a bandwidth decrease. And I think we can close it. We did have one very nice outcome of this that a Jenkins contributor détecta un libraire problème qu'on a placé dans Orphans et propose un change dans le corps de Jenkins pour réagir à une nouvelle version donc c'est maintenant offert par Maven Central. Et j'ai eu le courage de toucher ce libraire parce que c'est l'implémentation Java de la cryptographie OpenBSD. Et la cryptographie n'est pas une chose que je touche bien. Je pense que l'expert devrait faire ça. Mais en ce cas, ils ont fait l'analyse et plusieurs personnes ont fait l'analyse et ont vu qu'il n'y avait pas de changement en Java pas de changement en Java entre la version qu'on utilisait originalement ancienne de 2016 et la release qui est disponible en Maven Central de 2021. Donc, un grand positif. Certaines personnes ont fait l'analyse et nous sommes bons à aller. C'est déjà dans la semaine 2.439. Et nous serons dans la prochaine baseline LTS en février. Oui, c'est bon. 24 janvier dans la prochaine baseline LTS. Non, c'est pas la base. Différentes phrases. Je ne pense pas que c'est si urgent que nous devons remercier. Parce que vraiment, il n'y a pas de changement en Java en tout cas. Il n'y a pas de changement en importe et rien n'a changé dans la code en Java. C'était purement un changement pour construire les scripts. OK. C'est à dire que je peux ouvrir l'issue. Je vais vous demander... Je vais ouvrir. Je vais faire le commentaire et ouvrir. Parce que c'est... J'ai commencé, j'ai ouvert. C'est très raisonnable que je devais être responsable. La définition de la fin aussi inclure ma dernière clean-up. Donc, nous avons besoin d'avoir tous les commentaires de ce que l'on a fait. Donc, vous devez confirmer. Et la dernière one will close. Est-ce que c'est OK pour vous? Oui, ça ressemble bien. Merci. Est-ce qu'il y a d'autres questions sur le Parti G-Center? Non, pour moi. Nous allons passer à la prochaine question. Mes greetings. Les leftovers de public gates pour IRM64. Donc, nous avons une bonne liste exhaustive. Je crois qu'on n'est pas capable de travailler sur ça. Je n'ai pas besoin d'être en holidays, oui. Exactement. Les gens d'honneur. Les holidays. C'est à la fin de l'année. Ah, ces gens. Ce qui veut dire qu'il n'y a rien à rappeler ici. Stéphane, est-ce que vous pensez que vous seriez OK pour commencer à travailler sur ceci la prochaine semaine? Oui, c'est ce que vous pensez. Et parmi les autres. 2 ou 3 semaines auparavant, nous avons dit qu'on pourrait faire le burden. Je n'ai pas eu de temps. Mais si c'est OK pour vous, nous pouvons juste séparer les services entre vous et Haïf. C'est OK pour vous. Les autres ont besoin d'immigration. Donc, ils ont besoin d'un travail à faire. Nous avons besoin de convertir. Je ne veux pas dire ce que nous devons faire. Je dis, vous êtes OK? Oui, nous pouvons séparer le burden. Bien sûr. Exactement. C'est tout ce que vous voulez. Je prends 1, je prends 1. C'est ce que je veux. Non, non, non. Je prends 1, je prends 2. Bien sûr, oui. Oui, bien sûr. Mais si je prends 2, vous devez écrire les updates CLI pour changer l'experimentation des créditons. Ce serait mon plaisir. Bruno me l'aider. Bruno, tournez pour votre vie. Il n'y a rien à rappeler. Les workloads sont séparés par les membres de l'équipe. Donc, nous gardons l'issue sur la prochaine milestone. Explore la liste de download de la liste pour la représentation de texte. Est-ce que vous vous rappelez où nous sommes sur cette liste, Stéphane? Oui, nous avons juste la skeleton. Nous avons besoin de l'aile. Nous avons besoin d'improver le contenu de ce qu'on a mis dans la liste. Nous devons convertir dans un JSON et dans un texte. Et d'improver le contenu et faire un petit script pour dégager sur la liste de l'aile pour obtenir ces IPs. Ok, donc la prochaine milestone mais la priorité de la liste. Est-ce que c'est ok pour vous? Oui, je ne sais pas. Je vais pouvoir prendre ma main si c'est la priorité de la liste. Ok. Mais la skeleton est terminée. Nous avons une représentation textuelle. Nous devons convertir dans un JSON. La priorité de la liste. La prochaine question n'est pas moi. Je devais pouvoir déployer cette liste pour la production la semaine dernière parce que j'aurais voulu prendre l'opportunité de ne pas avoir beaucoup de workloads même si je n'ai pas eu le temps de finir. Donc, c'est quelque chose que l'on devrait planter. L'idéal est que je voudrais faire ça la semaine prochaine la semaine dernière. Si c'est ok pour tout le monde qui s'involte éventuellement, s'insulter dans le mirrore pendant à peu près 1 à 4 heures après l'opération. C'est le temps pour le mirrore pour que tous soient scanés et l'opportunité de l'apprentissage de la service pour s'appliquer. Et bien sûr, si je m'ai fait un erreur durant la migration, ce serait un résultat pour obtenir Jean-Kin Sayo d'être disponible ou de répondre aux erreurs pour se downloader. Est-ce qu'il y a un objectif si je plante ça pour la semaine prochaine le matin de mon temps ? Pas d'objectif pour moi. Non, jamais. Le matin de la semaine prochaine pour le janvier 2024. À Paris ? Oui, je vais l'additer sur le statut de Jean-Kin Sayo. Ne tue pas la puissance. C'est ce qui est presque terminé. Comme mentionné avant le christmas, après une réplique de Stéphane Hay, nous devons commencer à appuyer des services en fonction de l'intel du public cluster. Envers les métriques, nous avons vu que l'usage nominale sur les ressources de RAM et les ressources de CPU est clairement plus bas que les ressources et les limites que l'on currently utilise. C'est la fin initiale quand on veut un système de scénarisation en linéaire. Dans ce cas, nous pouvons commencer à appuyer ce qui signifie réduire les requêtes de ressources afin que le cuban et le scheduler puissent appuyer plus de services sur moins de nodes. Et donc nous devons réduire les coûts de ces nodes parce que maintenant nous avons cinq petits nodes et nous devons pouvoir prendre tout sur trois nodes. C'est le but de cette question pour réduire les coûts des nodes sur ce cluster. Les limites vont être gardées en même temps parce qu'on a besoin de mettre un hopper bound qui va quitter le contenu si ils utilisent beaucoup plus que l'usage. Cela devrait être assez facile mais je n'ai pas eu de temps durant les jours de course. Donc c'est la même chose qu'il n'y a rien à rapporter pour faire demain. Quand est ce jour ? Quand est ce jour ? Quand est-ce jour ? Quelle est l'objectif ? Parce que j'ai besoin d'ouvrir un statut pour les services impactés par ce changement. OK, Stéphane, peux-je vous rapporter sur l'infrascié, Jean-Kinzayoune, en utilisant un RM64 ? Oui, pouvez-vous ouvrir l'issue pour moi aussi ? Oui, parce que j'ai commenté ce matin avec vous, en fait. Et oui, c'est ce que j'ai utilisé pour utiliser l'Irm NotePool. Nous avons choisi d'utiliser les outils qu'on a besoin sur l'image de l'agent dans l'Olin1. Donc j'ai installé les outils que nous utilisons pour l'Helm et l'Alphile pour la nouvelle tag, 144.0. C'est publié ce matin. Je dois mettre cela en production. Ce n'est pas encore en production. C'est juste disponible. Et ensuite, on va pouvoir changer les pipelines pour utiliser cette nouvelle image sur l'Irm 64. Et nous avons listé toutes les repositions que nous utilisons maintenant avec Terraform pour utiliser ces nouvelles outils sur cette nouvelle version de l'agent. Donc c'est le travail en progrès. C'est bien, est-ce qu'il y a une question ? Ok, donc nous ne savons pas, nous n'avons pas listé l'exhaustif de tous les travail que nous utilisons des agents Intel. Oui, mais ces deux sont les deux plus grands que nous utilisons. Donc, on va voir si nous pouvons utiliser l'Irm 64 pour cela, parce que peut-être que nous n'avons pas. Et quand ces deux sont prêts, je vais laisser Stéphane continuer de traiter d'autres outils qui utilisent d'autres non-Irm 64 images. Oui. Ok. Donc, un file N prêt à être répliqué par tous les N1. Le management de Kubernetes est le next target pour l'Irm 64 agent. Puis, tout l'agent Terraform a été répliqué pour un changement de libraire. Ok. Merci pour les rapports. Qu'est-ce qu'il y a? Ok, donc le prochain. Rénewer l'Océan Digital pour 2024. Donc, merci pour le travail de l'arrivée de l'année dernière. Nous pouvons avoir notre sponsorship rénewé par l'Océan Digital. Ils étaient en train de commencer et nous avons contacté d'eux d'aujourd'hui pour être sûrs qu'ils n'ont pas de crédit. Donc, comme j'ai mentionné dans cette rencontre, nous avons encore presque deux semaines de crédit qui ont été restés aujourd'hui. Et ils répondent promptly en disant qu'on va appliquer aujourd'hui ou à l'avenir demain. Et ils proposent même 20K au lieu de 9, 18K. Mais ça veut dire qu'on n'a pas pu poser pour d'autres crédits jusqu'à la fin de l'année parce qu'en fait, on consomme 18K et 8,4K plus de 10K l'année dernière. Donc, on a fait un peu plus que ce que l'on expecte et ils veulent rester à 20K max pour ce projet d'opensure ce qui fait sens que c'est déjà beaucoup que ça couvre beaucoup plus que ce qu'on a besoin d'aujourd'hui parce que ces crédits additionnels sont due à des problèmes et des questions qu'il y a que l'on consomme presque 8K en deux mois que ce n'était pas expectant. Maintenant, nous contrôlons ce qu'on fasse ce qu'on fasse donc ce n'est pas le cas anymore. Donc, c'est une bonne news pour nous. Comme un souvenir, ce sera de s'assurer l'archive de Genkin et l'enseignement de bandwidth, des downloads et des machines. Donc, c'est une really, really good news. Donc, merci, Survey et tout notre merci à Digital Ocean. Je crois que nous pouvons commencer à penser sur le blog post 1 pour remercier eux ou faire quelque chose éventuellement parce que c'est vraiment vraiment aidant. Nous avons renouvelé notre chiffre sponsor pour 2024. 20K crédit devrait être appliqué aujourd'hui ou demain à notre compte. Nous avons deux semaines de crédits à la suite. Donc, nous ferons l'issue une fois que le crédit sera appliqué sur l'account. Est-ce que c'est OK pour la définition de ce projet? Cool. La prochaine issue pour Stéphane est de la version Ghost Tracking. Can you give us a heads up on this one? Yes, I did the window spot before the holidays and I need now to do the merging, the factoring between Linux and Windows for the common stuff and rework all the DCI matching those ghosts, those ghosts, sorry. Common tests check all that's the dependencies. That's a back task. Low priority. Cool. Thanks. Is there any question? Thanks for your help. No problem. Next step. Replacing Blob X-Faire by AZ Copy. So the common line we use on multiple areas on the update center, crawler and other tools. Use Blob X-Faire of old Python common line to copy data to the file storage using storage account and object storage on Azure. But that tool hasn't been updated since 2021. So it's time for us to switch from that tool to a new one named AZ Copy and recommend it by Microsoft. The AZ command line does not allow to copy objects as we will want and the AZ Copy. AZ Copy has been used extensively by Hervé when he when he shaped the proof of concept for the new update center and it looks like it's working very well. That's also used by the crawler as we mentioned earlier today. That means we should be able to use it everywhere. The status right now is that Hervé is currently fighting the AS token. The goal is to have a secure setup where we can revoke the token at any moment whatever method and eventually have expiry date. We already have one crawler so that should be easy. But Hervé was trying to to have a fine tune grain and really tune system. It looks like we can use storage accounts and then in the future eventually use identity management meaning the virtual machine don't need even a token. I have mixed feelings about that kind of setup though. That's a different story because if there is a takeover somewhere on Azure system then that means we are doomed. So we need both of them. Yeah, the token is is dangerous because we need to rotate it. So at the moment we need a system where it's put in clear for a few minutes until we have applied it. That's the danger. So if there is a takeover of the machine of one of the administrators that can be dangerous. But in the case of the identity management that means any other job running on same virtual machine will be able to takeover. So for some jobs it's okay such as the crawler because the crawler only use ephemeral agents. But for the update center that can be a problem because the update center use a permanent agent. So that means if you have access to any of the job of trusted CI you could get the access. Maybe it's affordable maybe not, I don't know. But that's something to be to take care. So right now nothing to report. I remember that I read it some stuff before the early days but I don't remember which one. It's there is no command. So I propose that we put this as nothing to report and move it to next milestone. And I will take care of that when it will be back. Is that okay for you? Initially, we discussed about me taking over here but since there we have the crawler issues and since the crawler issues are related on the ACS token that AirVay is currently digging my proposal is that I focus on fixing the crawler and adding restriction on the crawler itself so that AirVay could cherry pick the knowledge and I play it here. Any objection? Okay. Nothing to report early days. Moving to two milestones early days for AirVay. Currently focusing on fixing and restricting is there any question on the ACS port? So knowledge can be cherry picked in this topic. OK, so then moving to the update center, the new update center system. A few things to update. So as a reminder, we still need to battle test this from the point of your performances. So performance test to be run. So we need to spin up an injector system that will inject requests at the high loads on different loads to see when does the system break. Second, we need to restrict the token used by trusted CI for the ACS, just what I mentioned earlier. And finally, we need to wait for a review from the Genkin security team on the data center pull request by AirVay. Minor update as part of the crawler. I saw that there were two credentials with the same value. One was the full URL while the other was only the query string. The query string is currently used by AirVay's pull request and the crawler. And I think the URL based on what I see on the issue, the URL token wasn't required anymore. It was too much painful to be used and they worked a lot on only using the query string. So I've removed the credential to be sure we don't we don't do any human error since it's all managed manually for now. And I've updated the data center job to use the new one because we didn't test the data center since three months that could explain the presence of that credential. The data center did not fail after that change. So we are all OK there. That will ease AirVay's life when it will be back. So for now, we won't be able to work on this one because we need the AirVay and fixing the crawler. So if no one object I propose to move in two milestones. Is that OK for everyone? Except minor credential cleanup. OK. Marc, I move this one as the last one. Installing it's a request to install the new coverage pages extension plugin non CI Jenkins IO. OK. I'm sure if we search, we might see a rotting issue or a closed issue in our help desk about removing the embeddable build status on CI Jenkins IO at least one year ago. Because we were wondering if it wasn't causing performance issue an outbound bound with download from CI Jenkins IO. OK. Let me search for embeddable. Maybe it's closed. I'm searching for this one. Consider removing embeddable build status plugin. So that issue was initially opened by Daniel. The reason was the plugin wasn't actively maintained. So that was unsustainable. We removed it from other instances. But for CI Jenkins IO, if I remember correctly, we were breaking things. Then the plugin was updated despite the in order to fix the CVS. OK, now someone in that room and they're in pop up. OK. So Mark, you and there in you adopted the plugin, right? We did and and I made a. What I thought was a relatively significant performance fix as an early adoption change. Cool. So there was there was some particular code that I looked at and was horrified. And when I'm horrified by code, that's a really bad sign. It's like, oh my sakes, what is that doing? And so that horror has been resolved and released in the in the plugin. I don't know that CI Jenkins that I would ever have encountered that horror. It was just a terror for me. It was. Whoa, how could this code possibly have considered as acceptable and something as accès as frequently as embeddable build status? OK, so which mean I wanted your advice and security advice on that topic. And I think I think security is still the right thing to ask because I may have missed something. I think the embeddable build status plugin is OK now to stay on CI Jenkins. Oh, unless we've got data that says it's causing an undue load, that that part, I can't answer, right? I've never done a data analysis to see see if it's if it's causing undo outbound bandwidth. I started checking the code even though I won't have your high on checking performance issue, at least the code is simple enough that if we if we do a threat dump, if we see CI Jenkins, you're being slow, we do a threat dump who will be able to immediately identify if it's there is some code stuck on that plugin. That one feels easy for me. So I don't mind the performance, but I just wanted to be double sure because my recollection was the embeddable status plugin should still be removed, but looks like it's closed. So I'm not. Shall we proceed and ask asynchronously the GenSec team for a careful review? I think we should. I I think it's good to ask GenSec before we deploy a new plugin to CI Jenkins. I would just that's a really good pattern for us. They're they're a good safeguard. OK, so I will command the issue and I will mention people. It's just that I know the GenSec team is always busy and I will prefer having them checking on the data center than this one because the risk in term of security for CI Jenkins you are not that much. We don't have a lot of credentials that could be taken over here. And that's a fair point. We might we may next week decide we're going to stop waiting for GenSec. We've we've assessed it ourselves. I think that's OK if we give them a fixed period and say if they haven't been able to to review it, we accept that. And the code is simple, right? This is this is really not a very involved plugin. That's why if it's OK for you, I propose since that issue is closed, I will mention it's closed because it has been adopted because I remember ambitable bill status at security issue. That's all I remember. And now we just saw together that you adopted. So for me, it removed what was a blocker for me. So if it's OK for everyone, I schedule that issue to Dono Milestone. We proceed for installing that because we have a contributor who looks really careful and is helping us. So I will prefer taking the risk on CI Jenkins given it's a low risk. And due to what we said, we still mentioned the Jenkins security team, say, A, for information. We have installed that. So we explain how we adjusted that risk. And we see if you have time or a point of view on this, please look at it. And if you don't answer no problem. Do you think it's OK? Do you think that's a proper? Yes, I think that's very reasonable. Absolutely. It's the adding the coverage plugin is not significantly increasing the threat, the risk profile of CI Jenkins.io, right? I think you've described it very well. It's if embeddable build status has some un resolve performance problem. It still has that whether we add coverage or not. OK, so risk versus benefits still pinging a sink low priority, the Jenkins team for the sake of sharing. OK. Is that OK for everyone? Cool. 96. OK. We still have a lot of issues. I'm sorry. That was all the days. I've put some issues on the next milestone and we need to check them. I will order a priority based on what we said. First one. Top priority, the DNS domain name expires in 25 days. We can close it. Oh, it has been renewed. It has been renewed. Just close it. It's and that was the that was the scenario we envisioned, right? I think when it hits 28 days, Tyler's renewal happens and so confirmed that it is renewed. OK. May I ask you to close it with a message showing how do you check for this? That will be easier for next time. Cool. I'm still keeping it on the next milestone and it will be closed immediately. Yes. Thanks, Mark. We have a request by Alex about the Proving Elementio GitHub integration for the repository permission of data. That's a good idea. Useful. I'm not sure about the permission that it gives. So that need to be read carefully because I understand the needs. But if you see on my screen review requests. So it's only one repository. That's the good thing. But it can read access. OK. And read and write access to actions, issues and pull request. So it's really OK. So that should be OK. It should not be able to change code. So that one does it looks good for everyone because repository permission of data as a reminder. Once a pull request on the code on the main branch is merged, that will effectively grant access to repositories and plug-in. So that's a sensitive repository. Even though I was scared this morning because I saw the right, but in fact it's only action issue on pull request. So it's for the bot to have the bot opening pull requests. So that doesn't remove any human validation. So that looks really good. So that one is removed. And I'm going to approve it. OK. Any question on that one? OK. Then add not my fault to Genkins admin group. So he need administrative access to CI Genkins. Which is OK. Just to be sure, I need to check the permission granted by Genkins-admins group. I know what I saw when I granted access to Christian to release CI. I realized that it's a math for this group. So maybe we need to plan and carefully check. So the goal here is to have Alex only having administrative access to CI Genkins. He cannot be admin or top-level admin, only admin on CI Genkins. That's really important, not because we don't trust Alex, but it's just to avoid having too much permission to everyone. Any question on this one? My proposal Stefan is that we will have to pair on this one just to see the state of the non-art and see what could be done and where are the real configurations so we can see the source of proof for this. And we can update that issue as soon as possible and then start planning for cleaning up things. Est-ce que c'est bon pour vous? Oui, je me souviens qu'on a déjà dénoncé quelques mois plus tard, ce n'était pas facile. Cool. Donc, plus de triage. Un nouveau issue est ouvert suivant le message Daniel. Il a l'air d'avoir un soucis pour downloader le data sur Uplink. Je pouvais reproduire l'issue et voir un nouveau erreur. Donc, une survey de thanks pour me filtrer les erreurs dans tous les jours. Donc, ceci est l'erreur mais mon connaissance s'arrête même si nous avons l'application des PGA toasts qui me fait penser que Daniel est là. Il peut y avoir un problème avec le database mais je ne sais qui. Donc, nous devons vérifier le database sur les sites Azure et éventuellement, le code. Il n'a pas d'idée d'appliquer à Uplink et d'enregistrer le code pour que ce soit une bonne chose. Si quelqu'un a cette connaissance, c'est bienvenue à l'aide. Je suis en train d'évaluer la priorité de ce message. C'est vraiment... Oui, je ne... Je suis d'accord que je pense que c'est pas une priorité. Je sais, Daniel, c'est inconfortable de dire que c'est une priorité mais je ne pense pas que c'est presque valable pour le projet de Jenkins comme notre travail sur les updates.janks.io migration. Donc, pour moi, j'espère que c'est différent mais la réalité est que même si on a perdu le data télémetrique et qu'on a dû le redouer entièrement, ce serait encore moins valable que les sauvages de la cause que nous essayons d'achever avec updates.janks.io. Ok, merci pour le point. Donc, la priorité de ce message. Oui, maintenant je suis ouvert à d'autres qui me disent que je suis d'accord mais je pense que dans le projet de Jenkins, le data télémetrique n'est juste pas bientôt valable, c'est un sénat de la cause sur les updates.janks.io. Ok, je pense que ça fait du tout, et cela est clair pour moi. Donc, je vous en prie. Qu'est-ce qu'on a? Qu'on a bien couverté. C'est une bille de croix, c'est un export. Si le plan n'est pas installé, donc je dois le commenter mais ce qui veut dire Le message de triage, nous avons de nouvelles questions ? Mes premières questions ? Ok, ça doit être vérifié. Je crois qu'ils n'ont jamais répondu. Mais on n'a pas répondu, donc on doit vérifier. Éventuellement, ça pourrait être un message. Le mail a l'air... Sur celui-ci, j'ai fait une cheque initiale. Et j'ai réalisé qu'il y a une technique que j'ai utilisé, et je ne suis pas sûr de savoir comment l'utiliser. Donc, j'ai vu vous dans le passé dire aux utilisateurs, Hey, je vois que vous avez eu cet account créé, et c'est vraiment là. Et ça matche ce username et le mail. Mais vous avez pu leur dire, mais on vous a envoyé un message mail, et je ne peux pas vérifier ça. Est-ce que ça aurait été... Ok, si j'avais juste fait un reset password pour cet utilisateur, moi-même, ou... En ce cas, ça ne marche pas, parce que si... On doit vérifier l'erreur sur Datadog. Tout le monde ici peut le faire. Sur Datadog, on cherche sur le log issue. On peut le faire après la rencontre, quand on arrête la recording. Je peux vous montrer le point. Et le but c'est de vérifier l'erreur sur l'application d'account. Donc, quand la personne l'a essayée, la plupart du temps, ils reportent que l'email ne pouvait pas être sent, ou qu'il n'y avait pas d'erreur, ce qui signifie que l'erreur est sur le server SMTP. Ensuite, on doit bouger, et je me souviens que c'est mailgun, ou tout ce qu'on utilise ici. On peut logger dans l'application et vérifier l'erreur, et les erreurs sont clairement montées. Ok, le fail de SMTP, l'email n'existe pas, l'email n'existe pas, le fail, etc. Ça fait du sens ? Oui. Donc, ça doit être vérifié. On va retirer le triage ici, et ajouter-le au milestone. Ok, maintenant, on n'est pas sûrs de la priorité de ceci. C'est pour ça qu'on a toujours le triage. Parce que, maintenant, j'ai eu des éléments, on a vu l'erreur, l'espace Java, mais on n'a pas l'idée de comment ça marche. On peut avoir besoin de quelqu'un avec connaissance en Java. Je ne suis pas sûrs qu'on peut vérifier les métriques, c'est peut-être quelque chose de l'infraside, mais ce n'est pas facile de comprendre ce qu'il pourrait être. Je ne suis pas sûrs si c'était un contenu, peut-être qu'on peut vérifier si c'était un contenu. Mais pour moi, l'espace Java est le mot dans le contexte d'un contenu. On a besoin de voir si il y avait un kill en O.M. parce que l'espace Java signifie que vous essayez d'allocer beaucoup plus de mémoire que d'explication. Ce n'est pas correct. Je ne sais pas les interactions, mais je pense que cette fois, ça peut arriver. Il y a encore de la fin. Je l'ai vu dans les dernières 48 heures. Mais c'est un bon point de bien résolver. Ce n'est pas free, on le fait à un autre point et le prochaine est souvent passée. C'est purement bien parce que c'est la même taux de mémoire Et c'est ce qui fait, au moins pour moi, surprenant et surprenant. Ok, j'ai fait la même chose, avec la même code, et cette fois-ci, je n'ai pas obtenu des souvenirs, ou je n'ai pas donné ce message. Si je vous remercie correctement, le Java Hip est installé à la launch de Java, et vous avez dit que c'est la propriété, donc ce n'est pas changeable. Et j'assume que c'est un kill de OOM. C'est un message venu d'un kill de membre. Mais je ne sais pas, je suis d'accord avec Damian. Depuis que c'est Mavin qui reporte le space de Java, ce serait un processus d'enfance. Le processus d'enfance recevra un code 1.39. Je ne suis pas certain, parce que le processus d'enfance et le processus d'enfance devra être tué. Le contenu de la main devra être tué par le error OOM. Ok. Parce que le kernel va prendre la partie de la partie de la partie de la main et le tuer globalement. Et ça va résoudre. Donc nous devons vérifier si c'est un kill de OOM. Si non, on va vérifier la mémoire, la mémoire usage. On va vérifier si tdk21 a un behavior dans le contenu. Limite réquest. On va vérifier quel cluster a été utilisé. Est-ce qu'il y a une corrélation de fail? Pour exemple, tous les failures sont sur le site digital d'avoir la mémoire ou internet. On vise des tests de la mémoire. Si c'est un test de la mémoire, on va vérifier si le test est adaptaudié par l'arts. On s'en va vérifier si la mémoire est dudée par l'arts. Les tests de la mémoire sont minibles au point 1 ou l'autre cluster. Merci d'avoir dit ça. Et aussi, essayez d'aller sur un agent VM plutôt qu'un contenu pour voir si ça disparaît. Parce que les machines virtuels ont beaucoup plus de mémoire. Oui, mais si ça marche sur un machine virtuel, ça veut dire qu'il y a quelque chose qu'il n'y a pas de mémoire à l'allocation avec le contenu. Si ça ne disparaît pas, il y a un problème avec la mémoire. Oui, mais vous ne savez pas si vous n'avez pas la même machine virtuel. Donc, vous pouvez pinpointer le GDK21 ou la configuration Mavon à spinning up les processus Java. Mais là, on ne sait pas, peut-être que c'est seulement le contenu. C'est vrai, je peux pinpointer le problème. Ok, donc ce n'est pas un bloc C'est vrai, c'est vrai. Est-ce que c'est correct, Marc? Oui. Ce n'est pas un bloc. Je crois qu'on a découvert toutes les nouvelles soucis. Nous avons des nouvelles choses ici, DNS, G-Center. Oui, tout est découvert sur mon côté. Vous avez d'autres... La removal de la plug-in ne sera pas plus facile que vous pensez. Nous avons un message de Mavon. Et il y a une dépendance avec l'ancien plug-in. Ok. Vraiment? Je pensais que je n'avais pas de trouble de retirer ça. Je ne sais pas où vous voyez un message dans l'une des réquestes. Oui. Nous devons avoir le cobertura aussi. Donc, c'est une bonne chose. Nous avons besoin d'un cobertura d'infoscié. Non, je ne sais pas pourquoi nous avons un cobertura. J'ai déjà vu un intro pour la week-end et j'ai vu ça après. Donc, si on a un cobertura, nous verrons le fail. Et j'ai la même question pour la release CI. Nous avons besoin d'un code coverage API. Je pense que c'est un certain set de plug-ins. Et le coverage est le moderne moderne. J'aime ça un peu. J'ai été, comme un développeur Java, vraiment heureux avec cette chose particulière. Sur un changement récent, j'ai fait le corps de Jenkins. C'est un peu important que cette facilité soit disponible. Le cobertura fait un bon travail dans Jenkins. C'est vraiment cool. Ok. Mais maintenant, nous avons besoin de release CI? Oui. Pour moi, on a besoin de CI.Jenkins.IO. On a besoin de ça. En CI, il n'y a pas de problème. C'est drôle, parce que dans CI, j'ai pas vu que c'était installé après restart. Je pense que c'est pas installé. Cobertura? Je ne pense pas. Je ne sais pas pourquoi. C'est pas. C'est pas sur CI.Jenkins.IO. Ok. C'est pourquoi ça marche bien. Ok, on va retirer Cobertura depuis que je ne vois pas pourquoi on a besoin de ça. Oui. Et Uli Hoffner, régulièrement, a demandé cette question. Il note que les autres plugins sont déjà offerts, les features que Cobertura a offert, et ils ont fait un bon travail. Warnings NG maintenant gère Cobertura très bien. Donc, si c'est ok pour tout le monde, let's remove Cobertura as part of this pull request. Stefan, you are allowed to push on my pull request, of course. I'm sorry, I did merge already your pull request on the other. So you can open a second. Is that ok for you? And I will take care of reporting on the main issue. Is that ok? So we share the burden. Cool. And then we'll see as pointed out by Alex. Once we will deploy the new images without Cobertura and with the new coverage plugin instead of code coverage. We will see if we still have the code coverage plugin installed. So we might need to do manual operation. Is that ok for you? Yes. While we're talking about this coverage item on ci.jankens.io there is old data from the previous coverage plugin that is being discarded if I press the discard old data button. So manage old data. I see no reason for us to keep that old data. It probably would have been better if there was... So I've clicked the discard un readable data button. It's going to take a while because there's a lot of it. Yep. Thanks Mark. Ok, I don't have any other actions. Is there something else you want to mention or discuss? Ok, no. So then let's get back to our normal walking day. Hope everyone is doing ok. See you next week. I'm stopping recording of my screen. Bye bye.