 Okay, cool. So welcome everyone to our bi-weekly SMI community meeting. If you haven't yet, please add yourself to the attendee list. And with that, do we have anyone new on the call? Yeah, Matt, do you want to introduce yourself? Yeah, yeah. Hey, everybody. My name is Matt Yacobucci. A lot of people call me Butch, so I think you might have seen some of my messages out there. So I'm working with NGINX, and so we've just released NGINX Service Mesh. It's now public. It was a little bit behind a wall for a little while, but now that we're public, we're trying to reach out to the community and be better members. We've got all the legal stuff smoothed out. We're able to contribute both to SMI Spec and SMI SDK Go. So that's all good. The whole team is ready to go. And from NGINX BU and F5 perspective, we're ready to engage. So I just wanted to say hello to everybody and I'm going to try and be a semi-regular member to these meetings. That's awesome. Very warm welcome. And that's really great to hear. Do you maybe want for next time or whenever you plan to try and again give a quick demo or walk us through a little bit? Yeah, that sounds great. We're still trying to work through some of our understanding and we want to collapse on certain understandings around the specifications. So yeah, I'd love to give a little five minute presentation on it. Awesome. And can I also ask you to, if you click on that link that both Lee and also Richard are going to share to add yourself there just saying your name. Yeah, here we go. Yeah, whatever you prefer. Thank you. Awesome. Cool. Welcome Birch. Excited to have you and congrats on the launch of the service match over at NGINX. Yeah, great. Thank you everybody. Did you say that the NGINX mesh is already SMI compliant? Or you're working on it? It is SMI compliant. Yes. And so we're up to all the latest versions. We're shying on some of the SMI metrics. So we don't support every resource that's called out, but we have stateful sets, damon sets, deployments, pods, and namespaces I think is what we're limited to right now. Okay, that's excellent. And let's make sure that you are listed on our webpage there, right? Yes, and I do want to get listed. We have a little bit of an embarrassment though with circuit breaker in rate limiting. There was a miscommunication or misunderstanding with the team on how those should have been namespaced. We do want to talk to you guys about proposing them going forward. It always should have been in our organization. So I don't want to communicate that until maybe next week. I could send you guys a poll request, whatever the method is. But our next release that should be out has that cleared up. And then I want to move forward with saying this is awesome. Awesome. Perfect. Thanks for that. Yeah. Oh, yeah. Richard, thank you very much. I should just share the link up to at your logo, the fragment in the repo there. If you just follow that. Cool. Thanks a lot. Yeah, I will move mine, the open telemetry towards the end, unless I see someone here. I like how you have the humility to skip the item I added to the top, which is, hey, we didn't actually talk about it at a meeting. We did talk, but we didn't write it in the notes. So I'm putting it for posterity that Michael and Turin are spec maintainers. Sorry, I was so focused on what you described there around the introduction of NGNX that I didn't really see that. But yes, thanks a lot. I'll just make a minor correction. And awesome. So are we good to go to Turin's agenda item around the SMI metrics, images and charts to get up? If anyone else has insight about it, he had it last time, so we pushed it to this time and he isn't here today. So we could push it further, but I don't know if somebody else already knows or has enough context to talk about it. Going, going. Okay. Then we have from yourself, Richard, regarding the upcoming schedule question to cancel the next time. Yeah. So the meeting November 25th would be one day before U.S. Thanksgiving and even with the pandemic, people certainly have like family obligations around that time. I know I'm off work that week because I took vacation then. And then the meeting December 9th would be fine. And then the December 23rd one again, I think people's vacation schedules might, might be such that it would be very difficult for us to have an effective meeting. So my proposal is we meet December 9th and then we go back to normal January 6th. And Michelle isn't here, but she said that sounded good. And I'm just curious what everyone else thinks. That makes sense. I'm just wondering if next week, KubeCon week, if we also, because I saw usually six canceled their meetings during KubeCon because everyone's so busy with KubeCon. Right. But we do have, we do have these topics. So exactly, exactly. So maybe if anyone, like, are there any objections regarding the canceling 25th and canceling 23rd December? And essentially, we have then more or less one more meeting this year and then back to normal January 6th, right? That's the bottom line. Correct? Sounds good to me. I mean, anything that is pressing can be handled via Slack and channels. Sure. Slack, GitHub issues, everything goes on, just the bi-weekly meetings as suggested by hybrid. Okay, then let's record that 25th is canceled, 23rd is canceled, which means we have one more meeting in 2020. That's more than enough for 2020. 2020 doesn't deserve that much anyways. Wasn't that good? Cool. Then we get to this. Good news regarding next week. Yeah. Yeah. Good news. What Brigitte has written here is accurate, which is to say, I think, yeah, it's about a 45 minute long slot on toward the evening on this coming Tuesday for, well, SMI, you know, all things SMI, I guess. So everyone here is welcome to come and either answer questions or ask questions. We'll see who all shows up. So it would be a zoom that we would join of the ones that I've hosted like this in the past. It has been helpful to generate conversation, to just to have a slide or two or four or a deck in the background that when people don't know what questions they have, you sort of bring up a slide, talk about something that's new or that's going on and that generates more questions. And so I guess the thing here is those that are interested in inserting a slide into a deck, I guess I didn't realize I was signing up for this until we, this just happened, which is, hey, I'll go put up a, I'll go grab a, I'll go put up a couple of slides and put out the link here, invite folks to, yeah. I think my words are failing me today, but you know where I'm going with this. So it would be good to, yeah, you know, just the general, just the stump speech, so to speak slides. Also, if that we've got relatively new things coming up or things like nginx service mesh being sort of yet another, you know, compatible implementation. And just in terms of the logistics, so all that people need is this cat.cofmyb, there is no registration or whatever, just go there and from there they get onto the There was, it was, it only took so many people's names. I filled in as many maintainers names as would fit on the form. And so for the, when you know, imagine I'm tweeting out, hey, you know, if you're interested in SMI come and join, what URL would I use? Would I use that Yeah. That's correct. At that URL, there's a pre-published Zoom link. So I don't know that entirely how that works if people actually have to register for KubeCon to be able to get into it, but, but there's a CNCF is handling it, but at least last time it didn't gate through the intrado system. So I really doubt it's going to have anything to do with KubeCon registration. It didn't last time. They added a little bit more structure around it this time, but I clicked on it, but I'm logged in there and I see, you know, join the service interface office hours here and then there's a Zoom webinar link there. I'm logging out now. Let's see if that's still the same. Okay, I need to try again, but it looks good to me. Yes. So even if you're logged out, can confirm. So we can simply use that to promote it, probably beginning of next week. Otherwise people forget about it anyways. Cool. Sounds good. That's definitely something hopefully a lot of people will see and come. Anything else regarding this? I'll put a link to the deck probably. I'll go grab a couple of things. Locky and others have certainly got a lot of good fodder out there for it and I'll ask for feedback and massive editorial review, I guess. It didn't have to be much. It really isn't the presentation. It's more just like, hey, did you know, when nobody has a question, it's just great. All right. So thanks a lot again, Lee. That was really super helpful that you took care of that and hopefully a lot from our end and also the outside will join and we'll have good conversations there. And I believe it will be recorded, right? So people get a chance to. Yeah, I think so. My assumption is as good as yours that they're all recorded and part of... They ran them like office hours last time and I don't think I published them, so your mileage may vary. I don't think they published the office hours last year or last Kube come. I just imagined that for me, for example, that's 10 p.m. that's still okay, but if you're Central Europe or more Eastern or I don't know for Asia, it might just be too late. So people might just want to watch the recording, right? That's why I'm wondering. Cool. Then thanks a lot again and let's move on to the next one. Richard, you put that down, but that's... I did and I saw John joined. I know Michelle wasn't able to join this call today, but John, I see Michelle extended it for one more week seeking feedback. Is there anything people should know if they're going to fill that form out to offer SMI metrics feedback? I think the doc does have a pretty good description of what we're looking at for that. So I would just take a look at the doc. Sorry, I didn't mean to interfere with your describing there because now that actually makes sense to handle it here. I don't know if you had a chance in that context, the open telemetry issue 199. So we got someone from the open telemetry community just in there commenting on it, offering. So if you click on that 199, you see commented on that. I had a conversation with them over on Gitter. They're still using Gitter and I guess they're moving to Slack as well at some point in time. So I would think that as soon as we have wrapped up the previous one that the Google doc John shared, we might be able to get back, either invite Justin for a conversation or share that Google doc for them saying, okay, this is where we are. At least that was my thinking there. That's great. That makes a lot of sense. So I really appreciate that they were really super open-minded. So okay, what do you need, right? What kind of semantic conventions or whatever. And then we probably just need to communicate. You know, here would be our proposal. There are a few there, but overall the metrics are still in hotel are still relatively moving targets. I believe it's like Q1 2020, one where the GA is planned. So we're still good, even with our timeline here. Question, Michael, in your mind, is this more about compatible semantics and conventions or is this also inclusive of potential? Because the word instrumentation is mentioned in there. So there are two parts, right? I would say the semantics are the easier ones. This is essentially something where as long as we find a consensus and say we consider ABC as the things that we want to do or expose or capture. The rest, there is still this on the wire, what happens with open metrics, will metrics be adopted by hotel metrics as the wire format, et cetera, et cetera. Where I think we, from the SMI perspective, we might have an opinion on that or an input, but we don't really own that, right? I guess it's more like, what is the, like working backwards from what would be the idle situation. Someone using hotel as the standard is able to instrument an SMI compliant mesh and gets out everything compliant to the standard. That would be the idle case, right? And semantics to me are the kind of like low hanging fruits, right? That's something that doesn't cost a lot, right? Everyone is like fine. It's just a convention. And the rest is essentially up to everyone to implement then, right? If you're buying into that, if you're saying like, yes, I'm going to write an exporter, I'm going to write something in the SDK, whatever in hotel, then that's up to you. But I think that's what we, I think, for our SMI implementers or people who actually provide SMI compliant meshes, want to provide us a guidance or give us a guidance, I guess. At least that's the way I see. I'm not sure if everyone agrees with that. It's helpful to, well, thank you for thinking about that out loud. And I'll press with another question about where you can do the same thing, which is in your mind, would this be, do you consider that this might be additive? The, like an additive to the existing metric spec in which it's optional for service mesh implementations that are compatible with that SMI, sort of choose between open telemetry compatible metrics versus the metrics that are there today or the formatting of what's there today? That's a great question. I'm unsure, but I would say that open telemetry, given that it's, you know, it's an emerging standard. And so far, essentially, the only part that is going to A by end of year is traces, right? Both metrics and logs are kind of like still work in progress coming next year. I do believe that, you know, looking at different specifications or future standards within CNCF, it would make a lot of sense if, you know, we support each other, right? Like, unless there's a really good reason, why should we not? But I also see that kind of like backwards competitive compatibility, that might be an issue, right? So I don't really have a strong opinion that other than I would wish everyone going forward would simply commit to OTEL and say like, oh, we're going to implement that standard. But I think we can only give a recommendation dancing, like, if you decide to adopt OTEL in your implementation, then here is, you know, for example, the semantics that we suggest to use rather than coming up with your own. I don't think that we can, like, make that a requirement or force anyone, I guess. One thing that'll be informative in this, in that thinking is understanding how many of the implement, the service mesh implementations today are in fact compatible with SMI metrics that conform to their spec. And so, yeah, so Do you think we should take an action item to research that, to have a closer look at that? Or what's your? I do, well, yeah, well, or yes, and I was sort of saying at tongue in cheek with respect to the SMI conformance effort to go over and verify that like, oh yeah, that might help. I think that would be super useful if you could, I don't know if it extends your scope or if you see that anyways there, but that would be awesome. Absolutely. I think that would be super useful for everyone. Or just yeah, informative toward like, hey, is backwards compatibility really, or how big of an issue is it? Does how compatible are meshes today? Exactly. And that's, you know, sorry, go ahead. Oh, so I, sorry, I would say that we have some freedom here being alpha, here's a moving target. There is a real nice story to tell to align with open telemetry. And I think you're going to find some freedom here, because I think a lot of data planes are going to be decoupled from the presentations of SMI metrics versus open telemetry anyway. So to, I think this is more of a presentation problem rather than any like data sync or data sourcing problem. So we should have some freedom to move between either implementation or many data planes probably have the freedom to move between any implementation. So I shouldn't see a saying it's mutually exclusive, but I should, I would like to see a should to say collapse on open telemetry. And I agree. And if I could also ask you to comment on that issue one, nine, and in addition to the Google Docs that's mentioned there, to the SMI metrics, essentially sharing where you are, your work, where you're thinking there is given, given where you are. Which is it? The issue is one nine to nine on our side. I think the tracking is differently in open metrics. But if you comment there, Justin, from their end is the liaison, and I'm trying to facilitate things from our end. And I'm not sure I think he's from light step. Not entirely sure. But yeah, this and the Google Docs that's in the previous agenda item that John pointed out the Google Docs around SMI metrics feedback. Cool. So we have seven minutes left. And I will shut up now other than moderating and handing over to Lee for the SMI conformance work stream. So last time we met, we touched on the topic of SMI conformance, which is an effort to verify that a given implementation adheres to the specs, to the SMI specs. And there's kind of a lot in there. It's a fairly well advanced effort that is functional and perform some tests. It needs to perform probably or let me step back and say, so there's a lot to discuss. Last time we left, Michelle had suggested that we, you know, that we call a meeting. And I think probably her expect that we call like a recurring work stream to kind of advance the discussions and give some dedicated time to it. And for my part, I thought that I would have done that by now. I thought we would have already had that meeting. Since it hasn't happened yet. And there's a few things that are happening within the service mesh working group. I was trying to find a spot on the CNCF calendar to host that call or that discussion and thought and thought of leveraging the service mesh working group to help advance it. So two questions. The SMI metrics discussion that was held two, three weeks ago, was that, how was that scheduled? Was that done? It was in this time slot, but just on an off week. Oh, I see. Got it. Okay. That might actually work. Yeah, okay. Do you want to do it every other week? I mean, if this isn't a one-time meeting, I'm just trying to be clear about what you're going to do. You're right. It won't be for a couple of reasons. One is assuming that, you know, a healthy number of the implementers actually participate. It'll take each implementer or each service mesh a little bit of time to, yeah, the short answer is, yeah, we need to meet a few times as every other. Well, I put a note on about your proposed time just because Friday, 1pm central, 11am Pacific is definitely night time on a Friday in Europe. And I guess I'll ask Michael to kind of speak to and Stefan to speak to how useful that time slot is for them. But that's kind of my concern about Fridays. Yeah. I mean, for me, it would still kind of work for Stefan. It's like two hours ahead of me. So that's even later. Maybe not the best time. Yeah. I don't think it will work for me on Fridays. The every other Wednesday, like this same time slot, except for next week with QCon. And actually, I would. Okay. So you want to just put that on the SMI calendar as the conformance working group? Yeah. And you want to start it the December, whatever it would be? The first one, I guess, would be December 2nd. Is that what you would prefer? Well, no, because that's another like, it's unfortunate that like I wanted the initiative to be done this year to be over with it. So I guess I should ask, since we have three minutes and we've got so meeting this week is anybody available to meet tomorrow? It doesn't necessarily need to be everybody. But so not next week. That means the following week, we're going to have this meeting. So the following week, we're going to have us Thanksgiving. We already decided we're not going to have this meeting. So if you want to hold a different meeting on the 25th of November, I'm not going to stab you, but I'm also not going to come to it. We don't do Thanksgiving here in Europe. I would certainly be up for it if you want to. Who else? Awesome. So if Michael, do you want to run a meeting in this time slot? Just run the meeting on Wednesday the 25th? We don't need any specific things for the kicking off the scene. That just works on its own, right? We don't need some magic moderator access or whatever. Do you have, I can sync with you after this and make sure you have the the mod code. And that's penciled in. All right. Perfect. Thanks a lot. And we still have two minutes to bike shed over who's going to moderate and or take notes on December 9th. I see Matthew raising his hand. I feel you knew to moderate. I can do the notes. Awesome. Please give me the Google doc enabled email address that you just sent it to me so that I can add it so that you can take the notes. Cool. Can I just send you that? Yeah. Damn it to me on here. And we have a mod. Stefan, you want to moderate on December 9th? Sorry. I don't know if I will be able to make it. All right. Then I guess it'll be me. Yeah. And Michael, you're in charge on the 25th. Oh, yeah. Cool. Thanks a lot, everyone. See you. Thank you. Bye. Bye. Cheers. Thanks. Bye.