 Welcome to the Jenkins Essentials Open Planning Meeting. One of our colleagues, Baptiste, is on a much-needed vacation, I think. So I think Mandy and I are just going to be the only ones here, so this should be fairly quick. So Mandy, do you mind if I sort of just talk about our progress first before we jump into some of this other stuff? Go for it. So I'm very pleased to report that the perfection evergreen backup, or backend, excuse me, is online and is functional. So I qualified some of the work yesterday to make sure that the database was correct and that updates were being delivered to new clients and things like that. But this is a big, I'd say, very important step to getting actual users to adopt and use Jenkins Essentials, which I'm very excited about. So there's some outstanding work that I still need to get into Jira to get us to where we can close out milestone one from, say, from a production readiness standpoint. And a lot of that, and I'll just get into some of my tickets, a lot of that comes down to automatically generating this, not ingest.vml, that was a typo, but automatically generating the ingest content that the evergreen backend expects. So for Mandy, I don't know if you've spent much time looking at this, but I'll just go ahead and talk through it anyways. Where are we? We're in services. Okay, so the way that we are generating the actual update levels, as described in JEP 307, I believe, is we have this essentials.yaml file, which is expected to be, say, developer curated. And this is where we'll be listing out the actual plugins that we expect to be included in this evergreen distribution that is being pushed out to clients. In between that essentials.yaml and the backends, there's another file called ingest.json, which is machine readable and machine generated, which contains all of those essential plugins and their dependencies. And that's very important to make sure that the instance will actually boot, but this file and the contents of this file are pretty much uploaded verbatim into this evergreen backend service layer, and that's what actually represents an update level. And so what we're missing right now, and this is some work that I have scoped for myself here in milestone one, is to actually wire up the backend automation from an infrastructure standpoint to where when we receive a new change on that essentials.yaml file, we're creating a pull request with a new ingest.json, and that when we have that new ingest.json merge, that gets automatically pushed to the evergreen backend system. And that'll just allow developers, whether it's you and I, Mandy, or Jesse, or Oleg, or anybody else in the project effectively, to propose updates to the plugins that are included in the essential distribution of plugins. Does that make sense? Does that explanation capture this well enough? I think so. Okay. I've realized over the past couple of weeks that I haven't enumerated exactly how that part of this fits together. So that's the work that I need to do this week. There's also a bug that I need to file this morning that I found where our socket IO clients appear to be timing out and not reconnecting. That's going to require more tracing information than we currently have to debug. But I'm going to put as much information in that as possible, and then I may pass that off to you, Mandy, or I may take a look at myself depending on how your work is going. I'm not sure yet. That's about it from my side. And I know when Batiz comes back, he's got a lot more to do on the client and AWS side so that we can actually get to the point to where on Jenkins IO slash download, we have a... We will be able to have a cloud formation launch stack button similar to how we have this deployed Azure button, which will actually launch Jenkins Essentials on AWS with the right configuration. So when he comes back from vacation, I'm hoping that Batiz can close some of those tasks out. Yeah, and so I guess, Mandy, let's just talk a little bit about where your work is. Well, my focus has been on getting the flavor in so that when a client registers, it will store the flavor, and that way all the packages are getting the correct flavor for the updates. I've got the changes in for the server side. I just need to troubleshoot some finer details with that. And then I've started on the changes for the client. The only thing I haven't figured out for the client is how to get the actual flavor value into the object that we're creating, because I think those are Docker containers right on the client side. That's the only part, because I haven't dealt with the client side a whole lot. They are being built as Docker containers. What I don't know if Batiz had actually implemented, and this should be worked to check, is if he implemented an environment variable that would be defined for these things. Actually, what I've been looking at is, in the Docker file, having it push in basically the value of the directory that we're building from, because each one has its own custom Docker file, and we know the directory name. I've already started on the path of injecting that variable into the container, and now I just need to get the actual client code to read that variable and pass it along when it calls the status create. But we've got some time set up later today to do a pairing session. I think we should be able to, assuming we can figure out the debugging problem that you've had challenges with from the client side and getting those tests to pass, I think we should be able to get that wrapped up. This, it sounds like it. It sounds like you're so close. I know. I'm like, I'm so close. It's just environment issues that I'm fighting right now. Yeah. And so for background, to anybody who watches this later, Batiste and I have been doing our work primarily on Linux, and the Evergreen repository is heavily using Docker for all of its build pooling. And Mandy is on a Mac and using Docker for Mac, and I believe we're hitting some of the slight incompatibility issues between Docker for Mac and native Docker on Linux. There's definitely some major differences in the way Docker for Mac is working. And the behavior is not consistent with what you would expect. How fun. Okay. So yeah, I figure we might be able to get wrapped up on the server side, some of the backend stuff. And then when Batiste comes back next week, if he can wrap up some of the AWS stuff, we might be in a position to where next week we can start soliciting more users to be exciting. That would be. I think before then, I'm going to probably drop the production database one more time because I've been doing, putting some debugging information in there. Messing with data on purpose. So before that happens, or before we start adopting more users, I'm probably just going to clear it out and we'll start from something pristine at that point. But yeah, it looks like we're very, very perilously close. So I'll, that's it. Mayne, do you have any other topics we should discuss, or are we going to make this real quick? Nothing else for me today. Okay. Okay. So the last item that I want to leave in your mind to think about, and when Batiste gets back, I want to talk with him about it more. I've been considering simply referring to this entire thing as evergreen. And part of the reason, so dropping the Essentials moniker. And part of the reason that I've been thinking of dropping it is, Jenkins Essentials is very confusing for a lot of people. And it makes people think it's an all-in-one bundle distribution that solves all your problems, which it is not exactly. But a lot of the, I would say the automatic nice things for users we had put down into Milestone 2, which we may or may not be able to get to in the near term. And I think evergreen more appropriately captures the automatic updating aspect of this and will help us solicit users that appreciate the automatic updating part without necessarily needing to implement all of the batteries included things. I think that's pretty reasonable. Think about what if we just call it evergreen. Which personally I kind of like. I like it. Yeah, we'll chat more about that with the T-String as back. And if he's cool with it, then I'll just go do a big old strings change. Yeah, it looks like we're ready to go. So, yeah, thanks for your time, Andy. Yeah, I look forward to next week when we have the full contingent back in action. All right.