 I think we'll give folks one more minute to show up, and then we'll just start going through the agenda. So I think Flynn is here, so Matt, do you want to pull for other agenda items or should we just start? Sorry what? I know Flynn's here, so do we want to just start going through the agenda items or? We have a lot on here, so we should probably just get going, yeah. Okay, Flynn, do you want to update on all three and all three? Sure, can you hear me okay? Yeah, excellent. So, many of you would have seen the pull request that I submitted, I want to say a couple of weeks ago about folding ambassadors authentication mechanism into Envoy. There was a lot, the PR has since been closed after a lot of discussion, a lot of back and forth. The long and short of it could be summarized as there was a lot of interest in having a more flexible auth mechanism as part of Envoy's core. There was a lot of discussion about how best we could do that in light of both the Ambassador PR and the earlier TIGERA work, and the end route forward there is going to be that we'll be talking later today between myself and the TIGERA folks about how to get the work done of folding ambassadors functionality and use cases into the existing filter from the TIGERA folks, which I'm very happy with and thanks to all involved. Thank you for the update. Yep, I will, one other thing, sorry, I'll be creating an issue against Envoy to track where we will track all the work going forward. That should happen a little bit later today, and hopefully we'll be able to get this thing wrapped up pretty shortly. Harvey, are you, you are on, do you want to talk about the view on deprecation schedule? Sure. So I think, you know, we're heading into the 1.6 release cycle right now while the 1.6 release is actually happening in the next few weeks. Is that correct Matt? Yeah, my plan is to kind of work on it this week and we'll burn down the remaining issues to hopefully do it later this week or early next week. Okay. And so as most folks know we have the V2 APIs now they've been production ready since Envoy 1.5, which was last December. The plan is to turn down the V1 APIs. We don't understand that there is quite a lot of dependence that folks have on the V1 APIs that there are various management stacks integrations that are based around the 1.6 API. We're not deprecating these aggressively as we are other features in Envoy. The plan of record I believe, and please correct me if I'm wrong folks, is to not deprecate them in the 1.6 release cycle. So it'll be 1.7 of which we announced that they're deprecated in three months time. And the way we have things working without breaking changes policy is that we then have another three months essentially of them being enabled. At the beginning of the 1.8 release cycle, we will actually remove that functionality. So that essentially gives us nine months, right? Yeah, so I think nine months. Yeah, it'll be it'll be nine months until there is a release in which the V1 code is completely removed, but it will be removed at the beginning of the 1.9 cycle, which will be approximately six months. One other piece is so we will document this entire policy and we'll get this sent out and it'll be on the website and we'll send it to Envoy announce. The other thing that we're likely to do is that in Envoy 1.8. So that means the beginning of the 1.7 release cycle in approximately three months. We will flip so there's a flag right now there's a command line flag, which it's basically tells Envoy to only use V2. So it's helpful for debugging because right now Envoy will attempt to parse config is V2 then it'll fall back to V1. What we will do at the beginning of the 1.8 cycle so in about three months we're going to switch that flag to default to true. So basically by default Envoy will attempt to parse V2 only so people will have so people will have to explicitly put in false for that. And we'll probably put in some type of warning also which basically says that in three months time, you know this code is basically going to be removed. So that will hopefully help people understand that they basically need to upgrade. We strongly recommend that folks don't write any new V1 integrations and start moving to V2. I mean there are other advantages than just having your API disappear from underneath you. Specifically like most new features are going into the V2 APIs already and probably after the next release cycle will start pushing back pretty hard on any additions to V1. So really is it feature-free state then? Yeah so starting basically next week we will be pushing back very hard. As once Envoy 1.7 is released in about three months we will not allow any further V1 features so it will be completely frozen. So again the kind of TLDR of this is that you know if you're running actual version releases you have nine months. If you're running master you have about six months. Yeah I mean now would be a good time to speak up if anyone sees a particular problem with this. Yeah there's also any blocking bugs causing you to not be able to move to V2. Let us know and we will be aggressive about fixing them. And we will also send an announcement about this to Envoy Announce. Oh I think that's that agenda item. Cool. What's next? Sorry I'm looking what's next on the agenda. Rippo reorg. Oh okay let me cover this one really briefly. So there's a GitHub issue that I opened before I went on paternity leave. And the kind of idea behind this issue is that you know at this point we have a whole bunch of different extension possibilities in Envoy. We have different kinds of filters. We have network, HTTP, we have listener filters, we have stats syncs, we have tracers, we'll probably have health checkers in the future. So right now the extensions are kind of sprinkled all over the repo. And that has a couple of different downsides. The first downside is that it's hard for people to actually look at the extensions, understand what there is and actually learn from them. The second problem is as we're growing this project, you know we have an increasing number of PRs. There's an increasing burden on maintainers. We'd like to get to a world in which we can have you know specific code owners files for specific extensions. So actually start extending you know that the fact that there may be people that own certain portions of the code that are not core actual maintainers. So we proposing a repo reorg and what's in that PR is not completely up to date. So the idea is to kind of move to a model that's a little more like Linux kernel in the sense that Linux kernel has like the core code and then there's a set of drivers. So what we'll essentially do is we'll try to move all of the extensions over to a specific directory structure called extensions, and then we'll break those down very clearly in terms of what extension types they are. And again that will allow us to more easily understand what's there, it'll have code owners, and also it's going to allow us in the future to actually again kind of like Linux kernel will be able to have compile flags probably for different filters. So the people that want to either from a security footprint perspective don't want to install certain filters or you know low, low, low memory footprint devices they don't want to install lure or something like that. We can basically compile that out. So I'm going to go and update that issue from a final proposal based on in person discussions with with Harvey that happened about a month ago. So watch that issue if you're interested, and then assuming that there's no major objections. Once we release 1.6. I'm probably going to start doing the work to kind of slowly move different filters over. And, you know, there's going to be a learning process during this in terms of, you know, what code is still kind of shared and like do we need other extension points for example to get all of the code out of common. So the one example is right now we support Redis health checking. So until health checking itself is pluggable, we can't take the Redis code entirely out of core. So, you know, there's going to be some to do is to actually come from this from things that you know that will need to make extensible to actually get that code out. But yeah, so we will update that this week and definitely speak up or ping that issue if there's any thoughts there. Yeah, there's there's one related thing to that and that's I know the user Dio Dio was looking at sending envoy filter example with some, you know, different types of filters and the idea that was to have that reflect the new organization. I'm actually wondering whether we actually want to think about reorganizing envoy filter example and actually moving into the main repost on these educational pieces and stripping that down to the bare minimum necessary to show people how to just do the build and link. Because that I mean we've always had historically issues with you know, big rots and maintaining. Yeah, yeah, I would be in favor of just getting getting rid of envoy filter example and basically having example filters that that don't necessarily go by by default. I mean, it would be useful I think to retain that repository just to show how you do the build link stuff. I mean there's some non trivial things that which would be true. Yeah. Yeah, one, one topic that we probably won't have time for this week but we should put on the agenda for two weeks from now and I will open an issue on this is, I think at this point we have a general need for GitHub bots that do like 17 different things. And like you can imagine that like we should be having a bot that whenever on my master changes and automatically commits the shop update into on my filter example and then basically tells us if it actually breaks. So, you know there's things that I think that we can do to help us with that bit rock. That's true. Yeah. But yeah so why don't we why don't we go ahead and I will take the action to at least open an issue on like what we want from bots and bots are actually a great thing for people out there who don't necessarily want to write C++ but like want to help that that we could get them to help with with with bots. Okay, just doesn't anyone have any thoughts or questions on the repo reorg. Sounds like a good idea. Great. The next agenda item is just increment XDS. So, this is actually just public service announcement or sort of a request for sort of interest from folks. So, Nicola who's a Googler and myself are working on a proposal for incremental XDS right now we would like to speak to anyone who's interested we'll have a public doc most likely later this week or early next week and but we would definitely like to look into the conversation earlier rather than later everyone who's interested in this topic so the idea is already Nicola has a sort of a work in progress PR for lazy loading where you can fetch additional resources such as clusters dynamically based on incoming requests. The idea here would be to see if we can actually unify that with the core sort of XDS protocol and support incremental updates along the way which were something which were also on the roadmap for XDS later down the track but there's an interesting confluence that might be possible here so please reach out to either myself, Matt or Nicola on Slack and we can loop you in the conversation if interested. And then I think the last item is Chris. Yeah I was just curious, you know with the audit that we did with cure 53 in terms of our thoughts of just publishing and looking at off of the Let's just publish it. I don't I don't see any reason not to unless there's other objections. Yeah, I've started to actually turn some of those issues those like the various bugs that they categorize into actual issues. Anyone I've done so far has been the high priority one they flagged which was the CSRF. I can do the manual grind and just turn the rest into distinct issues and we should also publish the PDF and that sounds good. Yeah, I put up a PR for the for for doc for the admin security thing with a big warning there so if people could take a look at that we can just get that published. I think it's fairly obvious but that that wording should make it even more obvious. Cool. I could do the PR to link the PDF so. Okay. Except for my end. Cool. Anyone out there have any things that they'd like to discuss. One of the things that that came to mind while you guys were talking about the deprecation of the V1 API is we just filed an issue where we're seeing connections dropping when we do hot restarting. And on the one hand, it would be kind of interesting if anybody has a cycle or two to take a look at that. But on the other hand it occurred to me to wonder as the V1 config goes away then is hot restart also going away. No, definitely not. There are people I think that will continue to use it like particularly people that don't use LDS. So I think the hot restart will be there basically forever. Cool. Yeah, for for your particular issue, I was I was going to ask you some follow questions in and get up later today. Yeah, sounds good. And I'm always on slack too. Okay, great. Cool. Thanks. I guess one one other question for me for the group as we're starting to talk about releases. Do people think that we need to start doing early candidates or is is the is this the procedure that we're doing now? Is it okay? Like from my perspective, I'd rather not do release in less there's a very good reason for it. You know, we're quite we've kind of taken the general approach that we're always at release candidate quality on on master. So is that still it with people or is that going to become problem that works for us? Yeah, I think for you the policy of release candidate, you know, master is always released candidate quality and run with that. Okay, sounds good. One other thing that I want to write it is why most pieces of it's very hard to hear. I mean, there was one other thing that I actually wanted to ask which is why most pieces of the configuration has become dynamic. The only thing that really making one thing which is the pacing competition like specifically specified, especially the some of the collectors. Hey, hey, sorry, you're you're like totally breaking up. You can type it out. Yeah, do you want to type it in the chat thing? Yeah, so so for any for any config, you know that people would like to be dynamic. I think that's totally reasonable. It just has to get resourced and someone has to work on it. So I mean, my general feeling is that, you know, there are certain config options that really don't basically change like once bootstrap is actually written out and making them fully dynamic is probably going to be a substantial amount of work. It's not that it can't be done. But what what I recommend is just for things that you know people would like to see dynamic was just get issues opened and then we can we can discuss there. Okay. Anything else. Happy to be back. All right, bye.