 Hey everyone, today is Wednesday, March 3rd, 2021. Welcome to the bi-weekly SMI community meeting. We have several really interesting agenda items today. The link to the agenda is paste it in chat, please add your name if you are an attendee. And feel free to add discussion items to the, to the discussion items list. And with that I'm just going to go ahead and kick it off. Well, an overview of the agenda actually first. We're going to talk about the generic SMI controller that Nick has been working on. There's also an update on the issue adapter on that. Bridget has a call to edit the SMI CNCF annual review so we'll talk about that. We also had an agenda item around, you know, how do we get our roadmap going. How do we deal with compatibility between integration so I'll help facilitate that conversation since she's not here today. There's a few other notes that she has. So I'm going to talk about the item around traffic split and clarifications around what a root service can be. And then Michael is going to lead us in the multi cluster discussion, and then I'm going to talk about the contributing guide for this fact. So we have a lot going on and I may apologies cut you off. We have a better discussion or a longer discussion offline about it or at the end of the meeting if you want to extend that so just to help us get through everything. Okay, with that, Nick you want to give us an update what's going on. All right, let me just find that button that makes my screen broadcastable to the interwebs, or can somebody enable screen sharing for me please. Yeah, I'm going to make you a co host, and we will see if that works. Okay, thanks. Yeah. Yes, there we go. Okay, awesome. Thank you. I'm going to caveat this with an apology because I about 30 seconds ago developed a migraine so I can't actually see out of my right eye at the moment until that disappears but we'll go through. So where I'm at with the SMI SDK, the kind of the things that I've been working on recently I haven't made many advancements in like things like adding additional specs to it because that's a known entity. The key thing that I'm interested in is, how do you test it, how do you develop it, how do people contribute to the SDK and ultimately does it work like is it is it possible to create something which is flexible enough. And I think the answer to all of that is, is yes. So the first thing around the repo what I've added to, to the repo is, is a while I updated the read me the other day there's, which has got some instructions on. It's very brief on how you can kind of create things but also instructions on building and developing locally and things like that. And I also added a bunch of functional tests. So now, not only are there unit tests, but there are functional tests which follow the, the sort of coop builder, ginkgo specification which I'm on the fence on I'd love to get people's comments on ginkgo tests. And also end to end tests which checks the controller SDK against a real Kubernetes cluster. So we've got, we've got all of that. It's working pretty good. I've been working on getting the development experience working pretty nice. So, I'm using a tool called shipyard which allows you to create a a Kubernetes cluster running inside a Docker so you can develop everything locally and install all of the bits and pieces in the helm chart and everything that you need. And as an added bonus what you can do is debug it because any of the web hook stuff is forwarded to your local machine so I'll give you a quick demo there. So I'm just running the controller controllers spinning up on my local machine connecting up to my Kubernetes server and Docker. And let's go ahead and apply a configuration here, which is the V2 Alpha traffic split example that I've got. So I've got some break points inside of the conversion code just so that you can see like the sort of the debugging approach of working with the SDK which which is totally relevant. Not just for the SDK but for the implementation perspective as well that was kind of like a clear game, hopefully. So I'm applying that K apply examples traffic split v2 you can see that the break point has been hit. So this is hit the Kubernetes API the Kubernetes API has called the web hook defined in the CRD which has been forwarded to the local instance on my, my computer here and I can step through this and do everything that you would, you would like to do around that so that side of things, I think is looking really good. We have, as I say, the sort of the tests. So everything's in the unit tests, sorry in the make file, you can build run functional tests run the unit tests. Yeah, everything's there and it's getting there. So, so that's, that's a kind of a quick update on on that I'm pretty, pretty happy where that's at it's pretty good now. I managed to put the, the health endpoints and the ready endpoints in which I will expose to people. I've been doing some work on the console as a side of things do the dog fooding, and that's been working really good. The next side of the dog food is I'm going to implement the some of the stuff around the the SDO adapter which which actually will be really, really easy to to implement because literally all you have to do is implement the methods that you are interested in. And just in case anybody's not seen that before. If I can find the right here's an example logging implementation. So, you don't have to worry about anything around the controller you don't need to worry about, like the, the sort of hierarchy that children objects don't exist the controller will deal with all of that. As a consumer, all you handle are the upsets and the delete events which you you receive and then you can execute whatever logic you need to do so it's, it's pretty rapid to be able to to use this. So that's, that's where I'm at is your next time I'll show you and Um, and just like kind of anybody who's not involved in the SDO adapter or, you know, is new or hasn't seen some of this just to kind of add some more color to this whole thing. I was really excited to get a code walkthrough from Nick. Him and I went through kind of like the pros and cons of updating the issue adopter as it is today versus like using this SMI controller SDK, and we kind of thought it was like really awesome to kind of just switch over and uses controller SDK it's essentially does what we needed to do so this SDK basically watches the SMI resources and allows us to kind of like implement whatever business logic we have on our end without having to deal with all the Setting up all the SMI configuration that we need to actually like watch all those resources and do something on them. And that's essentially what the issue controller is doing as well. So it's just or the issue adopter is doing as well as just it's watching SMI resources and then building like an SDO virtual service or whatever the SDO equivalent of, you know, that functionality is it's just building the resource for that so I'm super excited about conversion web hook because I'm hoping that that's really going to save people a lot of maintenance as the spec evolves because you can depend on a, on a base level and taking your advice Michelle I think you're right we should depend on like not v1 alpha because that's relative to be mature I think v1 alpha two or even three would probably be a better choice but it's, it doesn't matter too much. Yeah, I mean from an OSM perspective we're really excited about the conversion web hooks and we can actually go ahead and we're planning our next release cycle and stuff and we've kind of talked about how we want the upgrade story to be smoother in terms of SMI resources and stuff so we can definitely help out there too. Awesome. Yeah. The other, the other thing which I think just to add on that is that I did. I am using the v1 spec of the, the custom resource API is not the beta which the current go SDK is using and the rationale behind that is, I hope that where, you know, like I think that's API 16 or something where, where that was compatibility was introduced, you get so much better benefit around the validation side the fact that you can define like a custom validation for every version of the spec, and that might be another topic to table about whether we, we go and upgrade the, the existing go SDK and the CRDs that we've produced there and maybe start moving those to v1. That's a separate issue. Yes, we need to work on that. I'll take a note of that or Michael can take note of that that'd be great. All right, so let's move into actually want to give a minute does anybody have any other comments around the stuff that Nick is working on. Okay. Thank you Nick. Okay, so the next item we have is Bridget is putting out a last call to edit the SMI CNCF annual review. So if you gave a talk or did a blog post on SMI or saw something cool about SMI this is kind of our yearly report card to the TOC into the rest of the CNCF community around like things we've done and accomplishment accomplishments we've had so please throw that in there. But the next agenda item is around spec evolution plans. So getting APIs to beta and stable. We have had our API is kind of an alpha for a while implementations have implemented it. I'm kind of wondering. You know, we kind of need a roadmap we tried to do this before, but we need to have a plan for how to get our API is to beta and stable. Are there, are there parts of traffic split and traffic access and traffic metrics that we want to change and add features to or do we feel like it's in a good place and we can, you know, start moving into beta. And I guess we can still add features after, after it's, you know, be one or whatever it is we just kind of need to get it to some sort of a stable place where we know that conversion webhooks will work and we won't be changing fields all the time things like that. Nick, you want to talk about that. Well, all I wanted to make a suggestion is why don't. Well, okay, I'll make it as a suggestion. Would it make sense that maybe what we do is make a big push in the same way as when SMI was originally founded and we say look let's let's do a big push and add a bunch of features before a beta one because I'd love to see things like enterprise circuit breaking, you know connection level timeouts and things like that supported by the various spec elements, if that makes, if that makes sense because I think they're really important. Yeah, how do we like, it's nice that the APS have been in alpha because people can implement them and then kind of give us feedback on how it's going. And I have feature requests to like, should we add TCP route attributes to traffic splitting things like that. But do we want to like make a big push and get those features in before they've been implemented by people and then call that beta or do we want to get those features in and have them tested and have that be alpha and then move to beta or or is there a world in which we can just call what we have beta because, because it is pretty well tested in different environments and different implementations. And then can we add more features to those resources later. So, does anybody have any thoughts around that. Does anybody have any thoughts around compatibility for each integration I'm not entirely sure what that bullet point is I forgot to ask Bridget. Nick do you have a thought about that. No, I don't have, I don't have much, much thoughts I think that there's there's definitely a couple of bits and pieces that I'd love to see, love to see in this back and be more than happy to help push this forward but I think you got a really valid point that what we have right now works really well. And a lot of people have been using it so should it just be promoted and then we can always run another beta. If any, let's just open an issue on that and talk about a sink and then come back. I'll let Bridget lead that conversation next time. And we can maybe maybe I can work with Bridget on a proposal and we can push that through or not compatibility for integration I is that I want to maybe I'm just too close to a bit that is that SMI conformance was that like verifying conformance of an M and integrations compatibility with this back or is that you know I don't know but that's, that's a good point. Do you'll have an update by any chance on. Yeah, that's why I skipped the last couple of times is because it was. We were so close on like, basically a final like more or less we we was why I haven't joined is because last time we ended meeting with the engine X service mesh folks to help, because they had missed the initial kind of deep dive into that conformance and they're really interested and their gung ho to have their implementation verified, and the tool is able to do it. It, the problem is that their software to get access to service engine X service mesh, you have to sign in a EULA, which means that like, as the misery as the tool to pull down install files and deploy the service measures it becomes an issue for it just we got wrapped up in their corporate legal system. The, as a matter of fact so like a blog post is very much needed. The thing the results, the brief update is that the reason that the tool works you can go test different service measures conformance says we're ready for our first or the tools ready for its first real customer I guess, like the for the first, like the statistics are actually published on like I think four or five service measures on how what percentage compatible they are with the the current definitions of those tests. And it's like, it's like in the 40 percentage range for the tests that are there. And so it was. So I'll ask this, anybody want to sign up to be the first. And by the first I mean the goal is to empower the teams with the tool. So here's the tool run it at your leisure, run it in your CI pipeline or run it ad hoc when you want to whenever you want to do it by yourself, you're empowered to do it and then you're empowered to send your results in a verified way to the to a table. Can you, can you share a link to the tool so that everyone on the call and also for my notes that I have a link. So as well I'd be, I'd be happy to integrate that into the SDK pipeline as well, because I'd love to see that as a, I'm hoping that people are going to do things like copy pasta that like the build files for get of actions and stuff to make it So we added a stack to do the compatibility test, theoretically the reference implementation and the SDK which is like logging controller should be 100% compliant. So it would be, and I'd also like to integrate that on the console rework that I'm doing as well so I'd love to play with that and maybe we talk async. Nice. That's great. Michael, I'll drop in two links one to the one to the shit. I don't know what you the design spec for what the tests are, which actually needs some additional additional input there's a few tests there's tests that are there today. Did you say here in the chat or where do you I'll do both I'll do the chat and Google Doc. Wait, so many places where I could just to make sure thank you. I think I'm going to dig into the next SDO implementation and controller. So I would be happy to help with whatever needs to be done to make the SDO adapter also be one of the customers. Yeah, to be honest, let me digress for a second and say, between winter storms and pandemics and like, founding small companies. I am. Thank goodness you guys are coming to bear on it because I'm, I'm about done. And I'm going to go back to what you know Riley chapters do and things like that it's so good. Thanks for, thanks for letting me sit on your couch. Totally get that I totally feel you. Okay, so, going forward. I had a topic about traffic split route service which I'll briefly give you an overview of and then we can just have a one minute conversation and we can move on. In the traffic split part of the spec. There's like a paragraph and I have an issue that links to the paragraph but it just says that the root service should be an FQDN fully qualified domain name so that's cool. That makes sense because you want to be able to, you know, be able to have a client access food calm and then that service that traffic should be routed in whatever way the split has defined. And it says that later in the paragraph it says that, you know, the backup should be like, actually, there's there's some language around there that says something about that if, if the root services in there then the standard service configuration should work. And it's just like slightly confusing, because it sort of couples the root service to a kubernetes service. And I don't think that if you really think about it, that doesn't make sense because you should be able to, you know, go to food calm or bookstore bookstore namespace or whatever that is, you should be able to use either or. So it could be a kubernetes service, or it could not be a kubernetes service and I'm talking about the root service. So I would just love to add like maybe a sentence or two clarifying that there is not a coupling there, unless there's some background that I don't really know about. Okay, Nick is shaking his head and he's been here for a while so cool sounds good. So anyways that issue is there if y'all want to comment or anything. Any comments right now. It would be pretty, pretty standard. I'm going to skip the next. Oh, no, not the next okay the next thing is the multi cluster Federation call for feedback so Michael did you want to take that one. I, even that I'm scribing, I think I will let Nick do that. Otherwise, like I can't really talk and scribe. So you're okay with with doing that. Thanks. Drop me into the last. I'm with wasm and go earlier on this afternoon and yeah I'm less than impressed with the state of the compatibility, much to my own frustration anyway. I'll start look for this. Okay. So we've been talking about off and on about multi cluster for, well, it's for a while. So we never agreed as a group, whether we should take on multi clustering specifications, whether we should support something external or whatever so we. I started an issue, which I've just left to canvas sort of feedback on for the last sort of 13 days and ultimately it kind of just covers the fact that we're looking for help and. And I think the general consensus is that people want to see what multi clustering, which includes different mesh variants as well as different clouds and things like that and that was always the purpose of. Of what we were we were trying to achieve with that which is good. There's just some comments, few people have sort of spoke about these things. I think this is an interesting one and I didn't comment to this, because I do have a very specific sort of perspective that I don't. Well, my perspective that I don't think that we should enforce people to use a specific identity Federation when it comes to multi cluster discussions and my rationale behind that which I will add to to this is that I think that's an implementation detail and what the spec should actually do is talk about an identity conversion or something side of the specification. The example cited here is around spiffy which I think is a great format the problem with spiffy is it's a very loose format you know spiffy is is if it's a URI you're pretty much good to go but the problem with the URI you can compose it many different ways. I could use sort of dot notation so I could say, you know, cluster dot region dot application. I could use business unit dot region dot application, or I could use something like cluster slash business unit slash application so there's, you know there's a number of different ways that you can compose a spiffy ID. So essentially what you probably want to be able to do with multi clustering is be able to sort of trust a, you know, a broader thing than just a one to one mapping so I'd love some feedback and some comments on on that area about how we could deal with that. But you know that that's where it is. So within 13 days my plan is Friday, I will go back and answer some things on here but next steps. I think it would be nice that we could maybe you should have a little vote or something on what we think. I think Michelle's suggestion to schedule a deeper dedicated call on on that topic is definitely worth it. So folks who haven't commented and have an opinion, please, please, please hit that issue I'll throw that link. I apologize I was, I was talking I wasn't sharing my screen. Okay. Thanks. Yeah, let's do a meeting next week since we don't have an SMI community call like specifically on multi cluster if that works and then everybody go put your opinion on that issue between now and next week is that is that work. Okay, cool. I'll make sure that happens. Okay. The last issue on the agenda is just an issue around the contributing guide, you all can go check that out if you're interested. Thank you everyone for joining. Does anybody have any last comments before we drop off. All right. Sorry. Just great work, Nick. Yeah, thank you Nick. All right, talk to you later. Thank you.