 Hi, everybody, welcome for this new Jenkins infrastructure meeting. We don't have, I mean, we have a few things to the agenda, but I'm not sure if we already covered them in the previous meeting. So I just want to review the different point to be sure that they are covered. I saw that the first point is Jenkins as a service. I don't know who put that note there, but I don't have any information regarding that. Jenkins as a service. Okay. Let's just put this here. Regarding the GitHub on Seattle Jenkins, I saw that you did a bunch of work there. Do we have anything missing there? I think a leg did pretty much everything. So for the GitHub, GitHub app on Seattle Jenkins. Yeah, so get GitHub app authentication is enabled has plugins been enabled now. I know that's one that. I installed a GitHub check API, but we have to restart Seattle Jenkins. Tim, are you there because you freeze. Yeah, no, it's working. So we're just saying, so I installed a GitHub API check. But we have to restart Seattle Jenkins. So I guess. Just hold off a little bit on restarting. Yeah, because there is a lot of activity at the moment since here. Yeah. The bug in the checks API plugin that's just getting fixed. Just hold off. Okay. Okay. But then, then, yeah, because I already installed a plugin. When it's available and so I update the version then restart the instance. Because right now it's not enabled because it has dependencies on other plugin version that needs to take them into account. We have to restart Seattle Jenkins.io. So, yeah, but anyway, I see that there is a lot of testing at the moment on Seattle Jenkins.io. So it's definitely, it's probably not the best time to restart it. Yeah, I'll panic if we get done. We are rebuilding every acceptance test artist PR. Yeah, I merged three p.m. this morning. Yeah, it's crazy. So, Tim, I did see and I was quite impressed the, the table to divs transition is taking into account acceptance test harness. So you're confirming that it works. Yeah, Felix ran them all and he reported a bunch of issues. And it's picked up one bug in core and the pull request and one bug in the promotion plugin. The rest of them just been annoying CSS selectors. And, and fixes that have been tested and broken for ages. Some plugins have been broken for like last, sorry, some tests have been broken like last 15, 16 versions in the CSS framework. So Olivier in terms of the load on Seattle Jenkins.io, yeah, it's got over a hundred in the queue right now. So it's, it's triggering our, our warning on and ATH is the big one. Yeah. Given given the funding that AWS has provided, could we afford to increase the number of maximum high memory that we could run from three to say four or five. Because we are, we still have plenty of data that you can use on them as an accompaniment. So yeah, feel free to do it. Okay, we have, we have, we have the budget basically. We can probably also cancel the test ones too. Yeah, that's what I'm thinking. Sorry cancel which which Tim. Yes, PRs. Oh, okay, good. So you, you don't see a lot of loss if I go in and actively cancel some of those acceptance test harness PRs. No, I would just, I would just console them if, if, if there is really one that needs to be a retrigger, we can see manually trigger that job manually. So, and I can, I can check iteratively to see, has there been any change in the PR or is this just a rebuild because there was a change merged to the master branch. I think it would be better than increasing the VM size, but the number of them. I will do that investigation. Thanks. Just wait. Okay, so none of them have had a current, a recent change you've already done the look. Great. Okay, then I'm going to just interrupt them. Thank you. I remember that I put the LTS release in the weekly release. So far, we don't have anything new there. I merged the PR this morning regarding adding information for GPG key for a day began and read ads. It's working for that, but it's not for a day began. It sounds like there is we are trying to read. It sounds like there is something wrong the path where we read the GP GPG key. It should be easily fixed. But yeah, we just have to look at the scripts at the moment, but it does not affect future release. We still have green green builder. Regarding the automated release, we still have to work that need to happen in order to close the epic. That's what I was looking for. So one minor thing is to align. So right now, when we do an LTS release on security release, we freeze the codes on the Jenkins CI slash release repository. But on the Jenkins CI slash packaging, we are still using the branch in fraud dash 910 something like that. And we should merge that branch on the master branch and then start to freeze again the branch when we do an LTS release. So we should add to the process to create a bunch each time we need to create an LTS release. So it's, it's minor thing, but I think we should just fetch, I mean ensure that we can merge, we can safely merge the branch 900 and then to the master branch Jenkins CI packaging. So it's basically the tickets in fraud dash 2660 and in fraud 1363. So I put the link in the doc. So, so tell me about the changes that will or tell us about the changes that will occur as infer 910s branch merges to master. Does that change the job definitions on release.ci.jankins.io or is it So there is a variable on release the on Jenkins and fraud slash release where we specifically says get check out that get repository on that branch. Right now it's just in the parameters and we just know instead of using that we have to use a master branch but before doing that we have to be sure that the master branch is a line on in front 900. So the reason why we haven't merged that PR until now is because because you care was using the master branch or these release environments, and we did not want to affect this process. So now that we're releasing everything from the new environment. It's just makes sense to to update the master branch. Now, and in terms of timing we've got an upcoming LTS release next week. Do we do the infer 910 to master merge before that or wait till after the LTS. Personally, I would I would just wait great because I like that I would I would just wait because I don't have a lot of time here and I cannot promise my time for the moments and the thing is, while I do not expect anything that I mean I'm not expecting there. I just don't want to take the risk to have whatever happens. So I will not I will not close it yet for now. I'm not planning to work on it but I would just update it to be sure that we are aware of what we need to do there. And the second thing. So before 2660 is about free freezing, updating the master branch on Jenkins. Packaging. And the other tickets is about promoting packages. The second job is the second task that need to be finished in order to close this epic. And this one is about and the same I will not so I have open PRs I will not merge my period because I don't want to take the risk to break the current release process. And the third thing that I want to get is about promoting red dots use and the end packages. So the idea is to put them in a staging directory and only deploy them on the horse at the end of the process. So right now we have staging promotion first promotion from staging to their prediction for the package that Jenkins that I website, we don't have promotion mechanism for the horse. And then we stage the packages and then we stage the website and then we promote the websites. And so this means that, yes, it was a little bit challenging for the red dots because red dots, we generate the websites on on the machine on the fire and the production machine. And we need. We need, sorry, we need to read the package, the list of packages from the prediction so we don't have this. I mean, we have to specify one directory where all the packages are located. And so having to fetch the list of packages from two locations the staging and the prediction environments. It's a little bit more complicated. And so it implies a little bit more cleaning it's on so that's mainly because of red dots and Zeus packages, but I haven't been able to match my peers, but it should be it should be really now. And, um, yep, I think it's team who puts a link to the Jenkins slash Tucker. So yeah, I'm just moving to the next point. Tim, have you are you the person of which I can see a slasher link. Next meeting. Potentially, but yes, I didn't want to mention it. Okay. I don't remember adding it there maybe it's from the last one. But yeah, is there anything blocking the plug installation manager tool getting added to the top one just now. I don't have anything from my point of view, but maybe I like maybe Alex and like have some concern. Well, so it's currently implemented as a prototype right or is preview. And so it's not overriding the default. No, it's, yeah, it's preview it's not a prototype it's production ready and beta than they still plugins really. And it's previous for a little bit. Originally I had it in there as the third way and left install plugins is the backup way. I could give it a last review but I don't think there's anything blacker from me, but maybe Alex has some. Yeah, I'll do one more review on it but it looked fine to me, but I'll do one more review and my approval and perfect. And so there's just one last thing because in the, in the table at the top of the documents we have much. We have one prioritized to pick Jenkins and flash slash merge policy. I don't remember anything like about that, but it was probably me, but I don't know if you have any concern. I'm going to text about that. I think you can just delete this but in the prioritized topics. So we still have the info nine nine hundred ten. The second point is Jenkins infrastructure slash charts merge policy. That's done. Okay. Yeah, we can we can close this one. And to discuss the peak we had the agent labeling and Seattle Jenkins radio. I think it's done as well. So I think we can close its mark to you. Yeah, I definitely documented the agent labeling policy. Yeah, so I tried to document the current practice. Yeah, perfect. So I think we are good for today. So do you have any topic that you want to bring here. I guess if we don't have should we should we highlight that we've started a proposal a draft proposal for the Jira upgrade process. Yes, you can highlight that and it would be nice as well to share the document with people here. Yeah, that would be great. Okay, so. Okay, if I share my screen or best if I don't what do you have a preference Olivier. Yeah, you can share your screen that's that's great. Okay, let's see if I can find that. Okay, so here's this. And the idea is that our Jira instance is running Jira seven dot 13 dot 12 hang on and I'll share this screen, which will be officially off support at on November 28 2020. So we need to get off that version onto a newer version of Jira. And one of the benefits of being part of the continuous delivery foundation is that we get some free services from the Linux foundation that is the host of CDF. And one of the things that they do is they support Jira instances for open source projects. So this draft plan is trying to identify crucial objectives and proposals for what we should do in order to make this transition by November 28. The FDA is going to let me lead this one. So I would be happy to give a request to others as reviewers for the proposed plan. Right now the crucial players are Andrew Grimberg Brian Warner and Steve era of the Linux foundation it team. I just started this draft yesterday but just be aware that this is an actively in progress thing so that we can get off Jira seven dot 13 dot 12 before November the November 28 2020 end of support date. And that's, that's really all I had are there questions from people about this about the idea of upgrading Jira and having it switch to be hosted by Linux foundation instead of us. So just to add thanks Mark, we just add a little bit here. The idea is we try to prepare that migration in advance. So the best scenario Linux foundation can upgrade a version for us and they do all the work here. The worst scenario, you have to create the Jira version by yourself before November and that's why we start working on this now. So we are still at the next one in exploratory mode. We don't know how to really work with it in explanation because we don't have a real process because obviously we don't have access to their We are working whatever so we I mean we are really at the beginning of this work right now. And we're thinking about moving to kick off. So is the identity stuff with Linux foundation still going on or is So, so, so it's, it's kind of related, but not I mean it's kind of related to the question right now is Are they okay to use our system management because we still have this is something that we have to discuss in the community when the community about what we do with the Jenkins identity management, but I have the feeling that it's going to be a little bit more complicated, not in terms of complexity about the Whatever, but more in terms of what we do about the data here. And yeah so the first thing is to first move Jira, if we can without modifying that identity management, and then discuss about how we do, and how we work with identity management. I don't want to, I don't want to work on key clock right now because it's not, it's not yet clear if it makes sense or not, but the discussion will probably happen while we discuss about Jira because we have to see how, I mean, if it's possible. I think it's good to get some clarity there because, like the current account management that here is very, like, it's very poor. The system of use is very well well and Tim I would think we will want a similar plan that does a identity management next steps plan right whether that's a transition to click key cloak, or a transition to Linux foundation identity or something else. Agreed, I was, I was just focusing on Jira for this exercise. But yeah, the thing is, we have to bring some clarity because even if I don't expect it to be a lot of work to officially switch to click look. Yeah, we just have to be sure that we don't waste our time on this stuff here. So, Tim, Tim and Alex, are you interested in being reviewers on this document is so I'm happy to share it with you. Okay, we'll do. Sure. I'll review anything. Careful, careful. And while we're talking about Jira, I'm just wondering if you both Alex and Tim, you would be interested to have SSH access to the machines, the perpetrator structure, because if you do, you just have to provide your SSH key and then we can plan some knowledge transfer about how to fix issues on those machines or how to improve or whatever. You just it's just a PR on the perpetrator basically that I have to merge. Yeah, I'll take a look. Okay. So I propose to finish the meeting here unless someone else has any other topic to bring. Otherwise we can just continue discussing in RSE, which is perfect. Great. Thanks. Thanks. Bye bye.