 So should we get started? Sure. OK. Searching for speakers or listeners for Ukrainian conferences. Whose item is this? OK, maybe they'll join later. We can get back to this. Africa support status. Whose item is this? Someone asked. That's me, Greg Hansen. I work with IBM and Istio. And just we're trying to integrate with a Kafka deployment that is limited to Sassel SSL for the authentication. And in our attempts to communicate through Envoy to like a broker for sending and receiving messages, we're getting a HPE invalid method and Envoy access logs. I was wondering if that was related to any of the work that's ongoing with the Kafka support. I know there's a pull request and an item tracking the work. Yeah, there's no Kafka support in Envoy today. So there's no Sassel support. There's nothing. OK. So if that's interesting to you, I would recommend hopping in and potentially helping out. I think we have a good plan forward of how to move that PR forward. I don't know what the timeline and status is. But we're at the point now where we've gone through a bunch of iterations. The Kafka folks have nicely just, they have like a JSON version of their protocol so that we can auto generate the various classes so things are better now. So I'm hoping in the next month or so we can get something basic merged there. I don't know that that's going to do Sassel though. So someone would have to come in and do that later. OK. Well, no, that's great. It just means that, yeah, that's the PR that I should be watching and possibly the person I should be badgering regarding Sassel support. But no, thanks. That answers my question. OK. Cool. And if it's an HP error, does that mean they may have accidentally configured HTTP one? Yeah, that is the one error that I'm seeing is dispatch error, HTTP 1.1 protocol error, HP invalid method. OK. And the app when I'm trying to attempt to connect through Envoy, I'm getting basically a response of unknown protocol for Sassel underscore SSL. OK. I mean, that's because we just don't support it. So you'll have to either use raw TCP to go through Envoy or someone will have to come in and implement Sassel support. OK. Yeah. Hi, this is Lin. The reason we are kind of asking this is it's interesting. We actually find a blog, probably more than one blog out there that people actually using GKE and then they were using Kafka. I think they were using Confluence as an example. So they were able to create service entry to access Confluence, which runs outside of the mesh and then use service entry. And I believe they were using TLS protocol as part of their service entry. So we know Envoy doesn't support Sassel, but I guess we were trying to understand what if we config to use TLS to access Kafka, which is external off the mesh. Would Envoy just to allow the communication? Why would people actually get it working on the blog? So those are the questions we have. We are saying you won't get any of the intelligence like routing or logging metrics feature of Envoy, but basic connectivity. Envoy can TCP proxy. Right. Here, I would recommend if there's Kafka questions, like I don't know that anyone in this call is going to have more info than what we just said, but I'm happy to start a communication with people at Confluent. So if you want to know more, could you just send me an email and I can introduce you to people at Confluent? Yeah, that would be great. Maybe reach out to you on Twitter. Would that be the best way, Matt? Or my email, mclientatlift.com. Okay, and then just to make sure we... So you said if we access to TCP and TLS, that would be okay. Just nothing specific to the SASE protocol, right? Right. Okay, thanks. Okay, next issue. This is one of the reasons that we might want to discuss and know if he's on the call, yeah, he is. We need to bump our use of autocom to fix some snafu, which is as a result of this layering of technical debt, which comes from this CMake external stuff. Basically, we're trying to pass down flags for things like sanitizers in the environment, which have actually, now that we're doing that, they've started to actually cause our external dependencies to build with sanitizers, which is a good thing, you would think, but it turns out some of the auto tools, autocom stuff doesn't work very well with ASAN, at least with earlier versions, so we need to bump this. And then that slide us down the rabbit hole of, do we do this by bumping the CI image? Do we generate just the configure script and just check that in? And maybe it sounds like if we don't want to bump to 1804, we should just generate the configure script. And I think that will fix it, assuming that there's no other... Assuming it's in the actual generation that the bug was fixed, then I think that's all good. Well, I don't have the full track of where all the configs used. Is that only G-perf tools? Probably, I mean, like we're now down to two build recipes. There's LuaJits and G-perf tools, and LuaJit is its own weird make monstrosity, so I think it's just G-perf tools. Okay, then G-perf tools. So we recently bumped the G-perf tools to some master commit instead of release 2.7 to support the PPC architecture, I think, that's by Christopher, I think. So that one doesn't... So the master commit doesn't have generated configure script, so we have to run Autoconf since that PR. I see that was a new introduction, and we didn't used to do that. Yeah, we didn't used to do that when we were on the release version. And is... So just to... You know, the essential model is that Autoconf generates the configure script. Does it rely on anything in the environment while doing so? Is it really a... Yeah, Autoconf shouldn't rely on the... environment since it generates Autoconf configure script to detect the environment stuff, right? Yeah, yeah, that makes sense. Autoconf, yeah, it doesn't make sense Autoconf, it depends on environment. Okay, well, I tried to bump to 1804 anyway, and it fails in spectacular ways, so I'm kind of tempted to then just go down the path of checking in the script as you suggested. Yeah, I think that would work. Yeah, and that's probably easiest way at this point. And I think bump to 18.4 is too heavy for the community at this point. We might eventually do the upgrade, but yeah. Yeah. One thing we could probably do, I don't know if it's worth the effort, is we could make two build images, one 16 and one 18, and just use the 18.1 just for the ASAM build. And I'm not sure that that's worth it. The other thing that occurred to me, and I mean, wouldn't it be less effort just to make Jeep Perf Tools work with Bazel? Like, I mean... Well, I have a thread about that internally. The maintainer of that doesn't believe in Bazel, to be honest. So that was his response. So I mean, what can I do? I mean, don't you have some Google camp that you can send this person to that can fix him or something? I don't know. That's not the way things work at Google. People disagree. They just disagree, it turns out. Is that a guag joke, man? Yes. Yes. Can we not just add a Bazel with a build file? John Merlin tried to write that, and he said it's defining from his skills, and he's like a Bazel ninja, so I'm not too keen to try and do it again. Okay, that's fine. Yeah. Harvey, did you get any answers to, like, when there would be an actual release of Jeep Perf Tools? Like, soonish? I don't know if I asked that one. Yeah. It's been almost a year since the last one. Yeah. If you can ask them when the next release, probably that will be. Yeah. There is one promising development, and that is, AbSale might include TCMatic in the future. So that will be part of our coupling to Jeep Perf Tools. I think we still rely on it. We still rely on it for anything else. Like, probably for profiling and so on, but we could always make that an optional thing, right? Yeah. We use it for CPU. Well, I mean, the thing, I've always found that the Jeep Perf Tools CPU profiler doesn't work very well for me, so I always use Perf, but the heap profiler does work quite well. I think the CPU profiler probably related to the stack unwinding issue that I found, that's the bug we have since we don't modify the system library to have the frame pointer. We don't do that, but the enable frame pointer expects you have the all dependency to down to libc have frame pointer enabled. Got it. Yeah. I mean, it's mostly, I've just never looked into it because Perf works so well that I don't see the point. Yeah. Okay. Cool. So I think that we know where to go with that one. Envoy usage platform survey. Yeah. So, you know, we keep talking about things like, can we update to Ubuntu 18 or move to C++ 17? So one thing that occurred to me is maybe, you know, every six months or something like that, we could send out some type of survey just to understand, you know, what, what OSs are people deploying on? What compilers do they have access to? We could ask them, like, do you have access to a version of GCC or Clang greater than X? And I feel like that would help us make much more educated decisions about can we drop X compiler? Because right now I think we have absolutely no idea about what we can do. Fair. That's good, although, you know, how do we get people to actually respond? No, we can't. I mean, but, but I don't know, like as long as the usage was anonymized and we don't ask access, like, like where they work or whatever. I mean, we can just send it to Envoy Announce and Envoy Users and yeah, it won't be perfect, but it's probably better than nothing. I bet when you said if you had CNC app drive it and they have like social media and like they can like repeat it. Yeah, I mean, like we can do social media. We can send it out on the email. So that we don't have to do. Yeah. Yeah. So, so if people generally think this is interesting, I will open a ticket with the CNC app to have them help. Yeah. Chris just said CNC app can do that. If you know we have Chris on the call, maybe we can discuss the Envoy certification thing as well. Well, do you quickly want to talk who put the C++17 thing in there? That was us. That was us. That's less pressing. Are you, are you already able to do C++17? No, but it's coming soon. Yeah. Yeah, it's it's imminent probably sometime in the next year. It's probably a few months off. Yeah. I mean, if we could actually move to 17, I'm not sure that we can having access to standard file system would be pretty nice. Yeah. Yeah. So I think, I think if we are able to go to 17, the question then becomes who else. And I think the survey is probably the best. Right. Yeah. So my, my, my gut is that we probably, it would like, I don't think we have enough information to go to 17 right now, but why don't we get the survey going and then let's just see what it says. Yeah. Right. Yeah. Okay. This probably means we can remove all the string hacks because that's happening. Oh, oh, that's in the same. Really? Yes. Wow. That made me really happy. They are linked. Yeah. Yeah. We need to undo the string hacks before we can go to 17. It's like, oh, it's a strong prerequisite. Yeah. Well, Yeah. That's pretty exciting. Wow. I will be happy to never have to think about that again. That's great. Yeah. Apologies. Yeah. Okay. So I guess we do have Chris on the call. Could you Chris, could you talk about this? I don't know what, what you call it conformance programs or is it an application program? It's kind of up to you. There's some folks that reached out that it could be interesting for as Envoy's being adopted by different cloud providers and offering kind of, you know, Envoy's a service, you know, at mesh style to have a conformance program in place to ensure that if people call it Envoy, at least meets whatever your community standards are similar to what we've done with Kubernetes where all the folks who have a Kubernetes service essentially have to go through this program, pass the end to end tests, you know, determined by the community and then they're able to be granted to use the Kubernetes term. I don't know if Envoy is there yet, but we're happy to do something for you if you think it's required at this point. Are you talking specifically about management service here? Yeah, manage Envoy. I don't think anyone's doing like distributions or anything like that yet as far as, as far as I know. For Kubernetes we do both for managed service and distribution. I don't really have any strong preference. I mean, if there is someone out there that wants to drive it, sounds fine. Yeah. I mean, what I'm probably going to tell you, I guess he's writing us a very comprehensive suite for management service to validate that conformance, which would be only a good thing. Like it'll improve our range of tests that we have out there, sort of reduce the need to duplicate this each time someone wants to write a management server. Yeah. But someone's going to have to write those. We don't have anything close to that today. Yeah. Yeah, I mean, if it's not the most important kind of burning problem for folks, then I'm not too worried about it, but as more of this comes up, people generally want to use the kind of Envoy mark for things. And right now we allow that. So, you know, there's a reason it's AWS AppMesh and not AWS Managed Envoy, whatever. So. Yeah. But in the other side, from the distribution side, we have a lot of like Envoy-based solutions on that side as well. Like Instaproxy is one like ambassador and like couple of them are based on Envoy and how much they are like aligned with upstream. If you use with the management server, can act like upstream Envoy does something like that. It's also a components test can do. Yeah. I don't know how many distributions are of Envoy or out there. Yeah. Maybe in the survey, we could figure that out and use that as data to. Yeah. Do this or not. Yeah. What, what we should probably do is, and I'll take this action item. I will start a Google doc of survey questions. And then maybe we can collaborate on what we want to ask. Obviously, we shouldn't ask too many questions. People won't answer them, but, but let's, let's, let's try to have some type of usage survey and then we can go from there. Yeah, that sounds nice. Hey, what's next? Extra time? Seven minutes. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Well, I guess are there any other topics that people want to talk about before we talk about that? Actually, I just have a quick question about. Caching spec that we introduced a couple of weeks ago. Where. Yeah. We've gotten a lot of really good feedback on the doc. And I wonder if. Yeah. Yeah, this is a close process for kind of saying this is, this proposal looks acceptable and we should start sending PRs that actually provide the infrastructure. Or should we do like formal review? Having had some comments. Again, it's meeting. What's the practice? I don't, I don't know that we have an official practice. I, I, I, my, It's probably okay given the detail in the dock to start and just iterate That's that's my personal opinion. I'm not sure if other folks have have any different opinions Guys, I wanted this is a different solo. Can you hear me well? Yeah Yeah, so I just wanted we built And we feel there for a catching and we would love to give it away to the community And we have actually out of filter that maybe will be interested in So just let us know what we can do about your kid. We can help we also filter and transformation filter So if you we would like to work with you guys great you and I have been kind of attempting to think up I'm about to head to California for a few days Yeah, that's good. We bought in Cambridge. It's just make a lot of sense. I was gonna say you all work in the same place should be very I will say that we have quite a lot of customers. So we would love to share if you need any help about How people are running it with us. We would love to share That'd be great. I'll set the thing up and also invite Todd who's on the West Coast to join us by video Any other items before we discuss the CDS updates here, okay So, yeah, Matt Okay, so let me just make sure that I understand the problem because it's possible that I don't I don't even understand What's going on? So the problem as I understand it is that Rama has a situation where, you know, they have some management servers that are coming up and down and A new management server comes up. It doesn't yet have all of the information So it goes and it responds to a CDS update with the clusters And then envoy asked the management server for all of the all of the EDS updates The management server doesn't know about some of the clusters. So it returns an empty update and that causes the cluster to exit warming with no hosts and The fix that Rama has proposed for that is that because in the XDS doc There's a line that says that if If an EDS response does not contain a Resource envoy is allowed to use the last known good resource of that type So some code that basically detects whether That case happened So if the management server responded with some number of clusters but not the one that was warming and He detects that case and if it's that case then he copies the hosts from the old cluster to the new warming cluster Is that like am I even understanding the problem? Is that yeah, I think that's roughly right I mean I have to refresh myself on what on there's one detail there, which is what happens On the EDS front like envoy So when you when you update a cluster that should necessarily cause any activity to happen EDS front Unless it's like removing and adding a Watch that's probably what it's doing which then causes some some Activities remember you basically always have a hanging get on the an EDS at all times, right? change The resources that you're watching that the management service sees any activity or you're acting something Right, but my my concern here is that we're proposing putting a bunch We're putting some very specific code into on boy, which seems kind of scary to me Which is that we're in the tactless case and we're gonna copy hosts from the old cluster to the new one You know Go ahead. Well, right. I was gonna say so Just just by itself that actually scares me because like do we know that the like the all hosts apply to the new host? That seems potentially not right and to and I'm I'm done, but like I It seems like it's a problem on the management server side Which is the management server is accepting connections before it's ready to actually serve So Yes, I agree with the the last points and I think there's two separate things to discuss the first is What are the one of the correct semantics here? And we can discuss that whether it's okay to you know, keep the old EDS Posts and the other thing to think about is like what's the correct mechanism for implementing this? I kind of feel that the trunk. I think it's kind of like hairy and complicated to transfer hosts across. I agree clusters my suggestion in the original ticket was at the XDS level we cash resources essentially and We feed that we feed them back To to the new warming cluster without actually doing a wire traffic If that's what you want to do is your implementation mechanism and that seems simple to me But but in in this particular case, I guess I still don't understand Let's say that you did the caching How would you even detect the caching because if the cluster config changes? Let's say someone changes some TLS setting or like something else. Yes How could you guarantee that that it's the same hosts? Like I guess I just don't fundamentally don't understand How okay, so the networking we're getting into the semantics I mean, I think you know from a mechanism point of view what you do is you just keep the last known Set of hosts for that cluster and you feed it back Where when The cluster comes back up and you know, there's only been an update So I don't think that's the issue that so the issue is like is it safe to feed to you to reuse the same hosts across a cluster update? and I think that a good example is switching from hdb to hdps or back and Then it comes down to I think do you care about eventual consistency or strong consistency because if it's eventual Consistency the management server shouldn't be sending a host update anyway Like it should be doing a push-based one. So let's say you switch from hdb to hdps You should get a cds update and then immediately after that you should get Yes update for the management server that will override anything that you've cashed or served up in that way, right? It's sorry. We're getting kicked out of the room. I'm trying to go out into the hall. Yeah Yeah We'll hurry it keeps out in a sec. Um, so I think this is a we may want to actually have a simple meeting about this Okay. Um, why don't we? Yeah, well, yeah I mean, I think if if you can carve out 15 or 20 minutes just to look through my comments And then let's discuss in github and then if we feel like we're not getting anywhere in github I mean, we've got time zone issues with Rama But let's find a time that all of us can actually meet because I think this is I Just don't want to jump into putting this code in because once it's in it's a behavior that we can't take out ever So, I mean what I would say is just just the mighty LDR is yes I am in total agreement that the management server could fix this problem The second is I think we could do things slightly more elegantly By not, you know doing surgery engine cluster manager and the final thing is what I think the crux of the issue comes down to is Whether we care Whether we care about being able to make like it's it's it's it's it goes like this early discussion had around ADS about how Concerned we are about, you know reusing resources while updates are taking place and how important it is to guarantee Consistency over sort of windows and whether it really should be up to the user to do a proper make before break with it I think if we cluster resources versus I'm trying to reuse the same names So there's a whole bunch of things in that discussion, which I get clear. Okay, sounds good So I I guess let's just not jump into merging that PR. Let's let's let's make sure that we're doing our due diligence Okay, okay sounds good. Thanks. Oh, okay. Bye