 Bonjour tout le monde, aujourd'hui nous sommes le 28 de juin 2022. Nous allons commencer avec l'infrastructure de Jenkins publique. Sur la table, nous avons votre serviteur diamond du portal, Ervelmer, Mark White, Stéphane Merle et Bruno Vardin. Bruno Vardin, merci tout le monde pour le management de l'année dernière. Nous allons commencer avec l'annoncement. La semaine passée très bien cette semaine. Le test est très complet, tout est bien. 2.357 est prêt. Nous avons déjà été dans l'image et c'est prêt à être déployé sur l'infrastructure. Vous avez d'autres annonces ? Non. Ok, cool. Nous allons maintenant passer à la tâche que nous avons fermée la semaine passée. 1.1.0. L'espionnerie des services Azure principale et pour l'access cluster et privé gates. L'espionnage a disparu, je n'ai faimé de nous rappeler la team la semaine dernière, parce que j'étais un immeuble, et je n'ai pas à l'appuyer mais nous avons un calendrier. Je l'ai rappelé par mon calendrier. La calendière est toujours une bonne idée pour les préd Его, Nous avons tourné la coopération, les trois de nous, Stéphane, Hervé et Hai, pour le fait de la séance décollée, tout a été bien. Les impacts étaient très détaillés sur l'issue, seulement sur l'infrasie, donc il n'y avait aucun impact public. Nous n'avons pas été dans une situation où l'usage était ou dans un état. Nous avons fait ça très rapidement. Il a été documenté. Nous avons mis des notes. Nous devrions utiliser un autre système d'identité d'identité et d'un principe de service qui aura le bénéfice de ne pas avoir besoin d'un secret pour roter régulièrement. Donc, juste pour tout le monde, nous allons utiliser l'identité d'un principe de service. C'est écrit sur le problème correct. Donc, ne t'inquiète pas si tu ne m'en souviens pas. Mais pour le sake de partager l'information. Une question ? Non. Le prochain. Un grand nombre d'entraîners s'est arrêté la semaine dernière. Nous avons eu un problème avec l'algorithme utilisé par le générateur d'entraîners. Donc, le travail est de lire tous les derniers plugins publiés et de essayer de générer l'index qu'il y a sur le file que tout le monde donnait lorsqu'on commence une instance de Jenkins, ou de checker pour nouveaux plugins. L'issue était sur le Java Code utilisé pour construire ce file qui est lié à la façon dont nous cachons les files. Donc, cette génération n'est qu'une seule à prendre quelques minutes, plutôt qu'une heure. Donc, il y a eu plusieurs exchanges. C'est maintenant fermé. L'impact était des utilisateurs durant la semaine à cause d'une bonne décision de mail. Donc, une bonne expérience collective. Ils n'étaient pas capables d'ajouter ou installer des plugins AWS parce que l'un des plugins a été ignoré parce que c'était le plugin qui a causé le file nommé Toulon Issue. Donc, comme une enseignante générale d'entraîners, la prochaine fois qu'on a un issue sur le Centre d'updates, c'est mieux de laisser le Centre d'updates être adapté pour quelques jours que d'essayer de retirer un plugin pour laisser l'autre plugin fixé. Ce sera le default pour aller. Quand vous êtes seul et que vous devez prendre la décision, s'il vous plait, laissez-le dans un state de fail. Lorsque le JSON file est sur le correct state à un moment donné en temps, et nous attendons quelques jours, nous pouvons toujours retourner et corrected-le. Exception pour les issues de sécurité, mais la team de sécurité sait comment s'occuper de cela. J'ai essayé de summariser cela. Est-ce que vous avez des questions ou que vous êtes unclear sur ce qui s'est passé? C'est fermé. C'est confirmé. Il y a été 28 heures sans erreur. Merci beaucoup, Daniel, pour l'aide. Marc, Helvet et Stéphane, pour l'aide à l'aide. Tout le monde m'a rappelé d'avoir un issue sur le Centre d'updates publiquement broussable de Github, qui m'a aidé d'avoir des informations et de suivre-up. Merci pour l'aide de Gira et Github. C'est définitivement un improvement collectif. Pour ajouter sur cet issue, j'ai aussi vu que Daniel a appris le progrès de remettre le limiter sur le nombre de plugins. Parce que, maintenant, nous n'avons pas de problèmes. C'est une bonne chose. Cela veut dire qu'on peut commencer à avoir beaucoup de plugins nommés avec des versions de l'aide. C'est une bonne chose. C'est une bonne feature. La prochaine question, une documentation migrée de Github pour les plugins de Nutanix-Calm. C'est un taux de maintenance de plugins, donc merci pour la personne qui a fait ça. Ce n'est pas vraiment l'infrastructure, mais c'est encore partie directement. Nous avons une notification, notre système LDAC est l'entreprise pour tout cet utilisateur. Je suis heureux de pouvoir fixer ça rapidement. L'update centrale n'est pas l'update. J'assume que c'est le même issue. Oh non, c'est celui précédent. 2 jours avant, j'ai mentionné un grand failure de file name pour longues en créant l'aide centrale. Il y avait un autre issue. Il y avait aussi d'informations qui étaient bloquées avec un file à l'intérieur de ce système cache. Un file était empty. Normalement, c'est un error de download. Nous avons un runbook avec un set de commandes pour mettre sur la machine d'agent SSH. Donc, ce procédure est vraiment facile. Vous connectez à la machine indiquée sur le runbook, qui est un lien privé, d'ailleurs. Vous copiez et passez la commande. Vous le runez. Et puis, même mieux, vous le runez sur un CI entré, pardon. C'est une commande grouvée exécutée sur l'agent. C'est vraiment utile. Vous le runez. Il a choisi les files qui ont été nettoyées. Vous le runz le build et ensuite, il va retourner à gris. Donc, si vous avez cet issue, maintenant, vérifiez le runbook avant, parce que la plupart du temps, Daniel a pris beaucoup de temps pour documenter ces éléments. Pas de question. Jenkins, donc, la dernière salle de Jenkins, la dernière semaine, lors de l'advisation de sécurité, qui, pendant 24 heures, suivant Mathomenos, suivant la release, a mis une preuve qu'il y avait une nouvelle version de Jenkins pendant que l'utilisateur l'avait déjà utilisé. Donc, ceci était un conséquence d'un issue sur le centre d'updates qui était fixé. Et puis, depuis que le centre d'updates n'était pas updating, nous n'avions pas pu publier à l'utilisateur. Ce changement a été fait par Daniel après la release. Donc, ça a pris quelques heures pour être disponibles pour tout le monde. Donc, merci beaucoup pour tout le monde qui a été invité en notifiant ce que c'était vraiment utile pour avoir une petite notification à la fin de la release. Nous avons pu fixer ça très rapidement. Donc, lTS a été publiée, la première release. Ça veut dire, qu'on a fait moins qu'un jour. Donc, c'est un bon travail et un bon travail pour l'automation. Build Failure Shavada ne peut pas produire localement. Je n'ai pas d'idée sur ce qu'il s'agit de. Si quelqu'un de vous le sait, sinon, on peut... Il n'y a pas d'idée de ce qu'il s'agit de. Et Bazil a donné des conseils pour fixer. Ok. Ok, merci, Peter. Il a ouvert la pensée qu'il pourrait avoir été en frais pendant que c'était une issue de configuration. Donc, c'est mieux d'avoir des issues ouvertes en pensant que c'est en frais. On peut toujours aider. Mais, oui, c'était merci, Bazil, pour résoudre ceci. Merci, Hervé, pour les souvenirs. Migrate from Workflow, CPS Global Lib to Pipeline GroovyLib. Donc, c'était un anoying warning sur Eugen Ginston parce que nous avons d'autres choses from one plugin to others. Why? I don't remember and it's not a problem. But we had to remove a plugin, install another and remove at least one dependency or ensure that one of these, the dependency of the Workflow CPS Global Lib was removed. So, thanks, Stefan and Hervé for managing that. That was quite the exercise for the three of us knowledge sharing because between the docker images and the manually managed instance on virtual machines that was not that easy. So, thanks for that work folks. We am not sure certain date. We see that later. Okay. Is there a reason why did we close this one then? We might have closed too quickly now. I don't remember but I will see this after. Okay. So, you take care of that one? Okay. Adding a note. Hervé checks for cert.ci with the security team. So, we have to check with them if they want to do the plugin changes or if they want us to do it. No problem but we have to check with them. Last task. Weekly's CI default view description diverge from the defined one. So, weekly CI is a public Jenkins instance hosted at weekly.ci Jenkins.io It has been created to show the latest design of material what we call the Jenkins design library and that requires to be using Jenkins weekly version. The only weekly version that we run is infrasci which is not public. So, it's a kind of public demonstrator. So, that demonstrator has a description on top here as you can see. And we discovered that's the way we were configuring it using Jenkins configuration as code was wasn't the correct version. So, changes were made on the infras code but not applied. So, it was not doing it was not behaving as expected. So, we had to understand that and fix it. It's now done and details in the issue. Any question on this task that were finished? Did we miss any closed task that you did that we forgot on that list? Nope. Okay. Work in progress Cannot upgrade Jenkins from 2, 3, 4, 8 using pkg Jenkins say that I totally missed that one but I answered. Hmm. Yeah. It's about an HTTP reduction. Can you zoom in, please? Yes, of course. Okay. So, someone is having an issue because they are using the Debian package repository in HTTP on the whole domain name Jenkins CI.org So, you assume it's a Jenkins that is quite old or at least that existed since years even if updated. They fix the issue by themselves. Okay. I remember now. We gave them information for anyone with the same error that will make here. That task is still open because that will be useful for us to add an HTTPS redirection from the old domain in HTTP and HTTPS to the new one that will be the redirection on the Apache server on that machine. So, any user using the old links will be automatically redirected to the new one. So, any user using the old links will be redirected to the new one without any problem because it's not the case today. Would that make sense for you folks? Yes. Okay. Is there someone okay for taking this one that will be poupette on the Apache? Yes please. Okay. Adding to the next milestone. Hop. Next work in progress. Claim that updates JenkinsIO certificate is sometimes expiring. So, it's an issue followed up by Mark. A user complains that sometimes you see word certificate or unexpected certificates with TLS invalid connection when checking updates JenkinsIO and get JenkinsIO. We also have a user that did something else word. What is hidden beyond that I try to show some elements we have to dig a bit more for get JenkinsIO as I wrote if the user does as an old HTTP client in HTTP 1.0 or an invalid one like those Magica blue code appliance in companies that provide security proxy. Most of the time they tend to use word behavior of HTTP and that remove the host header or set the host header to an invalid value or worse to remove it at all. HTTP server have to rely on SNI which is at the TCP level when any protocol of the application level try to open a standard TLS connection like HTTP or MySQL the first packages on TCP are un encrypted and provide a domain name as part of the first packet packets the goal is to have the first uncheck and then encrypt to the connection and then you can have whatever you want in that channel and that is in I since it's un encrypted it can be used to do the same thing as the virtual host routing so in the case of Apache and Genix 2.0 and other web server if they don't have an host header on the incoming request they check the SNI and then they try to determine the host name for the V host and then they can select and choose certificate otherwise they fall back to their default virtual host configuration to provide certificate so in the case of Gage and Kinsai on Kubernetes if there isn't any information to select one of the ingress rules which are basically V host then it fall back to the default and then it certificate so we might have an issue when the Apache server and the machine is not able to generate the initial uncheck and what we tend to see on sometimes we have error on updates Genkin CI the error that the second user and the line is still in the same area we have issues with the machine update Genkin CI sometimes it drop so right now no action for us to be done there trust me I've spent quite the amount of time this weekend to run some TCP dumps on the machine for another subject on the docker area the thing is we have an old version of Apache it's not and there are issue with old one so we needs to use a more recent version and that's one of the next issues migrating that machine to Oracle will have the benefit of solving these issues is there any question anything is unclear on that topic or someone that doesn't agree and we can absolutely discuss and take that in consideration so is it okay that we keep the issue open because for me the issues exist and I want to acknowledge it and I will need to add the comments that should be solved by the other ones March Do we have any tracking of the issue in any logs to make sure that with the new Apache the logs are disappearing you cannot see that on the logs because since this is the TCP uncheck failing Apache doesn't even know it has a connection because the kernel never tell him at the kernel level we don't have any logs no and that's a good thing otherwise the machine will spend its time absolutely however by TCP DOM you can see the issue open some packets are lost I propose that we link that issue to the Oracle Update Center so we remove that issue from the milestone we had a comment there explaining that so once we have migrated we can test again that issue and put it back on our priority list but right now it has to be kept open and there is no action item for us so I propose we remove it from milestones we will be able to ask people to check for us too to confirm that the problem is solved ok absolutely otherwise we can switch to NGINX that will solve the issue wonderful and the main is that you haven't done that yet but yeah next task is consider removing embeddable build status plugin that's the plugin that provide this tiny building or failing or passing icons images that's a request from security team because security a lot of security and the main part of the plugin is not able to work on it anymore so he helped to solve the latest security issue from the free past advisories however security team seems pretty frightened by that plugin so either someone jump up to maintain that plugin either we remove it so we removed almost all the controllers or unsure it wasn't installed except CIG and Kinsayo because we have last task it's sending an email to the mailing list telling the developer hey we are removing now that plugin from CIG and Kinsayo so you might see these images broken on your read me of your gen kids plugin you have to remove it that's all just to let them know as a courtesy Mark proposed to do pull request on the 163 location where it was used de l'histoire cout e cout cout cout cout centrifuge s s s s s s s s s s s s s s s s s s s s pour créer des requests. Je pense aussi qu'on devrait... On devrait aussi avoir une question sur la représentation de plug-in, puis un request pour ajouter une application notice ou une deactivation notice. Cool. Je n'ai pas compris. Est-ce que vous êtes intéressés, ou est-ce que vous pourrez suivre cette application? Non. Cool. Ou si quelqu'un d'autre n'est intéressé, bien sûr, vous pouvez le faire avec l'HRV. C'est juste que c'est intéressant, mais je n'ai pas le temps de me concentrer sur l'infra. Non, non, non. Honnêtement, j'aimerais que ça aurait été très utile pour moi durant les mois de passage. Donc, dès que quelqu'un de l'utilise est capable d'automater cette change, c'est vraiment important parce que quand nous faisons large-scale change sur l'infra, il faut être appliqué à des milliers de pipelines si on est capable d'automater cette change. Wow. Et aussi, Combi, qui est un outil pour faire du refactoring dans plusieurs langues. Et sa expression est plus facile qu'une saison, ou une expression C'est bon. C'est fait pour ça. Et ça pourrait être sympa. Donc, vous devez présenter le résultat pour nous. C'est un trap. Oui. Je vais faire une version crude comme Justin a fait, ce n'est pas ça crude, mais c'est notre improvement. La seule part mandatorie ici est de résoudre l'issue. C'est-à-dire, si vous pouvez ouvrir plus de requises, envoyez le notif et retirez les plugins. C'est tout qui est requiert. J'ai l'intérêt d'utiliser les sites, parce que, comme vous l'avez dit, j'ai l'intérêt d'entraîner les questions. Absolument. Absolument. Ce sera vraiment utile et sympa. C'est juste pour mettre la barrière. Vous décidez le nombre de temps, mais ce que l'on expecte de l'infra-parote, c'est de remettre les plugins et de l'intérêt de l'infra-parote. Cool. Enable développement de l'intégration en Gira. C'est ce que l'on a posé. Je vais retourner sur celui-là. Ça pourrait être un peu pire, et nous avons besoin d'autres tokens de l'admins de Genkin CI. Le but c'est d'intégrer la Gira de l'intégration avec le Kitabishu. Gira est capable de mentionner l'intérêt de l'infra-parote. Nous ne pouvons pas utiliser, comme l'on a dit il y a deux semaines, que nous devons utiliser un Kitab app. Ce n'est pas possible avec la version et la configuration qu'on a. Nous devons créer un utilisateur technique sur les parts de Genkin CI qui aura des droits. J'espère que pas trop d'administration. Ce utilisateur va avoir la même permission d'administrer le Kitabishu. Je ne pense pas que nous devons faire ça pour Genkin CI, mais ça peut arriver parce qu'il y a des nécessaires pour synchroniser le but de différents trackers. J'espère que non, mais nous devons. Nous devons double-checker si quelqu'un veut prendre le Kitabishu. Est-ce que c'est bon ? Oui, c'est bon. Je garde les deux et on verra le premier pour finir son travail. Évaluate la condition pour improving la stabilité de la build. C'est un plugin expérimental. Nous devons faire ça la semaine dernière, mais entre la sécurité et l'adviserie, l'overload de tous les équipes et l'issue de l'administration, nous n'avons pas pu faire ça. Nous devons installer des plugins qui ne sont pas la plus stable version, mais c'est un plugin expérimental de la build, d'exemple de pull request. Le but est d'être capable d'avoir une build restartée quand l'agent s'occupe d'une raison inexpectante. C'est un travail de Jesse Glick et nous devons essayer de le faire sur CI Genkin. Je garde les deux parce que maintenant, tout le monde a joué avec le plugin CI Genkin SAIO avec la removal. Donc, quelqu'un devrait pouvoir essayer ce plugin. Par défaut, j'ai gardé mon assemblage parce que j'ai commencé à parler avec Jesse, mais n'importe qui s'intéresse, il peut s'occuper. Je garde les deux. Répliquez l'agent CPUZ. Je vois qu'il est connecté à CI Genkin SAIO. C'est managé par Mark, j'assume que c'est fait. Il n'y a pas de problème. Il n'y a pas de problème pour nous. CI Genkin SAIO s'occupe d'un power shell sur l'image de Windows docker utilisé par ACI. Donc, c'est... Oui. ... ... ... ... ... C'est certain ...jeong... Je vaisовать ... dere. Provprise... ... ...nee. Ok, parce que mon target est ACI, comme ça. Oui. On peut seulement ouvrir le l' turret dans la photo de Windows. La méchance ordinate de l'image est curelle. C'est l'aliment là. Oui, c'est correct. Laissez-moi fixer ceci pour le futur. C'était... Qu'est-ce que vous pensez... pour tous les agents qu'on a ? On n'a pas besoin de vérifier si boheur shadow PWSH est présent sur les agents. Je ne serai pas sûr que c'est toujours présent. Ok, prenez les boheurs shadow PWSH sur tous les templates d'agent. Ça vous semble bien. Ça vous inclut votre travail sur la machine virtuelle et d'autres types. Vous avez été assigné et presque là. Laissez-nous continuer, si je n'ai perdu quelque chose. C'est bien. Dockers abe rate limiting. Il n'y a pas de news d'Ockers. Je dois envoyer l'email. Je ne sais pas. On a ajouté des rates limiting quand on construit l'image Dockers d'Officiel Jenkins. On a fait des actions. Je vais avoir besoin d'une configuration de templates parce qu'on utilise public IP pour toutes les machines virtuelles sur CIG and Jenkins. Je vais essayer de retirer les instances de memory qui n'ont pas été utilisées pour Dockers, même s'il n'y a pas d'Ockers. Ça nous permet d'abandonner plus de machines parce qu'on a un limiter hard sur Azure que nous ne pouvons pas produire de 50, de la région, ou de la grêne. Et encore, nous avons besoin d'Ockers pour répondre à nous, oui ou non, alors que nous pouvons décider de la stratégie. J'ai mentionné l'idée d'utiliser des images GHCR qui pourraient nous requérir, pour nous, d'un moment, l'image d'Ockers d'Officiel Jenkins à des images GHCR qui pourraient avoir des rates limités, mais une fois à un moment, ça devrait être bien. Et puis, nous pouvons faire l'amount de billes qu'on veut. Nous pouvons avoir une solution proxie, mais nous avons besoin d'une réponse pour décider la prochaine course. C'est bien, tout le monde? Si la prochaine semaine, si nous n'avons pas encore une réponse de Dockers, nous commençons à décider de ne pas utiliser le Dockers Hub et de sélectionner une autre solution, de changer l'enregistrement ou de mettre un proxie devant celui-là. Donc, la prochaine semaine, nous commençons à prendre une autre décision. C'est bien pour vous? Upgrade à Kubernetes 1.22, donc, Digital Ocean et Amazon sont bien. Je n'ai plus fini de prendre le change log, le change log, rien de particulier pour maintenant. Stéphane a déjà ouvert l'enregistrement et nous allons commencer l'upgrade sur le Dockers Hub. C'est bien, c'est bien, c'est bien, c'est bien. On va commencer l'upgrade sur la semaine matin à environ 9h00, 10h00, CEST. C'est bien. C'est bien. On va être le 31, est-ce correct? 30. Merci. Merci, les gens. Bon travail. C'est presque là. Digital Ocean, SponsorChip, rentre de crédit sur le cluster. Pourquoi est-ce encore ouvert? J'ai oublié d'encloser celui-là. On peut encloser celui-là. Je pense. Ok, je vais encloser. Je vais encloser dans la note de la meeting. Merci, Survey, pour ajouter le cluster de Digital Ocean avec les nouveaux crédits que nous avons ajouté depuis la semaine dernière. Il est utilisé, ou il devrait être utilisé par CIG & Kinsayo. Mais il n'y a pas d'opération en arrêtant le cluster. Vous avez regardé la prochaine étape avec Digital Ocean en termes de SponsorChip pour développer la SponsorChip. C'est-à-dire à peu près de la même rate d'utiliser Kubernetes, mais aussi d'être capable d'appuyer un mirage ou deux dans l'Asie. Et éventuellement, on commence à choisir l'image packer et la machine virtual pour l'agence Linux, les ones Intel. Docker et les builds que l'on utilise sur différentes machines. Qu'est-ce qu'il y a? La dernière, oh, pardon, allez-y. Ok. La dernière, Migrate Updates de CIG & Kinsayo pour un autre cloud pour résoudre ces issues de TCP, des issues de certificat, des issues de alerte et donner de meilleures expériences et de plus d'index de download pour les end-users. Donc, j'ai pris tout le temps ce tasque de Stéphane qui s'occupe d'un upgrade de Kubernetes avec Hervé. Alors, Stéphane a déjà fait beaucoup de travail sur le management de Terraform. Il a été able de dégager les works de Oracle Cloud. Donc, un grand travail là-bas. J'ai pris les parts de IAM. Donc, comment nous séparons la production et la staging sur Oracle Cloud. Parce que la façon qu'on utilise sur Oracle Cloud maintenant est que tous les utilisateurs ont un problème pour les changes automatique de Terraform. On ne veut pas les tests Terraform en essayant de manipuler les ressources dans la production. Donc, j'ai currently perdu mon air comme Stéphane a perdu l'année dernière. Comment nous avons la permission entre services Cloud et des groupes etc. Mais on est presque là. Merci à Stéphane et vous avez pu faire cela. Merci à Stéphane pour les services et pour l'essence de la production sur Oracle Cloud. Donc, je suis très content de vous pearler un nouveau code en en en en en en en en en Request from Adrien Le Charpentier, he's a cloud-based employees and he's above all a mentor of GSOC project about plug-in health. The goal is to have an health indicator based on some attributes for each plug-in. It's an experimental project as part of the Google Summer of Code, the GSOC. They ask for us to help to be able to build and test the application for now, no deployment involved. Adrien nous a donné des détails sur ce qu'il expect, ce qu'il a besoin. Donc, nous devons lui répondre par poursuivre son documentation et l'exemple d'un pipeline. Il faut savoir quelles capacités et agents peut-il utiliser dans CI Genkin-Sayo. Il a préparé un pipeline et il a mis le agent à l'utilisation. Absolument. Donc, le but est de lui pointer la documentation et lui donner des ints sur ce que vous voulez utiliser Docker-Linux-MD64. C'est le summary. Nous avons initialement discuté avec Stéphane sur ce point, mais selon le workload, oui, quand nous étions tous ensemble en Brassel. Mais ce n'est pas une expectation. Donc, je suis en train de challenger cet élément maintenant. Est-ce que vous voulez encore ce que vous voulez ou que vous n'avez pas envie de faire et que vous avez été connu avec? Je n'ai pas besoin. Je n'ai pas besoin d'être rude pour Adrien. Je n'ai pas besoin d'être rude, mais je suis désolé. Je n'ai pas besoin d'être rude. Le but est d'améliorer le task. Le but n'est pas pour Stéphane d'améliorer le task personnellement. Si vous ne pouvez pas, n'avez pas de problème. D'accord, vous ne pouvez pas, alors que l'autre ne peut pas et qu'il peut s'en prendre. Je ne peux pas. Est-ce que c'est bon si je le prends ou vous voulez en exchange avec Adrien? Je vais en exchange avec lui pour le déployement. Ok, Bruno Light, non, pas sûr. Bruno, vous voulez en changer? Non. Merci. En plus, vous voulez être supprimé après la fin de la GSTAR. Pourquoi pas? Pas de problème. La prochaine est le requiert de Java 11, l'infrastructure Fred. En fait, ce task a été créé par Basil. Nous avons déjà commencé à marcher. Le but est juste d'adder sur le milestones pour le traiter. C'est à tout le travail requiert de l'infrastructure code, repositories, communication sur le requiert de Java 11. La raison pour laquelle je m'ai mentionné c'est parce que nous avons déjà utilisé Java 11 tout à l'heure par défaut pour marcher les Jenkins. Et nous avons commencé avec un bon succès 3 semaines auparavant, si vous le souvenez, lors de la Silicon, nous essayons de forcer GDK 11 pour compiler les Jenkins. Ce n'est pas très bien. Maintenant, c'est le cas avec la week-end qui a été publiée aujourd'hui et qui sera forcée pour l'arrivée, si je n'y vais pas. Mais cette week-end ou la prochaine week-end, ce sera la première version de Jenkins qui ne soutient pas GDK 8 anymore. C'est plané pour la ligne de septembre LTS. C'est à dire que jusqu'à septembre, nous devrions encore avoir besoin d'avoir GDK 8 sur l'infrastructure. Mais cela signifie que ce sera un problème long jusqu'à la fin de l'année parce que nous devrions retirer GDK 8 de tous nos assets dans le futur. C'est pourquoi j'ai voulu être partie du milestone pour materieliser le fait qu'il a été travaillé pas toujours par l'infrastructure mais toujours. Le team Basile et l'Eye travaillent sur cela mais cela servait comme source de vérité. Surtout parce que le grand travail que Basil a fait sur ce port est vraiment utile pour nous et pour nous. Mais on ne peut pas être en train de faire une volcanoesque de l'avenir. Si vous êtes intéressés, n'hésitez pas. N'hésitez pas si vous ne vous en faites pas. Ce n'est pas un problème mais c'est un travail travaillé. Alors, nous devrions travailler sur cela. Et je personne ne le spent parfois, parfois sur celui-là. Et la raison pourquoi je l'ai mentionné c'est parce que depuis GDK le prochain sera 17. Je propose que, en la semaine d'arrivée, Je vais essayer d'aller dans FRACI, depuis que c'est une machine de l'âge, en utilisant GDK17. Il y a plusieurs raisons pour cela. Le plus important pour nous, c'est qu'avec l'upcoming Kubernetes upgrade 1.22, que vous allez faire sur la semaine, les machines de l'underlayant vont utiliser la version C-groups 2, qui signifie la façon dont les souvenirs et les notes sont différents. Et GDK11 n'a pas eu les portes à l'arrivée pour qu'elle soit correctement installée. Donc c'est comme de retourner sur GDK8 avant les management de C-groups. En utilisant GDK17, ça va nous aider. C'est une bonne excuse pour nous pour assurer que nous essayons de commencer à utiliser GDK17 en production. Nous avons besoin de la première évaluation des notes basales sur ce qu'est l'issue non-issue aujourd'hui. Mais dès que nous pouvons avoir plus d'instances en production, plus de feedbacks et des reportages de bug que nous pouvons faire pour le développement. Donc ne soyez pas surpris que quelqu'un d'intéressant n'a pas le droit de prendre l'issue, mais pas de l'intérêt. Mais en passant, ceci, en main partie de notre travail, nous allons préparer le fil pour le GDK17. Je l'ai mentionné, ce n'est pas un mandatarié pour le prendre. C'est bien de l'avoir. Managé la version de l'élastique Kubernetes cluster, donc la cluster Kubernetes managée sur AWS qui a été upgradée d'hier par UFolks. Le but est maintenant de pouvoir managé la version des modules installés. Les modules sont des plugins pour managé les réseaux et les DNS dans la cluster, principalement. Nous avons trois modules. Ces modules sont installés quand vous créez un nouveau cluster. Et nous avons ajouté durant les deux dernières années des upgrades de Kubernetes pour updater ce module manuellement dans l'UIE. Il semble que la configuration de rAuteraform est capable d'attaquer la présence ou pas de ces modules. Et c'est mentionné comme un warning, mais pas comme un item actionnel, que la version n'a changé parce que des updates manuels. Cela signifie que si nous trouvons une source de vérité, où sont les dernières versions des plugins dépendant de la version de Kubernetes que nous avons râlée? Il y a une grande matrice sur la documentation AWS, en tout cas, si nous pouvons trouver un moyen pour obtenir ce numéro de version, cela signifie qu'on va pouvoir updater ceci comme part du upgrade de Kubernetes dans le futur. Les codes FULAS et les auditeurs. Je pense que vous l'avez reporté. Ah, oui. OK, vous êtes assis. D'accord, parfait. Merci, Stéphane, pour l'opinion de cette issue. Et les deux main-tasques sont pour créer un nouveau cluster privé basé sur 10 privés qui sera remplacé 10 privés sans services crédentaux. Donc, il n'y a pas plus d'identité avec un secret de l'expérience. Et quand on a créé nous pouvons commencer à migrer le CI et d'autres dans cet environnement privé. La prochaine main-tasque après l'updater de migrer ceci et finir le cleanup de Mirrore Brains pour Poupette cleanup qui pourrait impacter les releases de l'opinion. Donc, c'est mieux de faire ça en juillet quand nous allons avoir moins d'activité. Vous avez d'autres nouveaux soucis importants que vous voulez travailler sur? Beaucoup de services pour l'exporteur issue qui me permet d'éviter le nom de l'opinion de copiement des images. Il y a un request de drap ouvert. Donc, même si ce n'est pas ce n'est pas en train de marcher sur ma machine pour le premier essai, mais quand même, vous pouvez copier et passer. Donc, on s'assume que c'est un improvement collectif. Donc, beaucoup de merci pour ceci. J'espère que vous pourrez l'utiliser la prochaine fois. Beaucoup de merci pour ça. Et de nouveau, merci pour votre travail. OK, c'est tout pour moi. Vous avez d'autres soucis que vous voulez faire? C'est très bon. OK. Donc, à la prochaine semaine, je vais maintenant arrêter la chanson, arrêter la chanson.