 What's up? Hello. Do we have an agenda for today? I don't know. I am trying to think. I don't think I have anything. Do you, I guess just while we're here, do you think that we're gonna keep having a bunch of merge conflicts because of this tooling stuff or do you think that it'll end up settling down? The most disruptive one was the one that went in yesterday where basically every single API protocol reformatted and had major code movements. Going forward, I anticipate the changes will be very small. Like, we'll see maybe some small formatting changes here and there. I feel that maybe if we're playing around things like put a validation formatting for the possible future ones, I think people should just be more cognizant if they're making API changes at least in the next week or two, they should merge master before merge, before, you know, doing the final merge. Okay. Most of the time from now on we'll be in the B3 alcohol treatment B2, which is where we're going to put it. And one other question for me is, have we actually formalized the policy on like when are changes to B2 still allowed? Like what are the rules here, basically? I don't know that we've actually set that down or is that written down anywhere? I don't think we have done that. I feel we need to, basically once we cut B3 we need to have this discussion. I feel for a short period of time at least we're going to have to allow B2 because there's still people actively working on B2 who are sort of blindsided by B3 and they're not going to want to upgrade to B3 just because you know, B2, but we kind of wait until, you know, 11 months into the B2 deprecation cycle and say, hey, now we're going to freeze things. No, no, yeah. I mean, my year or something like that or a quarter or something like that. Right. Yeah, that's my feeling too, is that whether it's like three or six months or something, but we have to have a policy so that people know. My gut is that basically halfway through the cycle, we should freeze it. So if it's a 12 month cycle, we should basically tell people, you know, after six months, you know, if you want new features, like you must start moving to the new version. That's my personal feeling. Yeah, I think that's absolutely right. Yeah, how? I would lean for earlier because we can always relax it. And then also again, like we've had problems before where people don't move early enough and then find problems. And so if we wait six months, I suspect there's going to be a bunch of stuff that people, like if there's behavioral changes. And I think like I'm financing six months for the first cycle, we'll see how it goes. But like a bunch of big things like the web socket change or something. Like if we have someone do a drive-by big feature and then they wander off, right? They're more likely to run in three months than sex is my only thought. Yeah, that sounds reasonable. Yeah, I don't like, I think we can try whatever. We may have to be flexible this first time. I think I'm just trying to balance. It's like we need to get people to move forward, but I also can realize to some people how incredibly irritating it would be. Like if we told them that, you know, they added one field that they want and now they have to move like everything over. I mean that, you know, so I just feel like giving them enough notice so that and having the policy clearly written down that we can reference it is pretty important. Yeah, I kind of feel like what we're going to do with the V3Work is show how we can reduce the toil by example on the on-boy side and folks who are then, let's say we can go control play and they're going to have to adopt the patterns that we've used, but not the code necessarily in on-boy to actually reduce the pain and moving forward through these major versions. Yeah, for what it's worth, I think six minutes totally makes sense this time around and then we'll see how it goes. I just don't want to codify that. That shall how it will always be. I think we're going to learn how it goes. Makes sense to me. Okay, so yeah, there was someone taking notes. Yeah, great. Cool. One other thing to point out is that we will probably, you should expect if you're on-boy user to see an email coming out soon about some pending release, no details right now, but it's, there will be a new point release coming in the next few weeks. Yeah, I was very pleased with that, so yeah, we'll do that. Yeah, yeah. All right. I can't think of anything else from my side. Anything else anyone wanted to chat about? Do you want to talk about relatable config status or do you want to stick that to email? I can go either way. Oh, I mean, as long as we're here, sure. Yeah, I saw your last comments on that. I think my question is, you're going to, this is not just for listeners. You're going to go and do the same thing for clusters and then we're going to have the same problem there, right, with the warming and the active clusters. Yeah, right, okay. I haven't seen the stress right about this. What's the- So essentially, again, what I want is something that's going to be generalizable and it's possible that I should do the one API change and then a bunch of coding changes. But essentially, for anything that's relatable, I would like to know, again, the last successful load for an instance of a thing and then if there were failed loads. So if they are named things, I would want to know that listener foo had a successful load five minutes ago and it had a failed load one minute ago, but if it's the first time I loaded foo, I do want to track the fact that like, we never successfully loaded foo for interval. Yeah, yeah. My preference though, which I expressed yesterday, I'm not sure how people feel, is that we should just reorganize how config dump works. So we should dump by resource, not by resource status essentially is what we do today. Yeah, so I haven't had a chance to type into the GitHub issue, but that was going to be my suggestion also, is to essentially move it over where now it's just a map of basically name to a thing. And in there, I think we can structure it so that if it's active, like here's the active config and like here's when it was last loaded. Like if there's a failure, there could be like a failure section with the config that failed to load. And then if it's warming or draining, you could optionally have what the warming or the draining config was, does that work? Like I think that would be flexible and then that would work for clusters also. Yeah. So basically what we're saying is we want functional name to... Thing. One of the lists that we have now, where the list that we may have now may be three things, let's say worst case, the warming, active and draining. And then... Yeah, so it's like, I think the common case, so let's just talk common case for a second. We're like, everything is running for both clusters and listeners. The way that I'm envisioning it as an operator is that I have a name of the cluster or the listener that goes to an object. The object basically contains the config, the running status, the last load time, like all of the things that you had said. In the case that there was a failure since last load, you would have like an optional part of that object which is like last failure. And then if it was draining or something else, you could even have, and then an optional section of draining config, drained at time, draining configuration, right? But that wouldn't show up unless those things are actually happening. So instead of just having those three lists that we have today, it becomes a little more of a dynamic structure where it only shows the extra information if it's actually pertinent. So I'm fine with that. I guess again, my question is, what do we want to do if the first time this thing existed, it failed? That's fine. So then basically the, yeah, so it's like we can figure out the object. I think in that case, you would have a last failure data, right? Which contains the last failure and then there just, there would be no active configuration. So it's like the only thing in the name would be like a last failure, basically. Well, you might actually have a config that was delivered, right? No, no, no, no, no, sure. So sorry. In like last failure data, I'm including like the time, like the config that failed, you know, like various things there. And then do we have preferences on what we want to do for, if there's only a fail, like if there's a listener, it's pretty easy to say, we're going to remove it when it's removed, right? I don't think we need to have, you persist that. If it fails on startup, then there's a question of when we remove it. We want to have that be configurable or just kind of hard-coded for now and later when people complain. Right. I had just thought about that case and my feeling was that while Envoy is still polling for it, like while it's still trying to fetch it, I would just keep it there. And then if it gets swapped out, for some reason, it would be gone. Yeah, that works for the resources that are delivered by RDS and EDS where Envoy knows what it wants. State of the world updates, the things coming from LDS and CDS, that's not the case. And so, unless you're saying, we're essentially going to delete the failure now of each successful LDS update, which might be reasonable actually, because when you have a successful LDS update and everything that's on the floor, it's useless. I'm a bit worried if we're doing some multi-tenant, we've got scoped RDS and like there is some scope that fails that hasn't succeeded yet. And then we have a bunch of things updating all the time. Like I feel like it's something we're going to have to have mouths for and we don't want it. If you're not doing it incrementally, there's a difference. If you're doing these incrementally, that's the thing we're going to have to discuss is a separate design discussion. So as I mentioned today, scoped RDS is the state of the world. So each time you get all your scopes, all the tenants, and the ones that fail will still be consistent. Yeah, I think I'm fine saying for now, the default is on the next successful update we can wipe that information. Yeah. And then again, when that doesn't work for someone, they can add the rich functionality. I think that's fine. Because like one of the work items, and this came up, I mean, it's something that I know that we've talked about. And it came up when I tried to remove the experimental flag from config dump, is that we definitely still need to invest more in config dump in terms of like making it available for filtering and like various other features. So you could imagine that based on either a proto RPC or just like, you know, query params that you could change the behavior and actually make it display different things possibly. Okay. So I think what I'll do is I will try to just do a proto push today or tomorrow, which is a pure structural change. None of the coding changes. Yep. We'll iterate on that until we like the shape of it. And then I'll go and do the rest of the things. Yeah, sounds great. And I mean, if you don't mind, since you're going to do that, could you do clusters also? Because I think we're going to wind up with the same situation basically. Cool. Because that way we can just agree on the overall structure and make sure that it looks similar for both clusters and listeners. And costal listeners are basically identical from a conceptual point of view. Costal listeners and like route tables are quite different in that, you know. Eventually I'm going to want it for everything relatable. I would like to not do it all in one fell swoop. I think we should, even if we don't land all the API changes, like tell me which ones you want to see the prototype for now so we get the structure right? Like if you should prototype and can use things, I would do listeners, routes and clusters. Yeah. Everything that we care about basically. Okay, so what I'll do is I'll do that. I'll leave the draft PR with those three and then we'll agree to tackle at least listeners. Yeah, that's right, right, right. Yeah, so. I'd rather make sure, because again, when I was doing the listeners, I was like, well, this works for this, but this isn't going to work over there. Cool. Yeah. Graph changes for all three and then maybe again I'll just roll back clusters and routes once I'm happy with it. Yeah, yeah, that's fine. I'd say as long as we have a link back, I think to the API that we agree to for all three and then someone can come back to it later, I think that's fine. No, and I think this is going to be my spare time thing. I am no longer allowed to work on changes anyone cares about, but I mean, this is something we need in the next six months, but no one needs it in the next month. Welcome to my life. It's amazing. Yes, I do one change every month now. It's great. Hey, I got to fix our build up. I'm like, I got my CL stats up. One extra PR. We're laying behind Harvey. Okay, cool. I will do that when I can. Anything else you want to talk about over here? No, that sounds good. Yeah, I mean, anyone else on the call? Okay, 15 minutes back. Bye. Bye.