 Okay, welcome to the SMI community meeting for October 28th, 2020, dropping a link to the notes so that you can take a look and follow along. And we'll get started with, we have a number of items from Michelle who'll be joining us shortly. And we have a Dhruv. I don't know how to say your name. Can you pronounce that for me? That is Dhruv. Yes, we pronounce it correctly. Wonderful. Dhruv, since you have an item on the list and are here, you want to tell us what you've got? Yeah, sure. Can I share my screen? Do you need to or? Oh, it's set to allow share screen, but yeah, if you're going to show something five minutes or less, this isn't a time for giant demos, we just I will wait a bit. Okay. All right. Let's see. I'm just going to go to the first item that Michelle had on the list. She wants to talk about releasing a new version of the spec and get updates to TCP route and the addition of UDP route. There is a diff that she dropped in the notes. And I will put that in the Zoom chat as well. Does anyone have any thoughts on that? We have our newest spec maintainers by the way on the call Turin Michael. Welcome. Thank you. So yeah, what are what are your thoughts? I'll put you on the spot Michael and say what are your thoughts on releasing a new version of the spec with updates for TCP route and the addition of UDP route. Yeah, as I mentioned, it's like I'm fully supportive. I think we should definitely make sure that the whatever the last pending open issues are can set itself a goal, I don't know next week or whatever, or next time when we meet that we get that out of the door. That sounds reasonable. We'll we'll revisit this if Michelle is able to join us. But meanwhile, interesting question around this PR around traffic target needs an LGTM. So that's important to look at. But do we want to make sure we don't have to core maintainers from the same company changing the spec? What do people think of that? Yeah, I guess if it's not, if it's not yet in the charter or whatever we should definitely say it should have support from two different companies. I think that makes a lot of sense. Yeah, that just seems reasonable. We actually have that role already for blog posts. So, you know, two people from the same org can't just put their own blog post in without getting a buy in from the community. Oh, how many or I was not able to be at the SMI metrics call last week. But I did see that there's a Google doc asking for feedback on it. Did anyone who went to that meeting have something they want to tell us about it. I do. I put it at the very bottom of the agenda, but I don't want to monopolize it. Let's get to that. Oh, excellent. And we have Michelle. Yeah, and to bring Michelle up to date, we all think that a new version of the spec sounds great and people should comment on it. Yeah, we like the idea of more than one org LGTM being changed to the spec. Is there anything else about like releasing the new version or approval from multiple orgs or multiple implementations that you want to highlight for us Michelle. Yeah, okay, so like we have like, I think it's a to LGTM policy. I don't know that it's like really stated in our governance doc, but it is like basically applied because of our PR gate like the branch protection roles that we have. So, so that's there and I it's great that we don't want like the same person from or the same, excuse me people from the same organization to LGTM it, but it's too enough. Like at this point we have several implementations and I'm just wondering, like, not everybody has time to like, like, you know, attend the meetings and they should but like, you know, life happens. So should we be some other specs like this is how it's done there some other specs I've chosen to kind of like they have like a person that's a core maintainer, and that person or set of people kind of goes around to the implementations and has the implementer review that spec change. I don't know if we're kind of like there yet just because like, I just want to make sure I think we're at the point where people are implementing and if we merge something that significantly break I mean that's the whole point of versions and stuff to you could argue but yeah, does that make sense. Basically should we go around and garner feedback from different implementations regardless of what the LGTM policy is. It seems like a good idea but then do we make a canonical list of the people who get weigh in on specific spec changes or like what's, you know, yeah. How do we implement that. Do we have like a lazy consensus with a certain amount of period of time and just say like, unless you object within two weeks or within a month. This is going to happen maybe over two meetings. I think that's okay. I'm sorry for the lazy consensus we just need to make sure that you know if it's just one channel like if we say only slack or whatever then you know people who might only I don't know look at mailing list or whatever might or some people might not look at I don't think we have like a plus one is that I don't think we have like a mailing list specifically with implementations. People with the Google Docs to the meeting notes so we need to make sure that you know everyone has a fair chance to actually react and really given that we meet every two weeks. I don't think we have like a plus one is that I don't think we have like a mailing list specifically with implementations people who have implemented, but I wonder if like that is a better way of going or lazy consensus plus maybe sending out an announcement on this mailing list is a good way to announce like hey there's a change and you should review it if you are implementing SMI. Otherwise it's going to break and it's a two week time period good for having people review spec changes. But we want two weeks or do we want to cover the period of at least two meetings, just kind of a technical difficulty or technical decision but like, if it's kind of a two week period but one meeting right in the middle and you know what I'm saying, like inclusive of two meetings, for sure. A meeting might be postponed for a week for whatever reason so yeah I think two meetings makes more sense. So should it be on every PR that's a spec change or just like right before a spec release. You mean in order to merge a PR that has a spec change. Yeah. The spec is structured in a way that you know there's like working documents, so working documents can go back and forth. So it's okay I think for PRs to get merged as long as once it's merged and people are looking at it that they, you know realize hey, maybe this doesn't work for our implementation and they could be you know have the opportunity to go back and re-review and say hey look I'd like this reverted. Yeah, and then so then the question is should there be a kind of a not a two week but a two meeting requirement on changes in a final spec. I think it sounds like we're kind of congealing on that and then the second question is, while that doesn't apply to working doc changes, does that potentially apply to you know I guess maybe I should clarify like I assume that that of the release process that we have right now there's a difference between merging a change into, I guess there's not based on your based on your facial expression there's a difference between merging into the master branch so to speak like not in the working doc but in the spec itself that we're that merging into the spec itself that's one and the same of making that version to release, like, like the act of merging into the spec is in fact the release of that spec. I was just I was thinking hey there might be a difference like if they're if we're if a release isn't going to maybe walk us through what this back release process looks like and then I think that would help us this conversation. Okay, one second I want one to mention we can use here branches and I think it will do exactly what you want. Like if we have a working branch or a preview branch everything gets PRed against that branch and that branch is at the end, validated by two people and merged into master and from there, we do the release should that work. I think so I think the only reason we were not for branches was where was because people wanted historical context for all the like all the different apis but those live in directories so in this branch, like the apis with the different versions of the apis would live in their own directories right still. The preview branch will be a fork or fork a clone from master a copy of master right so we don't change the files in any way. Only the files with working that are in work only those are changing that branch. Make sense so we don't change anything but just the branch that we configure pull request to be opened against. Okay. I'm good with that. I really wish we get rid of the directories. It's just like people aren't going to need the one alpha one be one alpha two over time I think it's just the fact that we're like moving kind of quickly, but if we have branches for each release then it'll just be like we could have the directory for the API supported. The versions of the API supporting in those branches. I'm good with the branch branching release method, disregard everything else I said, turns like yes we will disregard thank you. Yeah, I also think the directories can be annoying at some point with all the versioning in there. I propose branches at the beginning but yes, there are other arguments then. So, um, so okay. We will have a mask master seems so outdated main branch, which is net right now called master we should have that conversation, but we just created the issue for it. Perfect. Thank you. Let's just call it main. So we'll have this main branch previously master branch, and, and then we'll have like a working branch, and the working branch that's where you merge your changes, and then a release basically means that will merge that branch into the main branch. Did I capture that correctly. Yes, but that happens through a pull request. Yeah. And that pull request needs to be approved. Yeah, that sounds good. Oh, and that's where. Okay. So for a fun for promoting something that's in work to a final release, someone needs to approve that or to people from different companies need needs to approve a certain release. I wouldn't go even further and to say like, you know, X many implementations need to approve the actual release. But we can get there. We don't have to do that all in one day. So we need to define governance right in that perspective. We need to change the current governance to make room for oversteering committee or something like that. So who wants to write up the doc around who wants to modify the governance doc and then who wants to define or release process in an MD file. I think I can describe the release and work from there. If you want to, if you want to team up on it, I mean, it makes more sense if someone like yourself does it who has a lot of experience with it because I, you know, you have pretty much in your head. But I'm more than happy to team up with you on that and to, you know, Awesome. Steering seat. Thank you. All right, there's really loud construction in my building and I could not hear who Michael was talking to, who he was saying there's Stefan Stefan. Great. Stefan wasn't told. No, he was actually volunteering to do it. And I said, I'm helping him. But I'm not doing the governance change. It looks like the volunteer for that one, right. Yeah. And Michelle, I want an answer to the other question we were talking about active. I think it was the word and describing that. My answer was, I want to, or I want to engage there. And maybe I should because it'll be helpful in a couple of other projects. Oh, um, but yeah. Is that about active for maintainers. Yeah, just like what what it means to be. Yeah. We don't have to, we don't have to recap. I just left a question you'd asked on responding to and so that wasn't out of enthusiasm or lack of enthusiasm. It was lack of time. Yeah, I get that. Let's carry that conversation on slack. Should I just take the next bullet. Okay, cool. Go ahead. So the next thing is real quick. We had a meeting on around specifically SMI metrics last week. And just to see the conversation we had John from the OSM team, basically talk through how he implemented SMI metrics for the project. And so that was a good conversation. Good learnings there if you want to see the recording it's posted. One of the action items that came out of that was that we wanted to get like broader feedback on SMI metrics so I created a Google doc. So if you have implemented SMI metrics, looking at you Theron, please leave feedback, or if you have like, just thoughts on on on that thing on on that kind of stuff please please leave feedback if you try to implement SMI metrics and weren't able to if you got confused if you think it should be something different. All of that raw feedback is welcome on the dock. I'm going to review that doc after the doc is closed it'll be open for two weeks. I'll review it try to condense the information and then present it back to the community on one of these calls. Going down the next next item is some one of one of the pieces of feedback we got from that meeting was that there are some questions that get answered about the spec in the issue queue and those don't make it back to the actual spec. So we just as people in the community need to be like aware of that so if you've asked a question you've gotten an answer, you know your contribution to the spec based on what clarity you got would be more than welcome. Also, if you're answering that question, please go ahead and like, create a pull request and make that clarification in the text as well so people don't get confused a second or third time. If somebody wants to do like a review of that kind of stuff like if you want to review the closed pull request or excuse me if you want to review the closed issues and the discussion items I'm sure there's going to be a lot of just like random things that would be great to add to the spec so that's like an open item or task I don't have the bandwidth this week to tackle that but if anybody else has some time, you know that those kinds of contributions would be more welcome. So another question that I had here was that should we do a release of the SMM metrics with the current state of the spec because the spec, the spec differs from the current latest release right I mean the spec changed but but there wasn't a release so should we do a release and then take feedback or take feedback incorporated and then. That's a good question. I mean, how, how much effort is cutting a release like would you have to do a bunch of updates to SMM metrics. You're talking about like the actual project right. Yeah. So from what I see, like from other projects SMM metrics differs a bit right because the types are not needed essentially it's the it's implemented that should return the API, like whatever the defined API is. I'll try to see if the types are similar with that of the documentation if it is not I'll update the types and then and then cut it is probably based on that. So with aren't there some things in the SDK repo that needs to be updated to that would be considered bugs because they're not like they don't match the spec. So my intention was to update the SDK repo but the implementation would still be not updated obviously and then we can take from there right. Yeah, then you can have a release and the implementation implement it. Cool. Okay. So would you update it to match what is the current version of what is the latest released version of the metrics bit of the spec. In SMM metrics, the thing here is that we don't have a spec from what I see. It's still even alpha one like it's the same and that's where implementers did, but the spec changed and we did not update the type so I'll do that. Yeah. Okay, but the thing is the spec like the latest release, like in. Let me go to the V05.os. So we released metrics seven months ago in the SDK. Yeah, the type should be updated then. So right now we're at V1 alpha to working doc of this of the SMI metrics spec. And the like the latest released version of SMI metrics in V0.5.0 of the spec is V1 alpha one for the metrics on it. So I think everything should match V1 alpha one. And then when we cut this release, then we'll cut V1 alpha two of the metrics and we should update the SDK and the implementation based off that. We're on the same page. So my takeaway is that I'll update the types and then cut a release of the of the spec essentially with the types, then the implementations will obviously will have to follow the other thing that was that there is a slight difference in the versions even in SMI metrics right there are releases in the repo that is the implementation side of stuff and then the spec is different there so I think we should have some documentation on how it differs. That sounds good. When you say cut a cut a release of the spec. So, so like, we cut a release of the whole spec every time any part of the spec changes. So if you wanted to cut a release of V1 alpha two of the traffic metrics API then it would be then you'd have to cut V0.6.0 of the actual like whole spec. Okay. So I'll raise an issue probably to discuss more on that first. I'll try to see the SMI metrics side of things then I'll follow up on what we should do on the SMI specs. Okay, that's good. Thanks. I think that the synchronization of a new release should come from so we do a release on the spec itself, but that doesn't change anything. Right. People should use all our CRDs. So those CRDs are not yet released. We have to implement the SDK for the change and publish the new CRDs and then when we publish the SDK that's the final release of our spec. And then we can update our own components like the metrics provider, Istio, and others. That's how the release should work right. We're on the same page. I mean, that's now. That's how we do it now. So I think we should announce a release after we also implement all changes in the SDK. Oh, okay. That's nice and nuanced. You can note that in your release doc. Yes. Okay, cool. All right. Next. Okay. So can I share my screen? Yeah. We have two minutes left in this meeting. So I think I think it's not going to be a long thing. Okay, sure. I will make it quick. So Leafa is working to, we were working on running some test which scientists like the conformance of that. So we have a working demo of it and machines. I ran a test while the meeting was on to see and how it tastes and runs and currently the test which we have defined are over here. We have defined it for three particular space. This are like infant test cases which we have defined. We need to work on that. So we wanted to call for volunteers who could give their input and tell us if certain kind of tastes they want to invoke for the support that you are creating on the SMI place. Yeah. Very cool. Can you link to that, Rupa? Yeah, sure. One second. So, I will go to the slide and give you notice that we are also tracking the same on a documentation in which we've been listing down all the tests that we are planning on and the test cases. So that's another phase that we can. So here are the test sets which we are proposing on and I don't think no implemented or some of them are implemented yet. And you would like to input on the test set you want to include in this. So another component to that added this and some of you have seen this and commented on the tests within here. And we've made call for participation in defining and refining and defining these tests. So we're still looking for that. The demonstration that Drew was just showing is that of OSM and it running through a few different tests and whether or not and what the results of those are. I wouldn't read too much into the results because there's only so many tests to find we want to make sure that we're, you know, that each implementation is reviewing these. And so there's kind of a call for three things one is review of tests and the addition of tests. Two is, we've talked in the past about conformance or compliance versus capability, acknowledging that not all implementations and tend to fully implement all specs. So there's an open question about the philosophy of whether or not a given mesh should be considered out of compliance if it never intends to be fully capable. It's a good discussion for that doc. And then the last call here is for a service mesh maintainer to, well, to to engage and to begin refining their their test cases because we'll we want to work toward a composite report that those those teams that have some time. Don't everyone jump in at once. Because we did the crew here couldn't take it but but anyone who'd like to get there there make sure that they're the mesh that they represent as well, you know, well represented in terms of conformance. How's your, how's your chance. Sounds good this is all really cool work I know we're over but is there a dedicated meeting for the conformance related stuff I feel like it always gets kind of thrown in as a stand up thing and I don't know if like everybody's going to go and like, you know, rush to write test cases. So, I thought that's like it not an exciting thing to do is just, you know, when you're juggling a bunch of stuff it's hard to make time for that but it's important. So we should. So I think if there was a forcing factor of like getting people together in a meeting and saying you need to have read this doc and we're going to go through this doc and like we're going to answer questions together. It might be a little more helpful for me, but maybe I'm alone here I don't know, but I want to focus on it I want to I want to help I want to, you know, write test cases and make sure that osm is compliant and stuff like that so we definitely have incentive but it would just be great to have some sort of forcing function. And also it's a little bit, it's a little bit to digest. Like, so let me get a good response to that because there is a response but I think the meeting that I would identify as also has other items on the agenda. And so, like we did an offshoot of traffic metrics. Excellent. That would be so great. Thank you. I was moderating, but I think somebody needs to tell us that we can go. Well, I think technically you're moderating but of course I. Yeah, I mean that's why I was like take us through our topics. But I think yes we are at our time we're over time. So I am going to bump those last couple of topics to the next meeting, and I will hassle people on slack for, you know, assignments. Michelle is smiling but honestly, Michelle you did a fantastic job because you were taking us through the exact topics we need to talk about. An intentional moderator. It was great. Thank you folks. Thank you.