 Well, thank you guys for coming to my talk. My name is Alec. I am a core product engineer at Gray Matter and also one of the active maintainers of Envoy's Go Control Plane. And I want to take this little 10-minute talk to bring everyone up to speed on what exactly has actually happened this past year and where we intend to take this project as it's become a pretty critical part of the core infrastructure for the Envoy ecosystem. So let's first start off with a little recap of what's actually happened. So if you're following the XDS lifecycle, V2 has been pulled out. So we're pretty much strictly on V3 and focusing more on the UD, which is V4 and forthcoming. So in 0.9.9, I believe, we pulled out V2. So if you still are dependent upon that, you're going to need to go ahead and pin back to an old version. In June, we introduced ECDS. So as the project's growing, more XDS services are coming out, more discovery. And we are continually integrating those into Go Control Plane as there are quite a lot of projects that do rely on us. So that came in in June. This I'll talk more on in a little bit, but profiling has become a big target for Go Control Plane. We know that, again, this project is required in a lot of places upstream. But none of us really know what actually is happening under the covers. We've never really profiled. We've never really benchmarked. We know it works, but we don't know how well. In August, we actually reworked the snapshot API. So I don't know if you guys are familiar with the code base, but this is pretty much the core interface with the cache. And we found that it was really difficult to continually update for those rolling discovery services that kept coming out. So we readjusted, we changed the API, and we haven't reached 1.0 yet, but I'm going to talk about that in a little bit. So we just merged those in, and we called it another minor release. Incremental went in also. That was a pretty big milestone, but I won't talk too much upon that. Since last year, I gave a talk on this. So if you guys want to go learn more about that, I would recommend checking that talk out. And then we just actually merged in the scoped route discovery service, and that was a pretty big change to the core internal logic, because it obviously changed a little bit how we handled route associations to listeners. So that's pretty much what happened in 2021. And then I'll go ahead and talk about where we want to go with the repo. So what are some goals for Go Control Point? We've had a lot of requests for a 1.0 release cut. We've had some pretty major projects now become dependent upon GCP, so like GRPC Go, their XDS implementation requires on us. Big projects like Istio, Kuma, et cetera, et cetera, those are all using Go Control Plane. So we can't just continually break. If we just keep breaking, it's going to become a huge nightmare and a big pain for all those control planes that are dependent upon our code. So what does that entail? The 1.0 stuff kind of involves a lot of protobuf upgrades and also a little bit changes to the Bazel system that Envoy uses. We want to focus on benchmarking. So like I said in the beginning, we don't really know how this is performing. There could be optimizations out there we don't understand, and we want to investigate into that. And we're going to continue to bug fix. Again, this is a pretty popular project. A lot of people use it, so we want to make it as stable as possible. And then a reference implementation. So I will save that, but that is a big, big goal for Go Control Plane in the coming year. So for the 1.0, we decided to go with a multi-module release plan. So this means that if you're familiar with the code, we have the generated protostubs from the actual data plane in the code base, as well as the actual reference implementation of the XDS server and cache. So we have to be able to version those independently and asynchronously. So by doing that, we're going to treat that the protostubs version separately, and then, et cetera, et cetera. So we have a plan. I'd recommend downloading the slides and checking out that proposal to see how that's actually going to be versioned. It's a pretty complicated process, but we are working to get that done. We are dependent upon some deprecated libraries. But we want to move to the latest, which is what Envoy's pointed out. So that's going to require, again, some of those Bazel build upgrades. But that's pretty in-depth. And we are lacking a little bit of bandwidth on there. So if anybody wants to help out with that, please, please make an issue. And we would definitely reach out and like to collaborate. So for benchmarking, this past year, we integrated Pprof, which is Google's Go profiler, where we started investigating how the code's actually performing and optimizations that we can make. So the reason this was done is because incremental was merged in. So we wanted to see the differences in actual compute load for the XDS types. And we are actually working on building a full end-to-end throughput benchmark. That's not done, but it is something that I think a lot of people will benefit from as they'll be able to see what the actual benefits of incremental from state-of-the-world are. So the reference implementation. Previously, Go control plane was not really looked at as something that a lot of people would really use or depend on. So with the ecosystem growing and maturing so quickly, there's been a lot of issues that have occurred around replicating common functionality across multiple projects. Matt actually wrote a really good blog post in last year's EnvoyCon about greenfield deployment and the code replication, et cetera. And I'd recommend you guys go read that. But that replicated code is a problem. People are solving the same solution over and over again. So how do we fix that? Well, we bring it all upstream. And because Go control plane is a Envoy-sponsored project, it's a perfect place to do it. So we break down some common functionality across these projects. We bring them up, and maybe in Go control plane is a really good place to do that. We could even potentially have something like a reference service discovery mechanism, because what are all these projects do? They're all tackling the same problem. They're all performing service discovery. They're all doing health checking, circuit breaking, et cetera, et cetera. So is there really need to replicate this over and over again? So that's basically where Go control plane is going. That's our thoughts and ideas on the project. And again, we would love for people to help out and also maintain this project. We have a pretty small bandwidth for the maintainers. I think there's only four of us. So the more help we can get, the better. But yeah, thank you guys. And I will be in the slack if anybody has any questions.