 I don't seem to have any video I can hear you just fine Yeah, that's strange Do you actually make it into the office today? Oh, yeah, I Thought about biking in I got the snow tires on now, but But if I work from home, I actually get to like code. I know I took the tea and actually I did cheat All the West Coast people like what are you talking about? I wish it was snowing more here It's been pretty pretty dry in the Northwest enjoy it vicariously Yeah, pretty pretty jealous Nothing better than snow says you I would be so much happier weather wise on the West Coast And yet Yeah, if you don't like it cold you're living in the wrong place Yeah, I'll tell that to my entire friends and family because I can't convince them all to up and move with me All right Um, I don't think we have anything on the agenda. I added in talking about the else of We'd also we brought up over slack Tweaking the Governance rules to say that changes to the data plane should be runtime guarded But we never actually got consensus on that Does anyone object because if not I'll send out a PR and just ping maintainers. I think my only question would be Like what I mean what qualifies is a change, right? I mean I would I would say things that are seen upstream or downstream, right? I think you're changing the way that headers work if you're changing like Tammy characteristics. No, you know access logging. No, yeah, okay Yeah, no. Yeah, that makes sense. I'll wire on the wire. Yeah. Yeah Cool. I'll send that out. Yeah and then again just add just to call it out because We mentioned this in a series of PRs, which probably not everyone read But the last time we cut the release we were doing the flag flips and realized that it's really not a great policy to have like All of the L7 changes land in one PR so we're going to change the way that the runtime cards work and as people submit PRs They will be applied by default unless they're really high-risk so things like Changing the buffer implementation and are changing the HP 11 codec will obviously be off by default So we can get fuzzing and everything done things that we think are innocuous Will be on by default, but again if they cause you problems you can just track release notes and look for things to flip back false So hopefully that doesn't cause problems for folks and if so again, we could discuss this but The alternative is is a lot of busy work doing them one at a time Which is which is kind of painful or having like the big massive awful change which we think is suboptimal Yeah Makes sense. I mean cut cut isn't one of the alternatives just a bolt which you know, puts the flags predetermined schedule Yeah, but I don't I don't know how that's better like doing it You know essentially like people can write their inscripts to have them false by default and do them on their own schedule like yeah I'm missing it in terms of covering all the alternatives. I feel like that. Oh, that's fair Yep, we could if someone wants to do resourcing for that like if it causes some problems I would love someone to write a bot to do that because I think that would be I think I mean, I think your plan of doing on by default unless we decide that it should be off I I think that will reduce most of the pain and it's pretty pretty easy to handle Yeah So that that that would be my vote but As you say if someone wants to work on some type of alternative from a bot That's and again, I would say for like big companies that that care about stable stuff They can again and they're the import scripts or so they can just watch that file and they can literally Have a script that says for every flag in the object that tracks all the flags You know set the false semi-config file like it's very scriptable To if you want to have them false by default for like google or something We get to pick that as part of the import process Yeah But I think Again unless someone's got a punny up resources for a bot. I think this is the way to keep The kind of binary changes least painful for the most people Yeah, and I mean and and just based on previous history I'm thinking through and I mean there's very few changes in which I would say should be off by default So like I can think of the buffer change. I can think of obviously the new hdb parser but like First our deployment strategy internal is off by default get the binary rolled out and then flip them on separately But again, we can just do that like yeah, we can we can script that programmatically internally But I think for most people like Having a you know, what just happened here and having to track prs of oh someone flipped the flag I got like where where was this fly? What does this do and then have to find a different pr? I think it's more trouble than it's worth I think that I think that makes sense. Yeah, so I've got one pr in flight and two more uh In actually two in flight and one more ready to go once those two lands to switch our tooling over and everything else Yeah, and I just put a comment on that pr or on One of the prs is that it's worth syncing with harvey just because he's done so much work now around Proto tooling and now there's frameworks for like in python for parsing the proto tree and stuff like that It's possible that when you looked at this a couple of months ago and thought about making a script to actually look at the Proto I think you're talking about the fade-by default which is different. Oh, I'm talking about the runtime cards and there are two things. Yeah Okay, it it would I mean just thinking forward though It would be I mean, I think we're also planning on getting some type of clang tooling into the code base And it would be nice if there is a way Either through clang tooling attributes something like if this was fully programmatic meaning, you know if we I'm just thinking through that if there is a way to tag a particular runtime call in the source code You know that then everything could just happen automatically and we don't need these python scripts like that would be For the for the flying flipping one. It'll go away. The only one that sticks around is the filing bugs to remove code I have one of my peers was to just remove all the fly flip tooling because we don't need any more So programmatically, um when you add a flag, it'll check unless you add it to the off by default or unby default Documentation says added to on by default unless it's a major change And then I just added a line to governance in the pr that's not out yet saying Hey, check to see if there's any off by default. So again, like I think like once or twice a year We'll have an off by default like Derek's couldn't But if it's if if the new default is on by default, can we just Switch the thing in the code so that we don't have to do anything unless it's off by default I like having them listed just because then you have a programmatic check. Okay. All right, sure I mean, it's adding a line to a file and then and then the nice thing about that is that later on We can add validation of like are you referencing flags that don't exist or are you setting? Are you setting false a flag that no longer exists? I think it's a big one because like if you're turning it off manually and it goes away You should be able to be warned about that. Sure. Okay, sounds good. There's method to my madness Does anyone else have agenda items? I don't have any um, do you do you want to give an update on b3 harvey in terms of where we're at? Sure So we resumed basically out to kubecom the work on v3 Derek please end of myself are currently working on it. We're actually looking for more volunteers if anyone's interested So please reach out to them slack Or elsewhere if you are interested in working on that Right now we have um, let's see we have the v3 alpha api has been generated directly from v2 problematically We have a bunch of plumbing to be able to Do things like ingest v2 configurations and automatically translate them to v3 alpha inside of omboy I'm currently working on this set client tooling which matt mentioned before which will Allow us to basically take all these v2 references in omboy and turn them overnight into v3 alpha references This is just going to be done in like in a single pr mass changing like the entire world and that one's basically what's going to be my focus in the next week or so and I know a lot of folks are working on things like adding in these ends are going to add in some annotations for renec to allow you to Specify fields in v2 that you want to be renamed in v3 And uh, I think Derek can work on some documentation Hey, sorry, so the plan is to move away from proto comments to proto annotations Um for things which are related to the versioning story. Yes Like, you know, we want to rename to this, you know, be annotation on a field. That's that's to me seems to make the most sense Yeah, me too. I mean, I guess what I'm asking is it seems cleaner to just have everything be annotations Versus things like lengthy comments like, you know in next major version instead of blurb or that kind of thing So I see okay Made sense to actually including the common text But yeah, so some of the others like, you know, not implemented Yet or that kind of thing I feel might be better served as as a pre-annuation and as we add these at proto annotations There'll be a pretty trivial pr to add that as a secondary source of that information and deprecate the old one So anyone who's interested in that kind of hygiene. I recommend doing that Yeah Hold back until v3 ships next year before doing the sort of optional things like this So we would be best off focusing our efforts on v3 stuff for the next few weeks. But yeah, yeah, okay Sounds good I don't I don't have anything else. Did anyone else on the call want to discuss anything? I just joined I I was you know, I'm working on this first connection object and The socket exposing socket options. I was just wondering if Anybody had some views that I could use during implementation or the certain questions that I have as People are people are aware about the topic. I can ask I think we've pretty well covered it in the in the comments in the issue Yeah, yeah So Matt Thanks. Thanks so much. But a couple questions inside my org. They've asked, you know, I understand I think the comments were quite descriptive. But What about, you know, I I had a question about the non-con Network connection, which is already available. So we are not worried about that right because through other Through other callbacks, you can actually access the net the non-cons network So the question was that you you you you cannot access the non-cons network connection from an l7 filter You can access it from an l4 filter Yeah, but but so the question that I got asked was why do we What what is the what is the uber goal for this per connection object because I have one interpretation like if I could hear it from your Or What exactly what is the uber goal for this per connection object because what to expose the socket options We don't that they require this per connection object. We can do it in multiple ways Would it would it like could you just? Briefly explain what what are we trying to fully accomplish? I understand parts of it like it It maintains state across different filters on that connection But we beyond that. I think we added the per connection object because you asked for it Like you wanted to store state across filters for a particular request, right So my interpretation was that I wanted to change the connection state like I just wanted to set the Socket read and receive buffers But yes through through the l7 l7 abstractions what we have We can definitely modify the state and maintain the state, but is there any other Is there any other need or is there any other design that you have in mind that That's not yet because you said you needed a full use case implemented, right? So one of which is the socket options. Is there anything else that you have in mind that where we can leverage this kind of an infrastructure I I think there are probably a bunch of use cases in which it could be used But I don't want to merge any code without an explicit use case So if you don't actually need the third connection object, we should close that pr Okay, okay um So what whatever we've discussed is to access use the per connection object through uh for exposing the socket option So that still remains right if we can get a use case like that So I I mean the use case as I still understand it is that we're going to add a mutable hdd connection Object and we're going to expose that from the l7 filter interface with a limited set of connection operations Uh that that makes sense to me Okay, so if I just want to That's fine. I think most of the questions are answered. I just was you know, this is my first time I'm joining the community cause I I thought I love When you get bigger more familiar with the process I'll share some ideas Sure, sounds great Okay Craig, do you want to Yeah, sure. I was just a follow-up from one of the kubecon talks specifically uh the envoy on fire debugging a service mesh one the access log Service came up and there were some questions It sounded like just like a call out to the community about a potential reusable access log server as an open source project And I was just kind of wondering if there was any work within the Community that you're aware of that's uh working on something on that Or if there is interest in that would it be Uh like starting from the ground up There's nothing that I know of yet So what what we have in open source right now is we have a project called go control plane which You know it it it's mostly targeted right now towards config serving So caching xds resources and sending them down But one of the things that it does do is that it deals with getting all the protos compiled and et cetera, et cetera, et cetera Um, I think it would be reasonable to take go control plane and potentially build either a separate service Or something optionally built into go control plane that could allow it to be used for access log handling Um, I think we have a general interest of making go control plane more useful to avoid the case in which you know, we have Literally probably a hundred plus or more different control planes out there Like everyone implements their own for a variety of different reasons Um, that's not a situation that I would like to be in. I think it would be better if You know people had to implement less logic So You know if there's interest obviously in figuring out how to do that From the open source perspective. I think we're very happy to support that effort You know, but it's going to take some people to actually drive that So one thing I can say is that um, the turbine labs rotor project I mean turbine labs doesn't exist anymore, but rotor was open source and it's still available on github Um, and it actually has an alas implementation on top of go control plane built into it Uh, that we use to collect logs When we were going concerned So Yeah, it's open source. It's free to steal Yeah, I mean and but like one one thing that we should think about is that if people either start using that code again Or we want to maintain it again We should just move that into the org and make it you know, I make it like a more official project and get maintainers and You know that that type of thing. Yeah, it's very specific to what we were building But there's some code in there that you might be able to at least look at as an example Yeah, we're cutting it to say go control plane. Right. I think I think that at a high level What I'd recommend for people that are listening is that Like we are very interested in having Um control plane implementations that are useful for the community Whether those be more building blocks or full featured servers or stuff like that So if there's interest, you know, I'd recommend either opening issues in the main project or opening issues against go control plane And either tagging myself or others and we can we can hopefully try to get those routed Thanks. Uh, yeah, that's all I had. Uh, sorry if this wasn't the correct place to raise the question No, no, no, no, this is this is definitely the right place And it's something that I've personally been thinking about and I know came up quite a bit at coup con It's just becoming it's becoming very clear that we have basically every organization Developing their own control planes. Um, you know, we're in a very very early stage of the Managed service mesh projects and lots of companies are not using them, you know, like tons of companies are building their own control planes and It's uh, it's a tough problem because In a perfect world, obviously, we would not do that But people are doing this for a reason, you know, because their situations are opinionated or they need various changes And you know, it's like we're trying to balance having something useful from a project perspective Um versus trying to do something so general that no one will actually use it and then they go off and do their own thing again so, um You know, there's there's just no easy answer. So I think that if there is interest In helping to, you know, bring some of this into the org My personal feeling is that doing it as more robust libraries versus a, you know, like this is the thing that you will use Is probably going to be more useful and tractable Cool. Anything else? Yeah, hi guys, um, I'm Yaroslav. I'm from cong I have a question about web assembly support in envoy Uh, I remember that um bracket and work on and work on, uh, Estimated that it will take a couple releases and releases to bring this web assembly support upstream So my question is actually to to you guys because there is already, uh, you're like working implementation This repository, you're like, what what is your, uh, you're like definition of being ready for upstream? Why will it take like this estimate? You're like about six months to get a finished upstream Is Is liaison on the call? No no, um So my my understanding of this which is not current is that I I think it's really probably comes down to the people that wrote the code work on Istio and They're busy and they know that to get it merged upstream It's going to have to have a certain amount test coverage, etc, etc, etc Um, I don't think there's any blocker there. So like I think with extra resources it could probably get merged upstream much faster Um, if you or others out there interested in helping with that Um, why don't you send me an email and I can make introductions with the people who are working on it And it's possible that you could just help them with the upstreaming. Yeah, that's that's definitely our intention And I think that the next question He'll even john itself. Uh, he mentions that the next step into brings upstream it would be Just settling binary interface yeah next sdk And going on from there. Yeah The question is is it actually critical to settle on? binary interface before merging upstream I think that I think that's something that we can discuss I I think as long as the filter is marked alpha I don't think it's critical that we that that we settle on the binary interface Obviously before we switch it from alpha to production We we absolutely have to settle on the binary interface But no, I don't I don't think it's required that the binary interface is finalized as long as it's clearly marked alpha Okay, because we took initial look into the source code and basically we would laugh from our side. We would like to see changes into everything into um Like binary interface into proto files exposed to protein face exposed to actual users Because it's moment. It's right now. It's it's really focused on east to use case. Yep. It's not really friendly to some right I would that's my concern is that I suspect that what they did is very istio focused And it's not going to be generally consumable So I would love very much if if you would get involved in that Um, and you could work with them to help get it upstreamed but is it fine for example to uh, bring uh, just like implementation in scarring state upstream and then declare it is completely out front no backwards compatibility and Right, like I don't I don't have any problem with that I think as long as it's clearly marked alpha we can get it upstream and then we can we can iterate. Um It would be good if you could list out some of the concerns that you have with the interfaces that are implemented currently Just so, you know that we can make sure that everyone's in agreement on how to actually get them fixed Um, and then you could work with the istio folks to start getting the code merged upstream faster Okay, okay Yeah But yeah, I would say just shoot me an email And then I can I can link together all of the various people Thank you I was wondering if there's any end users with opinions about the security policy update Oh, we have all been talking about it, but Yeah No end users There's uh, um for those that are out there who are end users There's a poll request that I opened in the last few days or week. I'm not sure it's been so many holidays and breaks Um, that will allow in very specific cases end users on the security pre disclosure list So if you have opinions on that, I would I would take a look Hopefully we'll get that merged today or tomorrow Anyone else? So matt I just wanted to ask another question on the start with implementation Which you were I raised an issue and you said so is it Is it fine that we have another filter called To just to do security and stuff like that. You said you asked me to look at the tap filter. I haven't looked at it yet But are there any How should the should start to be just an standalone network operation Sorry, it's it's very hard to hear you what what was that? Oh So I I was asking questions about the uh carpet issue Yeah, you had some You asked me to look at the tap filter, right? We are wondering like So instead of having the entire infrastructure setup like should we have another filter called security filter for So we use and we have our own variation of security filter as I've mentioned We call it the security filter. We do some sort of filtering for all the traffic that It's our load balances And I was wondering like would that be a use case for On boy, or do you guys not want to have that filter? No, we uh We we definitely do want a filter that I would say would become a a WAF type filter and do tar pitting and blocking and those types of things My comment in that PR is that we we don't want to re-implement matching Like we have a big problem in the code base of every filter independently implementing matching um, so what I would We we didn't re-implement we just like borrowed. We just duplicated the code for Uh, the RBAC match up. So whatever the code is we kind of we didn't rewrite it We kind of leverage the same logic and Change some of these uh keyword like, you know, how do you match based on what right right? What I'm explain what I'm explaining to you is that we don't want to re-implement the matching So what we'll need to do is we'll need to use an existing matching construct Probably the tap matchers because it's the most flexible Um, and then using that type of matching system We can then implement different types of actions, whether those be tar pitting or blocking, et cetera, et cetera Yeah, we do like three tar pit drop and reset. We also do like a static page redirect and capture is something that we're working on So, um We we have different with that enough, you know, if you have that as the context So for this particular tar pit issue, would you think that we should raise another? overarching issue And probably have that implemented or just have a tar pit standalone tar pit implementation Um, I I think I would like to see a complete design doc just to make sure that we're on the same page Okay Okay, thanks I'll I'll follow up on the issues. I have any further questions Or I'll update with the design what we think or what I think And then we can collect feedback Great. Thank you. Sounds great. All right. I think we're out of time Bye everyone. Yeah