 Ready? Okay. April 1st, joke. Okay, we are semi-mitting the agenda. Should I read the agenda or how do I do it? I would just say it's April 1st, 2020, and this is the SMI community call. And we are moderated today by Stefan, please introduce yourself and get us started. So I'm Stefan Prodan, I work for WeWorks, and I'm an SMI maintainer. On the agenda today, we have the talk about celebrate the CNCF membership. The versioning of the API, how we want to do that, to move forward. And yeah, we have a couple of more issues, a lot of issues actually here, governance. And the project board, I think it's also a good topic to have. Amy, you want to go first on the CNCF membership and what that implies. Welcome, you're here. You're a sandbox project. It's good to see all of you. Hooray. We've got a bunch of other items here. So as a sandbox project, we don't get much, right? Part of that actually means that you have a neutral space to be able to grow in towards being whatever it is that you want to hear. We're here to help. We're here to be able to make sure that you get what you need to be able to be successful in this. And I know there's a lot of other questions around like logistics and pieces further down, but we can get to those in the agenda, but welcome. Good to see you all. Thank you. We want to talk about the versioning thing, Richard. Yes, I noticed, Stefan, that you commented on that. And I know that it's a ticket that Michelle had opened in the spec repo issue 88. And it says that you mentioned consolidation of API resources under the same version, blah, blah, blah. And I just wanted to bring it up in terms of if we wanted the specification to have information about previous release versions, we should probably make a chart or something. I'm not sure. I mean, we're going to solve it on this call, but since you put that comment, I'm wondering if you wanted to kind of say more about what you think the next step is. I think that we have two approaches to this. I think we should at least now in the alpha stage, we should list all the API versions that we currently have. And I think it's also important to specify what implementation works with what version, for example, I don't think it is on alpha one, maybe others are on other versions and I think it's for someone that wants to integrate let's say through SMI with service mesh or other operators. You can really tell right now what works with what and what version works with what other version because we also have dependencies between the API objects. One proposal was to list all the all the versions consolidate them under alpha four or something like that. And every time we make a change we bump the version on all of them. In that way, people don't have to worry. Hey, I have, I don't know, HTTP routes alpha two does it work without a traffic split alpha two or alpha three, the answer is alpha three and so on. So, in terms of representing that in the in the repository, there are two propositions one will be to create directories for each version and copy the specifications and everything in there. And then another approach that I suggested would be to create branches for each version. When you say create branches, do you mean branches in GitHub. Yes, and so there'll be like all these long live branches that would diverge from each other. I have any concerns about because long live branches. Either way we could have like, you know, a compatibility matrix that we maintain either on the webpage or in a markdown file and GitHub, that people could look at at a glance and see if this is the current compatibility. I just worry that if we have a whole bunch of branches people will still need a chart. I, I only have one ask and that is a kind of weird sounding ask and this the negative example. I don't want to say that this is like in bad practice but if I look at client go, I always, although I wrote a book about it I always get confused, trying to figure out what actually abusing I'm sorry but so if we can keep it as simple as possible, do it once properly and keep the matrix as possible to not confuse people. That would be awesome. That's my only worry. So I think we can totally avoid the metrics compatibility metrics if we bump the version on each modification. If we are going to do 100 changes to the API in the following month will have view on alpha 100. Are we going to do so many modifications are we. I don't think SMI will have so many things inside. And maybe bumping the version every time it's the right solution. If we do what I think is really effective in the Kubernetes project, which is we define what a regular release would look like. And we, we make commitments to the release and if the releases are because the pace of change is not so rapid. We've always got the option of kind of being ahead of the release if you want but but I think if we can make an agreement and an agreement that we will always try to be on the release and let's say we do every two months on a release. Maybe, maybe that's the way. So this is a specification of the software. We cannot commit to a release every two months if you don't check the spec. I don't think the software release pattern applies to specification at all. Oh, I don't know. I mean I think I don't think you have to do a release but but I think there's definitely. I mean if we kind of backtrack there's there's definitely been there are definitely changes which are happening all I'm kind of really suggesting is that we we bundle changes into a, you know, we don't release before or something. So we have no release of the SMI spec as it is. I guess what Nick was alluding to was more or less this kind of, you know, breaking, breaking or not right way and say, up to this level we reserve the right to change something so you know, if you want to use it, feel free to but we do not make any guarantees that you will see it face up to better or whatever. And once it's ga we kind of commit and say we do not change the API anymore. And if we then do something changing it would definitely get a new API, like major tool or whatever. I think this at least that was how I interpreted Nick. I'm going to say quick time check since we're going to try a condensed version of this meeting we're trying that today and we'll see how that goes. But since we've allocated a third of our time so far and we've talked about this item. I'm going to point people to the issue because I think that there's a lot of detail we could dive into here so people who have opinions about this. That's the issue to go and hopefully by the next meeting everyone will put their comments on the issue so that's unreasonable. Should we talk about the governance documentation. So we have a government governance doc right now. That states that maintainer will be removed after three months. If he's not active. If he's not active means. I'm guessing it's not only about writing some new spec it's also about responding on issues. And all the stuff so do you want to discuss that. Also adding removing projects. What's yeah we don't have, we don't have nothing around it. We don't have a mechanism also to voluntarily do that. I have seen that for for the ambassador program where you can essentially say like yeah you know I've changed focus or whatever it's like, you know, I'm not going to wait for these three months. I'm out of here. So yeah maintainers must remain active, if they are unresponsive for more than three months, they are automatically removed. So maintainer may step down by submitting an issue starting their intent. Okay. Yeah I think the only thing in there Stefan is maybe what active means, and specific with the cleanup I did I did actually reach out to everybody and they specifically said I guess I could have had them comment on an issue. I reached them by a slack. But I did ask Suraj, you know, are you willing and he said no please put me in emeritus. So but yeah, I mean we could say what what defines active. Have you been to a meeting have you contributed have you open an issue. We could we could just say what does active mean is that really the crux of what we need to define here. I don't want to make things too complicated but I think we should take it a step further and say hey this is what document specifically what a maintainers responsibilities are. And then the definition of active will be more clear in that, you know, they have not been doing their duties for X amount of time, and a number of responsibilities might be helping with issue triage attending meetings, resolving issues submitting Let me let me just go look for prior art in the CNCF I'm sure somebody's documented this and I'll put an issue together. And if the verb edge looks similar to what we agree on then we can just bring it over. I guess we that sounds like a great idea, lucky, but I really want to make sure that we don't have too much process on the one hand. On the other hand, like, it's a bit like a prenup right you. As long as everything is good you don't need it right. You exactly need it if if something goes right. And then it's like you know, what if like you know I've been, I don't know. I still want to but they're just after three months immediately get kicked out or do I have a wage appeal and like you know we, if we do it properly you know listing all the responsibilities then you know, what does it mean after two months you get a warning, you have a chance to you know pick it up again or like, how does it actually play out all the way through otherwise it's like, we just deferred to the first time word happens and making up these rules when it happens is almost never a good idea. Okay, so it sounds like we're putting together an issue and people can take a look at that. Okay, let's move forward about the renaming of the SMI adapter for Istio, do you want to rename it into Istio operator or what was the second? Yeah, I put that one on the agenda because it was kind of an old issue but since we were in the middle of removing or rearranging all the GitHub repos I was like, interesting. That's, do we need to do this? I think Michelle you were in that mix. I'm not. If you have any repulsion about renaming it anyway anymore I think the term adapter is used in the Istio community and so that's why it was named adapter and that's fine. Let's, I don't really care to run that said script right now, but is anybody else passionate about it? I really like the adapter naming makes sense. It's also in the SMI read me right now the main read me where we list the environments we say hey Istio think it's an adapter and console, the console connect thing it's also through an adapter. Can we close the contenders for name? Were there any other suggestions? I don't have the issue up. Operator. It's fine. I would be fine word. Yeah. My vote is governor. Istio governor. We're going to confuse everyone. I can't. Naming is so hard. Do we have any representatives from Istio in SMI on spec yet? Not that I know of. And we can totally troll them. We can call it the Istio. Mixer. If somebody, by the way, if somebody knows off topic, but if somebody knows the right person on Istio to reach out to to find out if they want their logo. That's them and console connect actually are looking at you Nick are the ones that have not signed off. You didn't sign off on the issue. You were like to care of it and I look at the issue and I'm like, it doesn't agree. So I'll drop a link in the chat. But yeah, so like, we don't want to use anyone's logo if they haven't said we can use it. So Istio, because members of this community wrote the adapter. By the way, if you are interested in working on the Istio adapter, please do because I've noticed in trying to get pull requests through there that we have a minimal amount of maintainers who focus in that particular repo. Yeah, Michelle. I haven't really been super active on it lately, but I am but it's just, I'm trying to update the metrics piece of it. So not the adapter. I haven't gone issue with contributing to this adapter since he's using the, it's using the OpenShifter SDK, right? It's using what? Sorry, I didn't hear. OpenShifter SDK? Oh. Yeah, it is. Yeah. Why specifically? I don't know. Is it just because it's hard? It's over complicating everything, like. Okay. Yeah, it needs a lot of updates, right? It doesn't use Go modules. Yeah. Do you want to like throw up any issues, Stefano, I would be happy to take a look at them. I'm going to have some more time for that. Yeah, I think the, what it does is fairly simple. So cube builders should work just fine without using all these frameworks. I think it's an overkill and complicates, makes the contribution harder. I think that's valid feedback and we should look into it. I think I inherited decisions and didn't really, I have like a lot of things to focus on. So don't really make those changes, but that's valid feedback. Yeah, I think when, when we build this, it was a cube builder wasn't where it is today. And now it's like the de facto way of building operators and it should be fairly easy to migrate. I don't know if we still use the project board or if we discuss that, but I think making it, making a priority for the AC adapter to be easier to contribute to is something that I'd like to prioritize for you to do. Yeah, anything that was not finished, I did move with the exception of a couple of things that I was thinking we'd be able to wrap up. But anyways, Stefano, go ahead. So do we want to archive the old slack? I guess so. Do we have to like, do we have some kind of need to keep the data from it? I don't really know what Nick you have ideas. Oh, you're waving because you're heading out. Okay. Yeah, I'm just apologizing. I just got a balance. Sorry. I'm not, it's not clear to me if anyone has anything in the old slide that they really, really want, but I feel like we should pick a time that we're going to either archive or delete and then let people, you know, decide to do what they want to do. Does anyone have any strong feelings about that was why I brought it up. No none here. My preference would be sooner rather than later. The only thing I want to keep is my statistics so that everyone knows I'm the most talkative person on earth, but I can't keep those forward to the CNCF one unfortunately. I'm for deleting all together. Okay, so we'll probably do that in like the next month. We already set them general channel to read only so. I've just noticed there's like 395 people in that slack. I guess some of them are already in the CNCF slack but they aren't in our channel so maybe go out and reach out to the people you think want to be in our channel. Next, and the last thing, talk about the project board. Yes, so basically anything that's on the Q one project board still if you want to go click on and write things on it if you care about those. I'm going to try to get those ones resolved or moved. And if you think things should be on the project board for Q2, we haven't put a ton of formality into what goes on a project board versus just the main thing that I did was I moved all the stuff from the SMI spec project board now that we have an organization we can have an organization on our project board and you can add cards from any of the repos. So, that is like open to people's ideas of how they want to organize it. I don't really want to be happy handed with it I just want to make sure that anything that we care about we are moving forward on. So, maybe that's a discussion topic, you know, what we want to move forward on specifically, like in Q2 could be a discussion meeting if people want everybody wants to take as a homework assignment from this meeting. Go think about what you have open that you care about. We did skip by the way there were a bunch of open pull requests and we did skip the discussion of it and I don't think that person showed up to this meeting, but if they did, and they are just under a different name. The pull request to add support for routes is actually something that I was not positive. I saw that Stefan maybe you can address that because you did the most review of that code but is that something that changes the spec significantly at the point where because it looked like he was adding some things. Anyway, yeah, maybe if you want to address that Stefan. Yeah, I was waiting for Thomas feedback on that request. I saw a pull request from that guy on this topic on almost every repo. Like, it looks like he's really trying to dive in and get this specific thing done and so I was like, someone to care. Yeah, it's a, it's a push from linker D to consolidate the metrics on the SMI right to us. Yeah, to give a background. I'm trying to get everything in linker D multi tenant SMI metrics would give us all of the read multi tendency so you just have Kubernetes are back. But a lot of it was missing and so Alex has been working at updating the spec to support all the existing like your D functionality routes is the biggest change there. There's not anything necessarily to the spec it's mostly just additive, but it's definitely something that we should be comfortable about moving forward on. This is going to involve more documentation updates to then or what's your approach there. Definitely needs. I think some of the one of the things that's come out of this is Alex has been frustrated in trying to figure out where to add things he's approaching it a bit from an engineering perspective, and so most of the PR is an information has gone into the spec. So I think an outstanding piece is updating the documentation inside the spec repo to go and give a feel for what use cases this is and what the responses are and how what we actually intend from a support perspective. It should block anything but it's definitely provides a discussion point which is, I think we should have a document written up that explains the checklist for how to propose a change to the SMI spec itself and what we expect to get out of it. Yeah, so, so the metrics changes got proposed in the SDK as a client go implementation or go line implementation for SMI. And afterwards we try to push Alex and say hey, this should be documented in a spec first then implemented in the SDK. And he's trying to do that right now I reviewed the changes in SDK and also the changes to the spec. In the current state, the pre-quest looks good to me I will prove it but we need another look at it for someone else and that's it we should move forward. There were a couple of things like the version wasn't bumped everywhere. It was only in the header, the examples were on the old version. And yeah, I missed some of those I realized later I asked Alex hey, please make all the changes like it should and then Alex realized okay but we also need the old version. And this is how we got to the versioning discussion like I managed to add all the old versions in the SDK so now whoever uses the SDK can use older versions as well. So it's easier to upgrade inside your own implementation from one version to another. But we also need the same approach in the spec because you look at the SDK case is V1 alpha one. What does this mean you look at the spec and you don't see it anymore so you have to look in the get history. So that's why I propose either a branch or let's make directories in there but we should have everything until I don't know beta one or something like that when you can archive the alpha versions. Okay, so if you want to look over the full request. So it sounds like Stefan and Thomas have the most context on this so if you two want to look through all of the pull request that this gentleman has put in and kind of help guide those first. What else do you have anything else. We did have, I did have an item in there about the meeting length. All right, we've now tried a condensed meeting. Do people prefer the hour long meeting or do they feel like we hit enough of the high points for discussion interactively in this one. Anyone have strong feelings when we're the other. I like to have an hour. We could discuss about versioning for hours. Yeah, that's a great sign. But just because if it's that important, it would be great for everyone to get a chance to read what you what you said. Yeah, I did my life is that can get up but there are like three issues now on versioning and we should make sure we link them together. So we don't lose one one side of the story on the other. Michael H moderating next time we need a volunteer to be short. Yes, shorter meeting is wonderful volunteer to be quick on the typing and the interpretation and the guidance. Next time. Do we have a, do we have a taker for that for the notes. I'm ready better typing but I'll do it with no one else. I'll beat you to it by 10 seconds to fun. You want to arm wrestle. Or Stefan can be assistant to the note taker, which is the very title we had last time. Hmm, wonderfully on time. Thank you, Michelle. All right. Bye everyone. Okay, so. Thank you. See everyone next time. April 15. Bye.