 All right, that's not I think we could get Started pretty much Liz. You're here. I believe right I am here. Yes. Awesome. Cool. I think Taylor feel free to get started We could just go to the agenda slide right now. I have Brendan Brian and Joe beta not attending But all the other TSC members are here. So we have six out of nine attending and quorum is met so Feel free to take it over Liz if you want to here's the agenda I Guess I could yeah, why not? Hello everyone. Let's move on pretty quickly because I'm sure we want to spend the time on the presentations Yes, so the storage sick pull request Who wants to make any comments about whether that is ready to go I Think Quinton or Alex Chircot. Maybe you want to speak to this I think the charter is ready So to kind of formalize that the TOC needs to vote on it. So if there's no opposition from the TOC I could kick off a vote today, but maybe Alex or Quinton want to speak to us Just by way of backgrounds The storage working group had produced some content and have been involved in Dragging some parts of the community and obviously we want to kind of take this further Some other initiatives in mind where we're also currently running a survey with the end user forums So we put together a charter and what was on the on the sick charter that was approved by the talk and G&B is this kind of efforts to be the talk liaison and We have We have a number of people that have Put themselves forward for the chair and take lead positions So I guess what we were kind of looking for is some guidance to actually formalize this and make it real The sick charter requires a TOC votes to to sort of formalize it I kind of ask Chris if we can get that Done this this meeting Okay, I know that and Quinton and Alexis were very involved in drafting the you know, the The processes for six and Alexis you're here. Have you got any comments about this or do you think it's ready for going to a vote? You're in need of this He's I'm sorry, sorry, sorry, sorry Yeah I'm happy for us to vote on this. I think that In the past when we voted people have often taken it a bit more seriously and brought out some last-minute questions Which we can account for during the process and also we've pretty been pretty good about fixing problems with a 1.1 release as well. So let's just vote Any of the comments on that I think we should go ahead and do that Yeah, I'll take an action item to do that after after this meeting. Thank you, Chris Thank you Are you going to whoever is presenting cloud events? Whoever. Yes, that'd be me. I'm Doug So because we have some new Because we have some new TOC members I decided to give a little bit of background on why the cloud events project got started and stuff if you guys are already familiar with This don't hesitate to stop me and I'll skip it, but I figured just in case I try to cover it for you guys so really why cloud events so we were trying to solve this problem of Many people live in a multi-cloud world multi-service world where events are flowing back and forth across environments and in particular in multiple ways different transports different mechanisms for transmitting the events and There really wasn't a consistent way for receivers of the events to actually be able to Without some some specialized logic to to be able to process the events not necessarily from a business logic perspective but from simplistic sort of Middleware perspective right how to get the event to the actual function as an example to process it Yeah, if the middleware want for example want to do some sort of advanced filtering More often than not it would have to understand this Oh, this was an s3 event as opposed to some other kind of event to be able to do the filtering and People were looking for some sort of inter-obility around this space And so that's kind of why cloud events sort of got started and just as a quick little graphic here This was one of that because of the one of our first demos to represent This is that problem where we had two different event sources AWS and Azure blob stores Going through different gateways sending out events to all the various subscribers in the middle And they would probably have to be able to or they probably have to write specialized code depending on the event coming in Just to do some basic filtering right to know where to look at each one Based on whether it's going to AWS or Azure on whether they even want to process the event in their business logic or not And so what cloud events was able to do was to try to harmonize that and try to make life a little bit easier for people So let's go on the next slide So how we're going to be doing this or how we did this What we looked at doing was basically defining a set of common metadata across events And the way I kind of tend to look at this is we were doing for events what HTTP did for simple message exchanges meaning HTTP at a very high level is very basic. It's just a set of headers A blank line followed by random data in the body, right? But the commonality of those HTTP headers allows for some very powerful yet simplistic things like Basic routing right and sharing of a location of where metadata can be found if you do get agreement On what particular metadata you're looking for and so we kind of follow a similar pattern here Right by defining some common metadata that appears on all events. You can at least allow the infrastructure to do some basic transport or movement type logic of your events And so we're defining some common metadata Without changing the business logic Meaning we don't get into this common pitfall that we'll get into which is defining yet another global Common event format that everybody has to hear to we decided we're just looking at extra metadata Not touching the actual business logic itself And of course we're doing this all to help facilitate integration and our ability across platforms with sort of a bigger goal of hopefully looking at Portability of functions themselves between platforms by because if everybody can for example assume A cloud event is coming in as opposed to just some random event You may be able to get a little bit of better interoperability and portability of your functions across the various platforms So those are sort of the high level goals and the whys of what we're doing this We were approved as a sandbox project Back in december 2017 as a result of the serverless working group And for those you don't know the service working group was basically started up To do some investigation around serverless in terms of what does the cnc have want to do if anything around serverless And so we produced a white paper a landscape doc, you know general stuff like that But one of the outcomes of the white paper was some recommendations for the toc Around possible areas of interop and harmonization And one of the low hanging fruits was events And so as a result of that the toc voted and said okay Go look at what you can do around eventing and that's how cloud events kind of get started All right, and obviously if you have any questions, please Jump in and ask him anytime. Otherwise. I'll just keep him rambling at a laser speed Um, all right. So overview of what the spec itself is It's actually a very simplistic spec As I said, it's just what common metadata Do we want to see in all in all events to be able to call to be called a cloud event And if you look at this list the first four that are in bold are really the only ones that are required Everything else is optional and they're not exactly You know rocket science here, right every event gets a unique id Um a unique source, which is basically a url saying where this event came from Uh, the cloud event spec version and then the type and you can think of type as The the type of event right so is it a create versus a delete kind of a thing very basic stuff Things that almost every single event should have anyway, so it's in there Now the other optional attributes are things that are useful, but may not necessarily be required for all events Things like the subject right? What is this event about as opposed to where did it come from the time it was generated? Information about the payload right the content encoding the schema of the payload things like that that are useful But not necessarily always going to be there So at a most basic level you can think that any of messages flowing around the system could be turned into a cloud event by just adding Those four top level properties and we'll get into a little bit of what that might look like in a second But once you once we define those properties what we then did is said, okay what are those things look like in different transports and serialization formats so for example, we define what a cloud event looks like for For a jason payload or for when you want to serialize the cloud event in jason Or what it looks like when it's being transported over htp versus mqtt that kind of stuff, okay But again the point remember the point of this isn't to transform people's data or business logic This is about the metadata to help move the message from one place to another so it's about the metadata not the data Okay moving forward So let's take a look at this example go ahead the button Okay, so first let's start off with a very simple htp request nothing too exciting here a simple post And we created a new item in some database or something So what would it take to turn this into a cloud event? Boom those four attributes and this is in the binary format of htp So basically what we did is we said add these four htp headers, which are completely safe to add to any message anyway And wham this now becomes a cloud event And any receiver that understands cloud events can now use this logic to do some processing Maybe filtering or routing is appropriate without ever having to actually know that this was a new item type of event from bigco.com or big yeah bigco.com Right, so we we have enabled some basic high level Middleware routing and filtering type stuff without ever actually changing the business logic or the the format of the event itself Just a couple of extra headers very simplistic type stuff so hit the enter key, let's go to the next one And we also allow for you to define or to serialize the cloud event as a top level thing Meaning let's say you actually do want to use a standardized wrapper in essence for your event thing We do define the cloud event format itself So notice the content type changed from just application jason to application cloud events plus jason And really the only difference here is we move the data from the headers into the body And the old body became under the property called data But it's still the exact same data just serialized slightly differently If you want to actually have a common format for your event or the event thing metadata as well All right, let's keep going forward So in terms of deliverables, we obviously have the specification itself that defines the metadata We have the serialization rules for three popular formats jason amqp and protobuf And some popular transports hp gnats and qtt you can read the list there We did come into one interesting problem where Uh because we're trying to promote interoperability There were some people that wanted to Add a serialization for their particular format or their particular transport But we didn't feel like it was really a A community or a interoperability Transport for example rocket mq was one of the ones that popped up And the reason we didn't feel it felt We didn't feel it felt like a generic Transport was because it was a transport for one particular purpose of mind with only one implementation And so we felt like it was a little bit proprietary even though it is open source And so we went back and forth on this a lot and we realized that they're probably going to be quite a few Transports or even serializations that might fall into this category of useful and used by people, but it's not really But by by creating a specification for we're not really helping interoperability because there's really only one implementation for it But we didn't want those guys feel excluded So we ended up doing was having basically a webpage that has a list of pointers to these quote Proprietary transport bindings that are hosted by the people that own the transport themselves So they can still feel part of the community But we're not necessarily promoting these at the same level as we do as what we felt were a real community Transports and and serializations, right? So just wanted to call that out to you because that was a big discussion point for us Um, so the in terms of other other roles We have a primer which is basically just you know our ramblings about Design decisions and guidance for people in terms of how to influence the stuff stuff That's very very useful, but not really designed for a spec per se. So that's why we pulled down the spec We have what is that six different sdks You can see the list there and then we have a list of Extensions, these are things that are beyond just optional from the spec These are even optional for to either appear in the spec at all. And so these are sort of Bits of metadata that we want to sort of play around with see if they're actually are popular enough to At one point in the future get pulled into the spec Or maybe it's a it's a niche kind of property that is useful, but only used by a couple of people Um, but we wanted to give people a sort of a common community base place to host these things Get people to sort of work on them going forward So there's listed the rules there Any questions on that? All right. Thank you. Move forward status. All right So we have weekly phone calls every thursday at 12 eastern new uh 12 p.m. Eastern We get about 30 people per call on average, which I think it's actually pretty good for weekly call From and we've had total of 76 different companies participate at one point in time Obviously not all 76 or every week since we're like at 30 But of the 30 that are over there on average about 20 people are voting members And that means that they participate on a regular basis and that's how they sort of earn their voting rights Because we don't have code and it's a spec and a lot of our work is very collaborative in nature It's very hard to track people from a traditional pr type perspective So we based it upon participation on the weekly phone calls instead and so far it's worked out fairly well I think the people that do end up voting are the ones who are most active and so that that works out really nicely We even though it is slightly different than other types of open source projects Uh, we do have interop events typically at coup cons themselves But people have used our demos at meetups and stuff like that. You can actually see in the top right hand corner This is actually going to be the demo that we're going to show off at coup con next week It's basically a simulating Events going through a common bus at an airport And it's actually based upon the acrus semantic model, which is produced by the airport council international group And basically what it's about is there's a common bus where As people walk up to the vendors that are in the bottom part of the picture and order coffee They'll get delivered the coffee But if the coffee retailer ran ran out of cups what they would do is send an event and the retailers on the top Would it would get the event send out a notification or another event saying they have a delivery thing to be made So you got the trucks the right hand side Start flying around the screen picking up packages delivering to the retailers and yet We're going to actually have the the audience members for this demo actually participate by actually ordering coffee through their phones And so it should be a lot of fun because we actually get customers Or the participants in the audience involved in the demo itself But the point of this is actually see events flying around And you can actually see the list of events on the right hand side there And that was kind of small But you can actually click on those to see the actual cloud event that flew through the system We could talk a little bit about that But anyway, the point here is to show interoperability And how cloud events has actually made this a little bit easier And to show that it actually is being considered to be used by some, you know, real world people like the acrus guys Um as of right now, we are still at 0.2 With 0.3 just around the corner. We were hoping to make it in time for kubcon, but realistically I don't think we're going to make it Because obviously it's next week But I do expect it to happen relatively soon within a matter of weeks The what's interesting is you can if you actually look at the version numbers going forward You can see that In terms of actual real hardcore work in terms of new properties or attributes that are going to get out to the spec You can see By the time we reach 0.3. We're basically going to be done 0.4 is all about possibly other transports and we haven't had a new one in a while there So that's almost done as well 05 is just resolved outstanding issues that are just in our backlog So really even though 0.3 sounds like a low number in my opinion We're actually closer to like a 0.8 verging on 0.9 type of thing Because I think once we get to the 0.5 we're at that stage now where it's more of Testing and verification that this actually is useful to go forward to get to 1.0 Now we haven't verified or discussed How long we're going to sit in this testing stage yet that's going to come up when we get to the 0.5 stage But I actually don't anticipate it being too long. So I'm hoping Maybe within a couple months we actually may feel like you know what we're getting close to one point though Maybe we start thinking about you know possibly doing a vote at some point, but we'll have to see how it plays out That's just my personal take on it All right, I'm going forward In terms of adoption We do have quite a few people using it These are the only three that I got confirmation that it's okay to use their names here So microsoft serverless comm s a p are using it The one probably one of the bigger open source projects that's using it is k native They're actually using it as the basis for their eventing infrastructure So as events come into k native and get Shuffled around between the various components or even off to the functions themselves They actually get transformed into a cloud event to provide that level of consistency So that when they started adding things like filtering mechanisms to k native they can now do filtering based upon Cloud event metadata, right? So they don't have to actually understand whether the event again came from s3 versus azure versus something else They can use the cloud event metadata to do filtering and people can specify these filters without having to care about What kind of business logic or where they came from or even the transport that was used Right. So again, that's exactly what cloud events was designed for to allow you to do that basic level middleware routing filtering Without having to understand the events themselves So in terms of plans and I said finish up the the version stuff that I mentioned the previous slide Finish up our sdk work and possibly consider incubator status I will talk about that more in the next slide When that's all said and done, uh, whether we actually reach one point though Or we feel like we're entering that testing stage where cloud events is kind of died down in terms of a Weekly churn We're then going to shift our focus back to the serverless working group because it's pretty much the same members in both organizations And we're trying to we're then need to figure out, you know, what we're going to work on next if anything We did work on or we started processing a workflow specification for orchestration of of of Of functions But they've kind of got stalled because most people wanted to finish up cloud events first So we'll return back to that and see if that really is what I want to work on going forward Okay, so before we jump to the next slide though That kind of ends the cloud events specific bits. Do people have any questions? Okay So for end users, are you referring to the platforms that Microsoft serverless and SAP because um, I'm really interested in who's using it for application like Like the end users of cnc app are usually the companies that are using the cloud platforms so i'm curious if You know, you've had that kind of engagement. Yeah. Yeah, so The list I have up there I believe these those folks have it as part of their product in some way And so I assume they must have end users that are using it but If you just go to the next slide and thank you sarah for Being a straight man and getting to the next topic that I want to talk about it is When we go to incubator or we consider going incubator In terms of the TLC requirements, I feel like we're pretty much meeting them all right now with the expo exception of this one that says Document that it's being used successfully in production by at least three independent end users And when you have a real normal open source project with code, it's very easy to know who an end user is In most cases I think but when you're a spec What is an end user and there's so down the bottom here? I say, you know, is an end user A product using your spec or is it end user a user of the product using your spec? And so I kind of wanted to tee this up for the to see to help answer this question Because that's going to dictate when or if we try to go for incubator status That's there. I think that goes directly to your question Yeah, and from my perspective if you have products that use the spec but not no User of those that's uses two products. It's not clear that the spec Actually achieves its goal Yep, that's the question. Yeah, so that that's kind of my perspective on it. Yep Yeah So I was hoping to get some clarity from TLC on this either today or in a future call because this is a question That's been lingering with in our group for a little while now Yeah, it has been lingering for sure the the question of what the different graduation criteria And meanwhile graduation incubation criteria mean for specs. It's it's Come up for tough as well. So it's definitely something we need to talk about and hoping that we can Cover that off maybe the next Normal to see meeting. I think you should have that on the agenda Yeah, plus one of that and there's also this ongoing Issue I know you commented on that as well Doug And in Justin as well I I commented on that so maybe you can ping the to see members to add their Add their opinions. I think that the end user point really Like I think before we answer the end user question I think the TOC needs to decide like is that really the right question to be asking of the spec spec projects anyway What are we actually looking for? As incubator status and I listed a few points in that issue. So let's continue the conversation for sure And as Chris said in the chat at July June 4th the person with the meeting that he hasn't scheduled for so All right, anyway, I think that's the end of my cloud events presentation anybody have any further questions Any concerns from the TOC? I think it looks looks good from my perspective Doug. Okay. Thank you. Great progress. Yeah, thanks Okay, thanks guys. Thank you very much. Okay. I'll be to you Kevin All right. Can everybody hear me? Okay. Chris would give me a thumbs up on the all right. Perfect. Well, thanks everybody So my name is Kevin Shu. I work on the Tai KV project along with a host of many many people who are actually on this call as well So I want to give a shout out to everybody who's working on this project And this presentation is for our incubating review And for those of you who aren't familiar with Tai KV I want to give a quick project overview and history Of what we've done. So Tai KV is the open source distributed transactional key value storage layer The type part just stands for titanium the chemical element KV of course just stands for key value store And we got our inspiration originally from the designs of the google spanner project As well as hbase some of the core features are Tai KV is a strongly consistent database So not a eventually consistent No sequel database like some of the other ones that are out there in the market. It supports distributed transaction It has a co-processor framework that supports distributed computing, which is actually a very powerful mechanism that's being used quite a bit to Essentially leverage parallel processing to process very complex data queries It is a natively horizontally scalable and also replicated across geography Using the wrapped consensus protocol and a quick historical tidbit We actually leverage quite a bit of the scd wrapped Implementation when we first started building Tai KV about now three years ago And now scd is of course part of cncf as well We became a sandbox project last september our sponsors were brian cantrell and ben hindman at the time And the reason and the goal and the vision for Submitting Tai KV to become part of cncf was really to provide this persistent cloud native database layer That could be the building block to simplify the building of other Interesting cool systems on top of something like Tai KV And I will go into a little bit of detail Later on in my slides in terms of how that has already manifested itself even just in the last eight or nine months or so Of being part of the cloud native ecosystem What you see here is a brief architecture overview of Tai KV itself the boxes that labels Tai KV You can imagine them as either physical machines or disks or VMs and of course containers These are individual Tai KV instances that can be scaled horizontally the little region block in the middle of it Those are essentially Data chunks that are key value pairs that are broken up into smaller chunks That we call a region internally in our documentation and each region is replicated using the raft consensus protocol Right now the uh, just so you know the default size of these region is 96 megabytes But you can configure that however you want depending on your use case Underneath each of the boxes is a little leopard which also signals It's a rock cb instance. So what we leverage rock cb quite a bit each Tai KV instance has a rock cb instance Underneath it and rock cb is a storage engine that was first created By facebook actually leveraged level db from google originally and it's still maintained by facebook And it's a very battle tested storage engine that both Tai KV and a lot of other database products use as the storage engine There are a couple of cloud native projects that we Use by default as well We use grpc as the communication layer between different components. We use prometheus as the you know basically the metrics gather of everything that's going on in Tai KV And we built Tai KV using rust which is a relatively new system language that is getting a lot of popularity a lot of enthusiasm and You know, we actually started using rust before it was even 1.0 Which was an interesting bet at the time But we definitely benefit a lot from that choice and have gained a lot both working with rust the language And also with rust the community. So that was a very fortunate choice on our part next slides Here is some basic community stats that we've gathered since joining cncf And as you look through them a lot of the details are in the dev stats dashboard as well But one thing I just want to mention and emphasize is the contributor count This is the number that I got Just this morning as I was preparing to to you know polish up this slide We have about 150 contributors and just so everyone knows only So we only have about 20 people working on Tai KV at pincap Which is the company that originally started building Tai KV. So the contributor I think community is very very healthy very diverse And there's a lot of other people that are really invested in building and maintaining and improving Tai KV beyond just the folks that are affiliated with the pincap the company next slides And here are some of the other kind of more community building progress that we've made since joining cncf We have formalized a governance document. We have a best practice batch from ci i There are actually a lot of new features that we are working on in Tai KV as they approach us 3.0 Which is the big next big version that we are working towards But two of them that I will mention that I think is interesting to this group one is batch messaging in g rpc we use a lot of g rpc in Tai KV and Batch messaging is a new improvement that we are working on to really alleviate some of the performance bottleneck As your system becomes more complicated and as there are more components being developed or being deployed rather in your cluster to batch messages When the receiver side is too busy, we would actually you know not stream all the messages and actually batch them depending on the busyness Of the receiver. So that's one improvement And another one is multi-threader raft store So as your system gets bigger as you have a giant Tai KV cluster Which is how a lot of our users are deploying Tai KV the raft communication You know to ensure consistency and high availability does become a bottleneck as well So we are providing a new improvement where we can multi-thread a lot of the raft communication to alleviate You know that performance bottleneck which has seen quite a bit of improvement in terms of performance already in our testing We have a new maintainer now. His name is Xiao Guang Sun. He is from Zhi Hu.com Which is a very popular internet company. It's essentially the Kora of China If you will both in terms of its use case and also in terms of its popularity perhaps So he is now a new maintainer that we have exercised our new government's document to elect formally into the Tai KV Project and the last set of bullet points that I want to spend a little time on is this ecosystem That is already forming around Tai KV going back to the original vision that we've had to have this be a building block So since joining CNCF we have discovered so far three separate Redis on Tai KV Open source projects just by folks who wanted to build that They're called Titus Titan and Titia is my best interpretation of that name and there is another Prometheus metrics into Tai KV project as well. That's been fostered in the open source community called Tai Prometheus In fact, this project is mentioned in the I think the official Prometheus documentation as one of the options for remote endpoints and storage for both read and write So in a pretty visible way and there's more that we can do here Still this vision of becoming part of the cloud native landscape You know to be a building block is really becoming a reality in some ways Next slide And in terms of adoption, we have a full list of adopters that is available for everyone to check out on our github Repo, but here are just some of the large ones that I will mention for the purpose of this presentation One is union pay which is I think probably one of the largest kind of digital payments and credit card gateway out there For those of you who will travel a lot, which I think is very much this group. It's a very well traveled group You'll probably see this logo in a lot of the fancy shopping stores and international airports as you do your transfer Ping An is one of the largest Internet or sorry insurance and banking institutions in asia is also an adopter of tai kv I believe Ping An technology is also a cncf member as well Book my show is probably the top three most transacted website in india It's a very successful internet company over there and the core use of that is to book movie tickets Bollywood shows and other entertainment in india. That's also a tai kv user And the shoppy is one of the most popular e-commerce platforms. They're based in singapore They're part of the sce group. I think and they have Their business throughout southeast asia and pretty much all the countries in asian as well So these are just uh, some of the some of the more notable Adoptions that I'd like to highlight and the core use case here It's still a combined use between tai kv and tai db, which is a sequel processing layer that's also Open source that speaks to mysql compatibility and you know with those two things together You have this relational distributed database that is easily horizontally scalable next slide But what I also want to note is that there are a lot of tai kv only end users That are adopting this project as well without really anything else That goes around with it Some of the ones are jd cloud, which is jd.com's kind of public cloud platform Elamy is a uber east of china if you will both in terms of its size and in terms of its business And uh, dren dren the little pic in the middle. It is a very popular They call it a recommerce platform. So it's kind of like secondhand commerce platform, you know People to people similar to let go which is analogous company that I think is based in europe But relatively popular in north america as well. So dren dren is a version of that and may two Which is on the bottom right corner. That is a public company. I think listed in hong kong That makes a or started making a very popular Selfie filter to make you all look really pretty in your selfie And that is not something I can speak to personally per se But it is also a very very large ty kv only user all these users have at least Five terabytes of data in their ty kv cluster either serving production data directly to their application Or to store metadata of other data Next slide So as we move into uh, the incubating status, hopefully with your support There are a lot of things that we are looking to continue to improve and strengthen the ty kv project and the community Some of the things that I have listed here is to make a home chart and operator for ty kv itself So using ty kv on its own can be more easily Deployable and manageable for anyone who is in the kubernetes setting And one of the things that we recognize that there's still more that we can do to foster more Contribution from the community at large So we have done a lot of work to contextualize the labeling of a lot of the issues that we have In ty kv things like help wanted or mentor, which means if you work on this issue You actually have one of the core ty kv members Mentor use throughout the process as you get through it or easy if you want to pick up something relatively You know easy to chew on to get your You know mojo going if you will and the screenshot I took here is a open issue still that has some of these labels Just ended as an example So if you want to pick that off right after this presentation, I will not be against it And the reason we're doing a lot of this is that because we use rust, uh, you know as many of you know It's still a relatively new language The learning kind of curve for rust is relatively high And being one of the largest rust production projects out there We want to do a weekend To lower the barrier of entry to that as well by being good stewards of the ty kv community and to bring more people into our community And other things that we can do is to further diversify our Maintainership, even though we have xiao guang from zhihu.com already They are more that we can do to bring in other diverse maintainers from other institutions as well as having a much clearer roadmap with targeted release dates and more areas that we can do to improve next slide So this is just a list of resources that you can check out to a further evaluate ty kv for incubating Status review and beyond that what there's websites twitter slack reddit I've also linked the incubating pr that we found Which i'm pretty sure has now a link to the technical due diligence document that xiao li from the toc has Drafted with the help of the storage Working groups so really appreciate everyone who has already done so much work to do diligence on ty kv As we move forward with our incubating review So with that I will wrap up and either take any questions or we can do that offline in the documents as well any Questions or concerns from the toc uh for ty kv to move to a formal incubating boat Uh, hi, this is sugo. Uh one quick question that uh, I just thought of How many do you know how many kubernetes instances run ty kv? Um Either and if so, what do they use? Do they use an operator or do they use custom deployments? Right, so the ones that we know of uh, and unfortunately we aren't allowed to share all of them A lot of them use this operator As the way to deploy ty kv along with other components in a kubernetes setting Oh, are they uh, are they uh, is that open sourced or are they did they develop their own? So the ty db operator is open source and that of course, um, you know Deploys both ty kv and other parts of ty db, but like I mentioned in the slides We are working to you know, either work with a community or get other people's help To develop a operator or a home chart like deployment for ty kv itself But yes, the current operator Implementation is all open source and you can you know find that fairly easily Cool. Thanks. Yep Or you can look at the chat window Chris already asked the question in chat, but um verbally any objections to going to the vote on this? Oh, if there's no, um, I will go kick off the vote after this meeting Thank you, Chris. Thank you, Kevin. Great presentation. Thanks, Les So open ebs All right. Thank you for having us Hopefully, uh, everyone can hear me. Okay So this is ebb and powell and it's going to be myself and kirin. We're just going to pretty quickly, uh, introduce the group to you know, what is open ebs? And uh, and so forth um Just a little bit Even before I get into this about background The company behind open ebs is now called Maya data And if you double click on our backgrounds a bunch of us helped Or tried to help create the software defined Storage market some years ago um, and one observation coming out of that market was that Something called vsan ended up winning which is uh was not Really the intent initially of the creators as far as I know of v sphere and vmware But this approach of turning the orchestrator if you will Into a storage layer itself ended up being really quite broadly adopted and and today is a Is actually a pretty big piece as I understand it of vmware's business And so at the highest level You can think of what open ebs is doing is Is leveraging kubernetes itself to deliver storage to kubernetes You can learn more about us at these different resources We have been running our own dev stats as you can see Now that'll I think Be over on the cncf side So there's there's quite a number of non Maya data contributors. We are about 60 of those to give you an idea We have about 60 engineers In the organization And a quick comment I would say, you know, thank you to Alexis Thank you to saying thank you to Thank you to That's my lexus just popped up behind me Thank you to alex from the cncf SIG storage SIG community and a whole lot of others who have really Helped us understand a little bit better. Chris would be a notable one And he would spend time with us to kind of Coach us and direct us sometimes correct us as we uh As we're over enthusiastic Early on but it's it we've got a gotten a lot of mentorship from this community. So thank you The next slide please So what is it as I kind of alluded to? Um And as the name suggests it's it is block storage and it and it does run within kubernetes And it does use What's there available? What could that be that could be an existing sand? That could be cloud volumes that could be disks or SSDs etc that are bare metal connected And it presents those up as block there is within the community a Let's say slim down NFS engine that is used sometimes on top But we're best known for as it says replicated block storage Yeah, you know, it's kubernetes native in many senses and so it can be deployed quite easily quite quickly As well and we did make an early decision to Of course architected as being In the user space And that was in order to make it again easy and easy to run anywhere We we tend to call the category container attached storage um, I will say At times I've had flashbacks to the early days of software defined storage where We started talking about software defined storage and every hardware vendor in the world said that's us too So, you know cloud native is one of those terms that That has been embraced by I think all almost all vendors So we tried to define it a little more specifically as container attached storage So I With some input from the community Have written a couple blogs about that And I would argue that Alex's Company and some other companies fit into that space as well. It's not simply open EBS There's a number that take at a high level a very similar architectural approach With that I'd like to hand it over to Kieran who kind of will walk through the how and the architecture here Thanks, Evan. I'll quickly skip these two slides that we have This just goes on to repeat what Evan said We make use of Kubernetes as much as possible for orchestration The core functionality of the storage controllers is the one That's part of open EBS. And that's what we call as storage controllers or targets Those are packaged and delivered as containers and orchestrated by Kubernetes itself The functionality that's provided by these storage containers Typically is what you get from enterprise storage in terms of storage management expansion High availability data protection, etc to there's a blog that Evan submitted about container attached storage. I've provided the link here So we go to the next slide, please Some of the examples for this kind of storage, it kind of falls into the hyperconverged storage topology that the storage working group submitted the right paper Open EBS is one of them. So some of the other products like portworks or storage or is natural on The way this differentiates with the rook is rook is mostly an orchestration control plane that could actually orchestrate any engine could be self or open EBS also could be plugged into that one I'll do the next slide, please This one actually has a little bit of an animation this kind of cues and overview of how open EBS works Yeah, please keep clicking through There are two personas that we have defined one is a cluster administrator and the developer the cluster administrator is the one that Sets up open EBS. So as part of installing open EBS, you start with a Kubernetes cluster click through please Each of those nodes can come with Additional disks This is what we call as the storage attached to the nodes itself as part of the open EBS installation We have something contest in node disk manager that discovers all these disks And makes them available for operators or administrators to create what we call as storage pools There are multiple pools that we support in this example. I've taken the example of a c store pool. Yeah, please click ahead Go ahead So the administrator picks up some of these disks and creates a storage pool cluster that Basically runs a deployment with a number of replicas on each of those nodes Next These are called c store pools. Keep clicking this And then the administrator defines a storage class that Allows the users to use these open EBS volumes. So the developer doesn't Have to do anything specific to open EBS. They just have to use the storage class defined by the administrators. So whenever a New open EBS pvc request comes the operators of the open EBS will Launch new parts to Deliver a block service. So in this case because it's c store a c store target is launched and A logical volumes are created on the different storage pools click please In this case, let's say like the application required high availability and the user can actually the storage class defines how many number of replicas you want and the They get provisioned with anti affinity feature of kubernetes itself Then it in this case it exposes iskasi. So it connects to the Through the application node via the kubernetes iskasi pv Click please. Yeah The one of the cool things about this is the uh c store target itself is Completely stateless and that's the one that controls the i o. So if node one Goes down the c store iskasi target part just gets rescheduled onto Another node and connects to the available replicas and starts serving the data and c store target does a synchronous replication Next one, please So it's We have a helm chart available for open ebs under the stable Charts, it's a single click install and installing the Applications via helm can also just make use of the default storage class that shipped with open ebs or administrators can define new storage classes and can provide them to Different types of applications. So one of the cool things about open ebs is also that it provides different configuration parameters For example, if you are running a mongo dp which can do its own replication The storage class can be defined to have a single replica or actually And The stateful set will make sure That each of the replicas are on different nodes at the same time the open ebs will make sure the data that's coming to each of these mongo dp is coming from different nodes What I show here in the right side is a diagram that's actually generated from the view scope Application Everything in open ebs is implemented as a Kubernetes native resource So they either with custom resources or the deployment of the services that are already available So this can be integrated into any of the Kubernetes tools that we have Prometheus grafana or even like the view scope kind of projects Getting into a little bit of a high level architecture here In the pr I linked to a Detailed architecture which we presented to the storage work group at a high level The open ebs consists of two types of components one that run at the cluster level Which are basically the operator The equivalent to csi controller and the node device operator that makes Sure that devices are not used by multiple components. It basically maintains the storage device inventory management And similarly there are node components that work For example, like the storage cistor pool that we saw is one of the node component And in the next slide, I just have one example of how the cistor volume target works So If an application node that Kind of triggers the creation of a cistor volume target The multiple replicas connect to this cistor volume target via a service Which is a cluster IP and even the application nodes connect to this target via service IP So even if the cistor volume target moves to a different node, you Basically don't have to change anything at the application layer to connect to this data It makes use of heavily different patterns of Kubernetes Volume target consists of the core data processing logic There are sidecars that kind of attach to this that help with managing these volumes or even like exporting the Metrics etc So open ebs itself is a Global organization that has a bunch of different projects So In the two slides above which define the architecture each of those cluster level components and all the data engines are Available in different repositories under the open ebs These are the ones that we are planning to submit to cncf Uh, there are currently a few more projects that we have under open ebs open ebs repository Open ebs organization that we forked and kind of used for example, we use copies one of them So as part of this process We will identify the projects that really belong to open ebs and We'll submit those things and the remaining we will move into a different organization So this is just a current status We started sometime in the late 2017 and right now we are at 0.9 release. We have some production users running open ebs at the moment The immediate roadmap it's mostly day two operations that we want to focus on and some performance improvements as well We are getting a lot of requests in terms of supporting the Edge use cases support for that kind of stuff It detailed or a lot of backlog items are kind of maintained in the milestones There's a lot more work in terms of grooming them all that We typically use travis itself as a ci platform today It does the testing and my data has set up a open ebs ci is similar to cncf ci that helps with testing across multiple platforms as well right How are we aligned to the cloud native community? It's tightly integrated in the kubernetes and follows the principles in terms of being an open source and open architecture It's a scalable horizontally scalable with the nodes The storage can be expanded to all the nodes that are in the cluster or it can be kind of dedicated to some of the nodes It does well in terms of integrating to other cncf Projects like kubernetes, prometheus, etc that i mentioned here, but even the other projects that are in the sandbox right now correctly Why do we want to submit to cncf? There's been a lot of interest in from both collaborators that want to help with some of the component projects in open ebs for example like the ndm itself As well as people who build solutions with using kubernetes and all the other components We want to provide an application a complete stack with using the cloud native projects And they would be feel more comfortable to innovate on open ebs if it's a vendor neutral organization That's a primary motivation So far I would say like you know just having proposed here we've been getting a lot of good feedback that's have That has helped us to fix the governance part for example and For some license checks, etc looking forward to more improvements in terms of governance Any questions that I can take at this point? I think that was the last slide from my side anyway Has anyone had any really bad experiences with open ebs? Oh, so I think the concerns that have been there mostly were in terms of performance. They Would ask for How do we tune this to get more performance that kind of stuff? And in the early on when we were using the early versions of the kubernetes since we depended on the Kubernetes to reschedule the pods We had to tune the tolerations, etc Without that It would take more than 30 seconds to kind of reschedule or even longer That would mark the open ebs volumes into read only that was one of the earlier things that we had fixed The thing that I'm not sure of any bad experiences We have a pretty vibrant slack community that You know people come to ask questions and we've been very responsive there the community has been responsive I have another question which is around the dependencies on external storage. This is something that came up with roc um Is cstore your main default? So we actually have architected open ebs to work with multiple engines So it currently works with gva cstore as well as uh local pvs For example, indium has the capabilities to manage the disks that are attached so it kind of augments the capabilities that are provided by the kubernetes local pvs itself in terms of data operations or management of those Stratable applications that are running on local pvs. So cstore is one of the components one of the data engines that we support We've had the production users uh on gva as well for Quite long time because that was the first thing that we supported Yeah All right, thank you. Thank you I Mean you know it's it's sandbox and I think they've they've done enough for sandbox. I mean I have I'll go on the record I'm really worried about any storage project. You know the Brian has left us and moved on to non-toc projects But he's left us at a long shadow of the doubt around all things storage and we just need to be super careful not to mislead users There's just so many things that can go wrong I think we just need to have a slightly higher standard for any anything to do with storage and it just came up again Rook and we just need to be very careful. So I really really like it if a few more eyeballs came onto this I feel much more comfortable I think from from all of the all of the other stuff that I've seen it's it's done well and I got involved because we'd collaborated with the team successfully. I'm very happy with how that went But it would be great to get a few more people maybe shank could comment on on the storage side of things And I think it's important to note that it's Primarily different than Rook and that it's not a privet necessarily just a provisioner Rook was a facilitator Whereas this is a more of a storage technology So I would agree I'd like to have a little more diversity in terms of which ones are actually providing storage rather than Rook, which is just a high-level provisioner. So Because to me it feels very much just like any other block storage. Maybe I'm I'm missing something there, but Um There are several in the kubernetes landscape already so cool. I think we're uh over time and Thank you. Open EBS Yes, we'll work with work with them over time. Cool. Take care. Bye. Thank you everyone Bye. Thank you