 Hey everyone. Thank you for joining us at the SMI community call. It is Wednesday, April 15, 2020. We have a fantastic agenda today. We are going to kick it off with Solo. They're going to present us Service Mesh Hub. Then we're going to kick it off to I believe Nick Jackson who's going to give us an overview of Project Hamlet. Then we have some discussion items like the SMI spec conversion webhook and versioning and backwards compatibility, which is always an excellent and very entertaining and very crazy conversation. But very very necessary. So that's always fun. Then we have the SMI blog launches announcement. And then let's see. We also have a link to the webinar about SMI featuring our very own Locky, Thomas, and Stefan. And then after that we are going to open up to any other discussions. There probably won't be that much time. So I'm going to time box everyone to whatever I feel like. Congratulations. Welcome to SMI. I'm just kidding. Okay, so first up, I'm going to hand it off to Solo. Can we actually do it afterwards, Nick? Please? Sure. No problem. No problem at all. Is Nick on or anybody from Project Hamlet? Yeah, I'm on. I'm not sure if Nick is here. By the way, let me see. List of attendees. No, Nick doesn't seem to be here. I don't see him. But feel free to give us an overview. Are you prepared to do that? Yeah, I do. Yeah. And feel free to welcome him to the community. Yeah, let me share my screen. And we can do these two ways. Less technical way, more technical way. I assume we have 10 minutes for that. Is that right? About seven so that we have a few minutes for Q&A. Seven minutes? Yeah, that's okay. Yeah, let me then do that quickly. So people in the call already know about the project because this was in community more or less by the same time that SMI was and basically the idea with or the underlying use cases of the federation spec that we have created in community and led by VMware has been to pretty much a similar objectives to SMI that is how to enable the interoperation of two different service meshes where these two service meshes are not necessarily compatible between them. Right? So there are different problems that we have in this space. The ones we are trying to solve with a Hamlet are a the identification discovery and communication of services. So this is more layer four problems, more networking focused problems. And the idea is that we can help our customers to a bootstrap integrations with other products they already have or we can help them with that. We can help them to expand the service mesh to more places than it is that they need to play as they start with. And also some customers, we anticipate that some customers are going to have configuration challenges with the service meshes in terms of how they should be configured to fulfill compliance requirements, especially PCI requirements. They may require in the future a multi vendor approach to service meshes as a networking solution that they are the same way they are really doing it with other networking products. Right? And the overall active is obviously to sell more, sell faster. It's from the VMware company perspective. The project itself is only solving one small problem that is a service interconnection and service discovery in that big space that is mesh federation. This is a spec that we built during several months with different companies. Pivotal now is part of VMware as you know, but it wasn't by the time. And this is something we have also done with a as you may know, with a console and Google. More recently, there have been some discussions in the Istio community to incorporate this into Istio, something that we have. I would say that one of the objectives of the project is to keep it independent. So we are not tied to any specific technologies. So just to give you an example, Hamlet has two things today. One is a vendor neutral platform neutral service entry that you can use to interchange information about services across platforms. And the other one is a protocol to do that interchange. So for the protocol, many things can be used. The important thing here is the data models, the object that we are sharing, not so much the protocol. The protocol can be anything, as I said. And there have been some discussion in the Istio community, naturally, because they were part of the initial spec around adopting some of the existing Istio protocol, more precisely MCP. But because we wanted to maintain Hamlet vendor independent and have its own life cycle, we decided to keep it its own protocol and not tie it to MCP. A little bit later than that, then Google announced that Istio was never going to be part of CNCF and that meant that we made the right decision by the time because we were not attaching Hamlet to something really existing. So open and extensible, so no constraints at all, interference at all. So the idea is that this shouldn't be imposing a constraint on existing vendors or technologies. So this should be non-disruptive. And the problem we are trying to solve is not multi-clustering. The very people who was confused, are you doing multi-clustering? No, multi-clustering is when you own all of the infrastructure and you can make conventions for a network rising name spacing policy, etc. The problem we are solving is a multiple administrative domains and these ones do not share information between them and it is not possible to normalize or to make conventions. And this can be situations as easy as two service measures with one cluster each or can be multi-clustering in each of the service measures that we are federating. Those details about how many clusters or what is the infrastructure type or where is the infrastructure located are not shared in the protocol and that is the purpose of the protocol precisely. So there are many problems in this space to be solved in the interconnection space. We have to have a way to inter-operate these measures, to interchange the service discovery object, the object model between the two measures. We have to have an object model. We have to have a way to federate identities if the measures are not trusted between them and we can relay on the single root CA and we have to have a way to implement the automation required in each of the participants in the federation with regards to routing of the service measures in terms of how a mesh is going to expose services and how mesh is going to consume services exposed by other measures. All these are problems to be solved. So far we have solved these two problems and the first one we what we have done is manual certificate distributions. So yes we have a protocol to do the inter-operation but the trust is a common root CA. We haven't solved the identity problem. So far we have been watching a protocols like an identity federation protocol done in community by Cytel but then Cytel was acquired as you may know by HP Enterprise and that is we don't really know what is going to happen with that and so far as far as we know that is the only viable protocol as of now. So if unless we do anything related to that then mesh federation is going to require common root CA or the trust is going to the ingresses of the of the measures if they have an ingress at all which is not a requirement of the of the spec. So for us the differentiation between Hamlet and SMI is that SMI is targeting more APIs which are user facing for practitioners and in the case of Hamlet this is more machine to machine what is required to make that communication happen between mesh so we can really make the traffic flow between them and not only have a single object model to do configuration management across the terogeneous meshes. I hope that makes sense. This is a proof of concept that we did with HashiCorp and this is a working proof of concept. We federated any sex service mesh that is now called Tanzu service mesh with console. Console had VMs and this was a super early version of console with beta ingress but it worked. We basically used the invoice of the both a Tanzu service mesh that is using Istio under the hood and a console that was also injecting Istio alongside the VMs. So basically the flow is simple right so we have a service entry a remote service entry that is injected into the local mesh catalog and then that a entry in the local catalog is pointing to the ingress of the other mesh and that is how the flow of traffic happens. In this case we had the common root CA so the envoid has certificates signed by the same CA and the ingress as we're doing pass through of the traffic to the other ingress which terminate at the MTLS and the opposite direction is exactly the same from console to men's sex service mesh so the protocol is synchronizing the catalogs in both service meshes as services are created and destroyed there is no there are no specifics in the protocol about how the user experience should be in each of the meshes regarding a how to expose or consume or how to decide which services are exposed or consume in each of the meshes that is something that we have preferred to leave to each of the products this is a product decision and not necessarily a protocol decision we're about at time would you mind taking a minute to just wrap up here yeah we're done really thank you thank you so much I appreciate it um we have like one minute for questions does anybody have like a quick question any quick questions yeah so I just had a quick question Sergio so anytime there are two services in the two meshes that need to talk to each other it'll it'll always have to go through the to the egress of one and ingress of the other no not necessarily I asked this question oh sorry so it was just in that example you set it up in that fashion okay yeah the example yes we used ingresses and aggressors and but it is not a requirement okay there can be multiple implementations of this the protocol does not really require having an ingress or an aggress it is it is strongly um a in courage to have an ingress because it allows you flexibility to do different implementations of the of the protocol and also because you know in production 3d environments you are going to be required to have an ingress and an aggress thanks does this preserve the identity of that calling service it does yes how does it do that if the egress is terminating the tls session oh the egress is not terminating egress and aggress are doing pass through gotcha all right we gotta cut it off here um I know there's several other questions um but let's go ahead and move on to solos presentations we have time at the end we'll come back for questions thank you so much for uh for presenting search you have you have a link to the deck and any information you'd like to drop into the notes that'd be really great sure thank you for this opportunity absolutely all right um thank you thank you thank you uh so Bridget would you mind dropping a link to the notes for me um in the chat appreciate it so much um all right eat it I'll hand it off to you seven minutes yeah so uh I will start just will work quick to show the slide and then Cristian will do it then okay guys can you see my screen yep hey that's really really uh simple so we announced the week ago can you see that everything okay okay cool so uh service Michelle we announced it uh basically a week ago I think even less maybe a week um basically just I wanted to give you that's kind of like an extension of the project that we did superglue before that to be honest it's exactly on the same way that we did superglue it's on it's basically just the better implementation for everything that we did but the vision is the same um basically we're working a lot on with superglue community as well as with SMI and when we worked on all of this we got five a three pushback one of them was about the common the lower common denominator people basically really wasn't against it they felt that this is a limited them um and they it was also hard for them to to not you know to basically be slowed by the the the the mesh that is is um moving slower and it was a very hard problem for us to come to it to for instance for our customers using stio and telling them you cannot use uh circle breakage because one of the other mesh does not support that so that's a really really problematic problem and we got a huge pushback we all of us got a huge pushback from the community so that's number one number two that we got a lot of requests in superglue is basically to support the last version of each matches um specifically stio 1.5 and the last one was multi cluster all about the multi cluster um so basically what we announced last Wednesday it's really pretty simple christian we show us a demo in a second but it's very very simple you can register a cluster once you register a cluster we're managing it we're discovering a lot of things about this cluster we discover every mesh that running in this cluster we're discovering the workload that belong to those mesh so basically we're going we're looking at this you know we're basically detecting the site current that we know that it's belong to the mesh and we basically have all those information you can also install a mesh right and upgrade if you need to we basically abstract the operator of envol of stio and link it installation and so on once that happened uh we add an api we extended the smi api uh it looks more like the glue api and the point of like it's actually also you can choose source not only destination and it's not a lot of common denominator we also change the access policy a bit and again christian will show you in a sec but i think it's a really really simple way to actually describe a mesh configuration there is a source there's a destination there is stuff that going on the pipe and the the other thing that we need to do is basically the grouping of those meshes and we're calling it virtual mesh so you can take two meshes group them together we are doing behind the scene all the mess of actually you know identity and a rotation and roots of you know a certificate rotation and so on and basically just making sure that those two meshes will be able to talk and again we will get to the detail in a second all the team is here so they can talk in more details and we will call it virtual mesh um and and we also and i am a added another feature that i think it's pretty cool and maybe a quick a quick show it's really really simple i have a class there are a lot of services i define a source i define a destination i define a policy on the rule but as we all know this is only where the problem is started it's going to be a lot of a lot of sources a lot of destination and what you kind of like losing all of this is what's going on for specific service configuration so we basically create a CLI command right now called describe but basically you can zoom into a specific service and see what what's rules apply on it by the way the way a service mesh is working is that when you apply a new rule if it's if we cannot honor it we're just going to arrow out on this the status will be for not apply so it's not going to break it's just not going to be applied so that's kind of like i'm not going to talk more i i'm all about let's see it so i will move my the screen to christian and christian we show you a demo well let's uh let's like let me share my screen and like you are not supposed to do moments before the demo and making changes to the demo so we should make a lot of this goes let's uh share my yeah that's great okay you should be able to see my terminal is that correct yes all right yep look so sorry was somebody gonna say something all right so what we have here is we have two different clusters running on gke and in cluster number one we have an istio installation we can see we have the book info part of the book info istio's book info demo install where we have reviews v1 and reviews v2 and in a second cluster we have a different istio installation and over there we have we have reviews v3 running all right so that's that's the setup we have um service mesh hub installed so we can see the the pods that make up service mesh hub we let's see if we can get uh we've registered these two clusters inside of service mesh hub and then we've discovered automatically discovered the two different service meshes so this happened before i was setting up i knew we had time constraints so i kind of set up that stuff if we if we check service mesh hub we should see and cross my fingers that everything's installed everything's looking everything's looking good now the first thing we're going to do is now we have two different service meshes they have been installed individually and separately and they have different trust routes so for example on cluster one when reviews calls ratings we should see a certificate chain right here we can see the route that's that that signed that certificate chain ends in whatever gag right on the on the second cluster we should see a different route when reviews calls ratings right because those are two different those are two different clusters here shouldn't be gag anymore it should be something else right so we have two different route uh trust domains here now as you didn't mention the virtual mesh resource in service mesh hub allows us to group multiple different service meshes in this case it'll be two istios if we look at the virtual mesh we can see that will will automatically generate a root ca from which those two meshes will derive so that we want to federate this identity we want to include these two meshes and they're defined here now we won't enable our back end and policy control book we'll do that in a little bit later and the federation mode that we're going with is permissive which means as we unify them we will enable service discovery for all of the services between the the two meshes so let's cross our fingers and apply this virtual mesh and let's take a look at it we should see ah one second that did fail but that is a known thing that we have fixed in a new version so let's give that another try okay get virtual mesh please no errors please no errors okay sorry that's i'm using a little bit older version um but that's that's fixed a newer version but so when we when we create the virtual mesh abstraction um what we what we end up doing now is telling each of the meshes you go off and create your own intermediate certificates send it to the management plane that will be signed by the root and then now now use those intermediates with signed by that root shared root um for each of the different meshes so no keys get transferred over the network what we're doing is sending certificate signing requests so we can see here on the management plane the virtual mesh ca cert that gets created this ends up being the root let's see if we can try to remember this y a and a couple of equal signs and then what we see on the remote clusters and any of the remote clusters is this certificate signing request so this certificate signing request ends up being sent to the management plane and then we should see that the root at base 64 encoded but i'll show in a second we should see that this was signed by the the roots the root certificate that was created by the management plane so ultimately what we end up having then is secrets created on each cluster we can see the ca search for istio here on cluster one we can see this the ca search on cluster two both of them signed by the same root which lives on the management plane and now because of a kind of an issue with istio that we have to we have to balance the the istio control plane to pick up this new ca um we'll give that a second let's balance it on both clusters so that they both pick up their new source of trust we'll give that a second we open an issue for it and we're going to fix it for them yes on on istio we should see the the workloads should now be provisioned with their new source of trust and now if we check the certs when we call all right well so they're they're coming hopefully they're coming up and they're fine let's cross our fingers for that now now the cert chain that we see when reviews calls ratings in uh cluster one oh let's try that again oh i know you're almost i mean all right we're almost there all right um so reviews calls ratings right so uh while it's doing it i'm going to just uh talk real quick i mean we didn't have time because this demo is really really quick but actually what i think really really cool about this project is the fact that it's really really easy to do stuff with it so for instance when you're starting you can in it demo and that's putting up all the environment for you already to kind of like go and try it i think this is really really strongly uh recommended and as i said there's way more functionality uh and yes hopefully christian demo will work yeah so now we see on the on the on the call from rate reviews or ratings to reviews we see that the root chain is now our source root and then if we do the same thing on cluster two right here talking to cluster two we should see the same root now so our identities across the clusters have been um they share the same the same source now like adeem mentioned on top of this we built uh they built to do traffic routing and access policies um now that the meshes are unified um but we'll have to show that later yeah thank you so much um we don't have time for questions so i'd really like to invite um both the folks from hamlet and solo back uh this is reported so if you want to take another look at the demos please do i encourage the community to do that and then come back uh next meeting to ask your questions or ask them in the smi community slack uh bridget posted a link to our blog post about smi going into the cnc f as a sandbox project uh in the um notes if you have a blog that you'd like to write please uh contact her is that the right thing to do bridget share absolutely um okay cool and there are so many new people here which is really really great come back next time so you can introduce yourselves to the community and we can talk a little bit more about the project and triage um but until then i'll see y'all next time