 meeting minutes Bridget. Absolutely and we are live. Hey everyone today is Wednesday July 22nd 2020 welcome to the service mesh interface community call we're going to kick it off today with I'm gonna say introductions because I do see a few new faces and then we'll go ahead and go into stand up for discussion items we have a few and we have like the reminder to submit your blood posts support for personas topic and then support for routes in the metric spec topic so without further ado does anyone new want to introduce themselves yeah I'm Jason Webb I'm from Intuit and I'm a more of an end user of service mesh not really a developer we do support the Admiral project out of Intuit which is a multi-cluster orchestration for service mesh but primarily I kind of look at service mesh more from an end consumer perspective awesome welcome thank you for joining us Mike do you want to introduce yourself hi I'm Mike I'm an engineering manager on the console team at HashiCore so we're just interested in learning a little bit more about what's going on here awesome thanks for joining us anybody else want to introduce themselves I'll just say real fast I'm redbeard from Red Hat it's been a while but I'm just kind of dropping in to check in on things and see where the community's been at for a bit so that I can go back and thump some folks on the head on the Red Hat side that's awesome I'm so nice to see you again redbeard yeah it's a pleasure all right okay so let's go ahead and oh anybody else if you do want to introduce yourself at the end feel free to drop that into chat and I'll make sure to check it out and save some room at the end okay so jumping right into our discussion items Bridget I'll let you keep off about the blog post oh yes I know solo and I think a couple of other organizations were thinking about writing blog posts and my urge to you is hey Kupkan EU is coming up a lot of people are going to be looking at stuff in the Kubernetes space now could be the moment to write a blog post about what you're doing to use service mesh or what you're implementing in the service mesh ecosystem and then submit that as a PR to the SMI spec website repo and the link is in the notes super cool we'll do thanks Bridget I think another really good topic too would be like HB header matching support like that recent edition I feel like we're not really talking about it and stuff so we should definitely make that known that that's a thing and that people should check it out and implement it I don't know why I muted myself okay so the next topic is support for personas and Jason I know you wrote an intro here but hopefully you can or Jason and Michael it says Michael on the side there can y'all kind of give us an idea of like what you want to see here re-summarize the summary yeah sure yeah so I guess the kind of the where this has kind of come up I guess is as we sort of look at at least more in-depth with the SEO API we haven't really adopted SMI I'm directly most of what we use as a sweet guy but as we look at that and how we can bring it into like the enterprise there's a couple of challenges with it so the first challenge is the kind of there's there's different you know even though they're like maybe a service publisher but I'm kind of acting in different roles depending on what I'm trying to do so when I'm trying to you know offer author like routing configuration for example I'm sort of controlling how traffic gets to my service or I'm controlling access for example or the split stuff like that so it's more from like the service owners perspective and also maybe there's some like defaults of how my service should be consumed like this is the timeouts that I would expect on a service maybe some default retries and stuff like that but there's also this the client persona aspect of it where I'm consuming a service and I want to be able to override some of those things so I want to be able to set like the timeouts or my circuit breakers or retries because upstream I only want to retry once with a one-second timeout because the UI is gonna you know it is gonna time out beforehand and stuff like that so you kind of need that ability to override sort of that consumption profile I guess you say in a way that is also isolated as well so that's one of the like without having that configuration broken out as a separate entity it makes it really hard to put kind of authorization rules around it so we can run it in a multi-tenant environment so with a lot of the server side configuration what we end up doing at least is sort of putting a structure around the DNS names in the SEO configuration and then tying that back to basically a namespace and then within that namespace you can only configure certain kinds of DNS names and that sort of gives us it like an authorization containment based on the namespace which is based on the team and so that way people don't kind of impact each other but without having a way to kind of set things from a client perspective it makes it pretty challenging so the reason why I kind of brought this to this group is we were going to look to actually solve this problem kind of in our admiral project and just use a SEO configuration introduce a couple CRDs to do this and then just put orchestration to manipulate their configuration that's kind of the path we were going down but I figured it would be maybe useful this is kind of a you know a new project kicking off to kind of maybe bring some of this stuff to you guys and see what you guys thought about it it was something you know SMI was is interested in it's so none of the meshes I think kind of have this concept so it's not necessarily pulling best practices back in this would be a little bit more from the edge perspective of what's going on in the mesh and folding into the spec which I don't know if that's appropriate for SMI or not but anyways I thought I would just bring it up with you guys and kind of something that's like an end consumer of mesh and how we're trying to get the API is you know usable for an enterprise in a multi-tenant scenario with lots of clusters and stuff like that it's just something I'm seeing so I thought I would bring it up to you guys yeah does anybody have any comments or I'm not before I jump in yeah I can comment on it in terms of traffic access I don't see how you can default to a separate configuration on the client side it's definitely an interesting idea can you give me an example like let's say you want you have a namespace and that namespace is a web API and for some tenant you want to restrict some routes and for a different tenant you want to allow those routes is that use case yeah for like for traffic access like so at least from again this is this is just the view of things that I've done you know within the stuff that we support right but what we'll do is we'll author you know there'll be a different set of kind of rules right to kind of almost like scope definitions and a lot they guess is the way you can kind of think about it right where it's like this is sort of this this sort of set of rules gives me access to this chunk of the API and this chunk of the API and by default a consumer would get chunk would we get a chunk of maybe the most generic part of the API but more sensitive API's might be left to only selective clients right so as a service owner I might say you know this is a client that you know I know about and I'm going to give them access to this particular chunk of the administration part of the API or something like that so that's sort of where I've seen it from an access perspective be useful so we don't actually do that I mean I get so we don't actually do that with our service mesh implementation yet we do that with our our other infrastructure that we run on board moving that to service mesh so we would that's something that we would look to do in our service mesh implementation yeah I guess it goes back to the identity problem how you manage identity for all these clients in in SMI we define identity in a very Kubernetes way it's a service account so we define how things get access based on the service account that initiates the call and the service account that let's say is running the workload that you want to secure so it's more about service accounts I for example is he also supports off authentication based on tokens and that could let's say be different totally different to service accounts a service account is more about the machine identified than a actual user identified yeah I think so service or the system identifier is fine but so where we run into problems using service accounts is especially as we run as we look at running a certain like a typical service itself will end up being at least a lot of our services use DR so we end up running the same service across multiple clusters and those clusters are isolated from each other we don't use like Federation or anything like that so so we actually don't use a service account really as our services identity we actually use it a different mechanism doing that but I guess I guess so the I guess to make SMI useful I guess it might need to have a be able to have identities that are represented than maybe that are larger than one cluster or make that part pluggable to a certain extent so there's a there's a type of identity that can be used or something that's extensible in there because identity is a tricky is a tricky thing well that's debatable because if you look at what cloud vendors are doing there is a iron roll to service account there is a GKE IM to GCP IM to service account and so on so in a way even if you have different ways of identities you can link them back in Kubernetes to a service account and SMI works service accounts so if you can link a service account to an external identity then SMI doesn't have to deal with it that's how we got away with it yeah as you kind of come in from other clusters though it's a little bit tricky right so I'm calling in from one cluster to another cluster now I have to have like a transitive like service account knowledge in between the clusters and stuff but so like then a multi-cluster kind of it gets a little bit tricky but I guess I'm not really like I guess I'm not really debating like the service account aspect I'm just saying more from like the the idea of a set of API's that are focused on the consumption of services and the attributes that are tailored towards service consumption I think that what that would be valuable as a way to build sort of an administration boundary around that so it can be used in a multi-tenant fashion because that's more of the the thing that I think would be useful so that's that's my that's just mine thank you yeah um are you familiar with traffic specs and traffic target have you gotten a chance to kind of go through some of that I didn't look yeah yeah I think one way to kind of like make the logic around what is accessible on your service what routes and on configuration is accessible on your services to kind of like reuse the traffic spec object traffic specs object across different traffic targets which would be used for different services to configure different how different services can access a particular service so maybe that's something to kind of look into but I'd love to like dig in further a little bit because I think what you're talking about from the user experience side is is very interesting and there might be like a higher level concept that we could we could think through we haven't really tackled retries and circuit breaking although that's something that comes up repeatedly so I think I'll be a good way to go about this is to open up a github issue around this topic and like dig in a little bit further and see where the gaps are in terms of like what we have today and what what we would need to kind of fulfill the user experience that you're talking about sure more like a github discussion oh yeah I'm still not used to using github discussions do you like those stuff on yeah we are using it for two weeks in fluxy D and it's awesome because you if I don't know during an issue other issues are rising so that comment was specific to someone else's comment right and in in discussions you can do this branching of replying to a certain comment which is great for API designs and all things like we use it mainly for API design proposal okay yeah so then this makes sense to do as a discussion because like so usually Jason we just like I have people open up an issue and a pull request with the changes that they specific changes that they propose but since this might need a little bit more async back and forth the discussion makes more sense here for sure and do you guys do anything with like like RFCs or anything as far as like a like a write-up of what you would expect out of it or is it just kind of a discussion we really should know we don't have an RFC process at the moment I could I could build one for us I could just like write a process a quick process up for us if that makes sense Stefan what do you think yeah we we currently have a template issue for proposal where you say hey I my proposal affects one of the current APIs or I want to add the new API then we have a section okay can you detail some use cases for it why it's good why it's not now if she's more complicated in terms of things you have to fill in I felt like the current issue template is enough for what we are seeing but yeah if we we could evolve to an RFC proposal type but yeah I feel like we should start to the GitHub discussion for big topics that we we didn't touch yet in SMI and this and from there create issues after we we brainstorm and so on I think that's in the interest of lowering the barrier of getting started on this Jason how about you just open an issue in the SMI spec repo and then if we want to build a discussion out of it we certainly can but I don't want extra tasks for you can move an issue to a discussion and vice versa it's very easy for us to move them okay so I'm just gonna move forward here the only other thing that we have on the agenda is I linked issue 129 I think his name is Adam oh Alex long had proposed that we extend the SMI metrics specs to support metrics per route and I think that this is a great idea and it's any issues with the proposal I approved it I know Stefan approved it but it just needs to be rebased I ping them on slack if anybody has any feedback or issues or anything like that please please feel free to comment on that thread any anything right now on the metrics per route but um Brian does your team handle like this is Keali on your team oh right there just walked away that's cool um but yeah okay so yes well sorry I I share an office with my wife so when I'm talking I need to do that but yes indirectly the Keali team is involved with me that's part of the reason kind of why I was here both dropping in to see if any of them showed up as well as do a little bit of an audit you know we have a number of concerns and interest where we would really like to be more closely conforming with the SMI spec and some other ideas around potentially integrating the open shift router which is a specialized ingress that red hat for a while with SMI so yes that being said you can expect that folks from Keali will be showing up to the SMI call soon okay from that team directly yeah I know our community is super interested in getting SMI support in in Keali for sure everybody's like obsessed so that would be great anything to make that happen would be great I'm happy to help John he is on this call he's on on my team and is working on metrics related stuff so he's gonna be touching SMI metrics pretty soon and yeah there's a there's a lot of interest around there so if it makes more sense to like have a longer call I'm happy to help set something up and and dig a little deeper into whatever y'all need and help okay great I will talk to Maltron Leo who is the product manager for Keali inside a red hat and then get a couple engineers and him coordinated in touch with you okay great thank you of course cool what else is on this agenda anybody have any topics they'd like to bring up yes the fun what's up so now that we've released the SDK thank you for that I want to move forward with the TCP route specification we I've opened an issue like long time ago and everything was blocked because yeah we need to add the spec to all the things so I'm I'm going to move forward then and create a pre-request on the SMI spec to define TCP routes and unblock the utp route thank you I'm going to ping people on slack for reviews okay I'm excited about it though whenever you're ready yeah but by tomorrow it'll be there I have a pretty good idea what what should look like but I it was blocked so now it's it's time to move forward all right what else what one more thing I wanted to bring up like when we last discussed about breaking changes in in the API we said okay maybe it's Kubernetes is not ready for an admission controller but I'm guessing most cloud vendors now are on 116 my proposal is to drop support for anything below 116 and work on proper admission control that can deal with changes now that we also have the spec inside our API it should be straightforward how to create with QBuilder such an admission controller for at least concerns about Kubernetes lower than 116 Asia 117 I think who's on it 117 okay yeah I don't even I don't even know that we support one I know we dropped support for 114 recently um okay no I don't have any any concerns at the moment you want to just open up an issue in case something comes up is there an issue already on the SDK yeah was it and say hey now we can do it and then the other thing I was gonna focus on it I'll like maybe Thursday or Friday of this week is like Kubernetes and grass and kind of like adding some documentation around how SMI thinks about North sorry it's north-south traffic I know you opened a proposal or open an issue around that Stefan so I just meant to get to it before this meeting but I didn't so I'll do that tomorrow yeah I think we should look into ingress v2 and yeah build something around it should work perfectly fine with SMI okay anything else okay we're still having some issues around like how to think about if you install a traffic split but there is a traffic target that doesn't allow the traffic split to actually happen like what the error code should be that bubble up and how to modify the status object thanks thanks for the status so so we're just still thinking through that but I will just update the issue I think Stefan you're applied to it right yeah yeah I think being layer 7 we should return the correct access denied status code okay if that's the case I think that's the best way to communicate to the consumer that access is denied not just you know TCP timeout or something like that because we we act on layer 7 we can return a meaningful status code instead of Kubernetes CNI that cannot do that and it blocks the stream itself like a network policy right okay that's literally all that I've been thinking about any anything else anyone want to add any my obsessions at Kubecon right beard you not this time no all right cool all right I'll just give everyone three minutes back thank you everyone who is new and introduce themselves and everybody else for being here have a great day