 Hey Paul are you are you out there? Good morning everybody. I think we'll wait probably about three minutes four minutes to get going. That sounds good. Happy new year. Yeah happy new year to you man. Hey Paul are you uh are you out there? Does your audio work? Uh yeah I am here. I can try to share my screen and we'll see if that part works. Yeah if you want to just give that a shot. You know we usually have 10, 20 people so I'm gonna give it a couple more minutes but yep that's looking good. I can see it. All right excellent. Cool. Unfortunately I won't be able to stay for the whole meeting. I was mistaken about the time of this meeting so I have a conflict towards the end but I think it should be fine. Yeah I think that's all right. I have two things on the agenda for the meeting today and uh so this should be maybe like 20 to 20 to 30 minutes if that's all right with you. Yep that's what I plan for. Okay excellent. I just don't want to be that guy that like takes it off faster. Yeah no problem. I think if we plan for like 20 then we add like five to 10 minutes of questions that would probably be perfect. A little bit low on the attendance but you know we're recording this so we will definitely send it out to the whole group once we're done. We'll get kick it off here so Ben's not gonna make it. He's got a conflict so I'll be uh I'll be chairing it for for this morning. On the agenda today we have a couple things. One is to talk about the open service broker API so we have Paul Moray from Red Hat. Thank you Paul for joining us and then the second thing we have in the agenda is to have a little discussion about the the test presentation that we we saw in the previous meeting a month ago. So at this point we hand it over to to you Paul and take it from here. All right thanks a lot Clint. So hey everybody my name is Paul Moray. I work for Red Hat on Open Service Broker API and different things in the Kubernetes space. The most relevant to this one or to this conversation is a Kubernetes service catalog and I'm gonna give a short talk today about cloud native storage and Open Service Broker API. So as as far as our agenda for this little talk goes, first I'm going to give an overview of the Open Service Broker API. I'm gonna call out the touch points between Open Service Broker API and storage and then I will give some examples that I know about cloud native storage type applications that are implemented or integrated with Open Service Broker API. So the premise of Open Service Broker API and its value proposition is that users and applications need access to usually say services and resources but since this is the storage working group I'm also going to call that storage is the thing that they need access to and those of you that have history of working in large organizations may be familiar with lengthy and sometimes convoluted procurement processes to get new resources or services provision and the value proposition of Open Service Broker API is that it lets a service provider integrate with multiple platforms with a single API that allows users of those platforms to in an on-demand fashion provision new instances of a service whereas service is just some capability and we'll talk a little bit more about that in a moment but it allows users to provision new instances of things and to bind those instances to their applications where of course an application might be something at the like user-facing application level it might be something more infrastructure it runs the gamut so the Open Service Broker API itself defines an HTTP interface between a platform and entities that provide a set of capabilities or services that we call service brokers and a service broker is a component of a service that implements the Open Service Broker API so to put that the canonical example that we use when discussing this is that is that the say for example that a service might be a database as a service the service broker for that service is the thing that knows how to provision new instances of that service and how to create new bindings to instances so I'm going to talk a little bit about the operations of this API and because in my professional life I work on the Kubernetes Service Catalog which is an integration between Kubernetes and Open Service Broker API I'm going to do that in the context of Kubernetes Service Catalog a brief history lesson before we begin Open Service Broker API it started out as the Cloud Foundry Service Broker API it has gone through a couple of major revisions in its lifetime as Cloud Foundry Service Broker API and in 2016 users of Cloud Foundry were coming to the Cloud Foundry folks and saying we like this idea we want to be able to use this from other platforms and at that point it was decided that the right future for the API was to become something that was more open than just the Cloud Foundry community and so a new working group was created, API was renamed and since then we've had folks from RedHatch, IBM, SAP, Google, Pivotal all working together to evolve this API and make it more platform classic. If someone could mute their microphone there's some typing. Hey Paul that was me could I get you to hold on just one second so apparently the invite and an invite went out yesterday and it made a new zoom call that some of the folks are on and that's why we have a low attendance so that was me. I'm happy to start over we're not we're not very far in if that's what people want. Yeah if you could just give me just a minute I think some of these folks are gonna join over here okay sorry about that no problem and I promise I'll mute and you won't hear the tornado of keys being typed Hey Aaron are you out there? How many folks were on the other call? Okay cool there we go now we got everyone joining. Hey folks thank you for joining sorry for the confusion there was an invite that was sent out yesterday and I was not aware that there was a new zoom link that was put into it so we'll make sure that we we figure that out we won't run into that in the future so right now we're on the old zoom invite which is in the meeting minutes. Today I would be chairing this because Ben isn't able to make it but we've got a couple items that are on the agenda in the meeting minutes. The first is that we have Paul Moray from Red Hat and he's going to be discussing the open service broker and and how this fits in this cloud native storage world that we've been discussing and second we've got an item to discuss that the test project so it looks like we're getting a more of a quorum here which is what I was expecting so you know thank you guys for joining again sorry for the confusion and let me pass it over to Paul to kick it off once more and talk about the OSB API. Thanks Paul. Thanks Hello everybody my name is Paul Moray I work for Red Hat on open service broker API and different things in the Kubernetes ecosystem and I'm going to give a short talk today about intersection of cloud native storage and open service broker API so our agenda today includes an overview of the open service broker API call out of touch points between storage and open service broker API and then some examples that I am aware of cloud native storage type integrations via open service broker API so the the value proposition of open service broker API is that users and applications need access to capabilities like storage services and other resources and those of you that have a background working in uh mid to large size corporations might be familiar with the sometimes lengthy and convoluted processes for requesting that a new resource like a service or a storage volume getting a chassis rack whatever the the processes around those can be lengthy and convoluted and definitely not in an on-demand type metaphor so the value proposition of the open service broker API is that it provides a way for providers to create components that know how to provision new instances of capabilities which could someone mute their microphone please the the API allows service providers to provision or create components called service brokers that know how to provision new instances of resources and how to create new bindings to those resources so the canonical example that we have for explaining this metaphor is a service might be for example database as a service and the broker that provides that service understands how to provision instances of that database as a service service and how to create new bindings to that service to be used in applications so the API itself defines an HTTP interface between a platform and these entities that provide a set of services which we call service brokers and a service broker is the component of a service that implements the open service broker API and has the knowledge about how to provision bind to unbind from and deep provision services so before I proceed as I mentioned before I do work on things in the Kubernetes space and since that is the the integration that I'm most familiar with I will be explaining the open service broker API operations in the context of the Kubernetes service catalog there there's also a lot of lengthy and high quality documentation for folks that have a background in cloud foundry for the exact integrations between cloud foundry and open service broker API but we're going to talk Kubernetes today because that's most most familiar to me as I said the Kubernetes service catalog is an integration between Kubernetes and brokers that implement the open service broker API it is shaped similarly to Kubernetes and as a user of the Kubernetes service catalog you use API resources that will feel very familiar hopefully if you have experience in Kubernetes and that allows you to to provision new instances make bindings to them without having to interact with the open service broker API directly that's something I want to call out as a point of moderate confusion sometimes in in our community that the open service broker API is really meant for platforms to integrate with rather than end users so let's take a look at yes let's give you a slide here let's take a look at the fundamental operations of open service broker API the first one and most fundamental is that a service broker has to be able to tell a platform what capabilities or services it offers so there is an operation to get a broker's catalog central to this discussion is provisioning new resources so there's an operation called provision and that is an operation that creates a new instance of a service or a resource to consume that an instance of a resource or a service in an application there's an operation called bind that will for services that implement it allow the broker service broker to return information like credentials coordinates quality of service settings for applications that want to use a service and then provision and bind have symmetric pairs to undo them so there's an unbind operation in a deprovision operation that remove a binding and deprovision an instance of a service respectively so in the context of Kubernetes service catalog which is very very similar to in terms of the generalities of the workflow to use this API in cloud foundry the first step is to add a service broker to the catalog you do this by creating in Kubernetes service catalog you create a cluster service broker resource and that tells the service catalog that there is a new broker to consume so what happens after you create this resource is the server the controller backing the service catalog API is watching the API and says hey there's a new cluster service broker that I want to consume I'm going to go call that the catalog endpoint and we do have some unfortunate naming collisions in the space so I usually try to be very good about disambiguating them if there's a question please holler and we'll disambiguate it but the catalog controller calls the broker's catalog endpoint and gets back a payload from the broker that says I have I present services a b and c and these are the different tiers of those services and transforms this payload into resources called cluster service class and cluster service plan and persist those back into the service catalog API server at that point a user is able to browse and see what services that broker offers in the catalog and say in the context of our database as a service example they say ah database as a service well I need a database and they want to provision a new instance of that database what happens at that point is that they create create a new service instance resource and that resource has information about the the service and tier of that service that the user wants to use you can pass parameters to service instances to set knobs that that service allows you to set the catalog controller handles communicating with the broker and calling the provision operation on that broker the broker does the work of actually provisioning the resource and reports back status to the caller saying I either did this or I accepted your request and I'm going to do it asynchronously or I failed to do this so forth the broker does the work of actually provisioning and catalog controller just updates the status of the resource to tell the user your resource is being provisioned or it's already been provisioned etc now when a user wants to bind an instance that they provisioned of a service to their application they make another resource called a service binding and the pattern should be familiar at this point user creates a resource there's a controller that backs the service catalog API that detects that a new service binding resource has been created it calls the binding operation uh on the broker for that service instance and passes the parameters just like with provision you can pass parameters to bindings um broker handles doing the work of creating that binding and passes back a set of credentials coordinates configuration to the caller and in the case of Kubernetes that information gets transformed into a Kubernetes secret that uh users can consume in their applications just like they can with any other type of secret so next steps that are relevant to this audience are there are two that I think are are probably going to be most interesting to folks in this audience one is the concept of API extensions or generic actions which are intended to allow broker authors to extend the API dynamically with new actions the the canonical use case that we have for this is that this API as you have noticed does not have operations for backup and restore it is very difficult to get folks to agree on the details in a specification like this for what certain actions should entail and what types of parameters they should accept etc so I would say perhaps one year six months ago the idea started getting traction in our community that there should be a way to add new operations that allow people to prototype new extensions to the API and add capabilities to their services that are possibly unique to their particular service and perhaps implement some other specification that they can link to but the idea is that you should be able to extend and add new actions to this API without having to go through a lengthy process of actually making a change to the spec the other thing that I think this audience may find interesting is the concept of a binding output schema right now there is no way no first class way in the API for you as a consumer of a service to know exactly the pieces of information that you will get when you bind to an instance of a service the binding output schema will allow brokers to publish a some sort of schema that says when you bind to this an instance of this service you will get these keys that contain this kind of information these keys x y and z key in particular have sensitive information in them so you should treat them as if they had sensitive information and basically expose to the user and allow user interfaces to be created that communicate to the user what type of information they're going to get from a binding I have two more short sections of this talk but I'm going to pause here to ensure that any questions folks have can be answered now hey paul this is basama quick question so is the primary goal the definition of essentially services that can be provisioned across different container environments like or different platforms like cloud foundry and kubernetes and and others or is the goal is this a kubernetes specific uh you know broker uh so that's a really good question um the uh I'm sorry the pause is because I started giving this talk before um before we had just sorted out the uh the meeting link and I'm now wondering whether I skipped some content uh about the history of the API and uh since those the memories of the two versions of this talk that I've given uh in this hour are kind of mixed together can somebody give me a sanity check that I discussed the history of this API here I've not seen it yeah not too much fall and uh we've got another thing on the agenda too so I think if we could probably cover whatever we want to within the next five minutes that would be fantastic okay that that is very possible the short answer is that open service brokerry api is not kubernetes specific uh it started out as a cloud foundry api and uh users of the cloud foundry service broker api in 2016 we're coming to the cloud foundry folks and saying we like this concept we want to use it from other platforms so what I've presented here is just uh an explanation of the api mechanics in the context of kubernetes because that's what's most familiar to me as far as individual brokers go uh there are some brokers that uh that have a that are designed to work in the context of cloud foundry and there are some that are uh designed to work in the context of kubernetes and some that that have an interrupt story but there's kind of a spectrum does that answer your question yes I I guess I'm just struck but you know I how do you think about the pattern of that kubernetes around custom resources and you know essentially the operator controller pattern around those uh vis a vis open service broker that that's kind of what I was trying to sort out of my head okay um I think that might be something to uh talk about offline sure if if you want to send me an email we can discuss that uh for now I'm going to get through the rest of the presentation and perhaps that might clear up some questions great so touch points between open service broker api and storage uh there is a notion of volume services in open service broker api however uh this is this is a some uh feature that's very cloud foundry specific it predates the time when this api was called open service broker api and as far as I know cloud foundry is the only platform that implements support for volume services um in the future uh changes to the api like the bind response schema may make it easier to implement uh integrations for storage volumes but despite uh this information that I told you there are already brokers that provide access to uh different cloud native storage like capabilities already and when I say cloud native storage I am not an expert on cloud native storage but uh when I say it what I think of is uh interoperable storage that you can perhaps find something in your cloud of choice or in your environment of choice that will have parity in some other cloud or environment so you have some kind of interoperability and portability between environments um some projects that I am aware of uh are there is a uh a broker called the open sds broker that creates seph compatible volumes so the the services it offers are a uh like volume as a service so you can provision provision a new instance of this and get a seph compatible volume created for you by open sds there are also a few s3 compatible brokers so there's a cns object broker that creates an s3 compatible object store erin boyd on this call is somebody that you can get some more information about that broker from there's also a minio broker which I am not sure whether this is actively maintained at this point but it is another broker that creates an s3 compatible object store and then uh there is an aws broker uh based on uh red hats ansible broker that creates s3 buckets uh using the aws api um the minio one isn't necessarily maintained but we validated it worked we also worked on that call this is erin so we can at least get it to someone that's interested okay um and that that is the gist of it uh I think maybe we have one or two minutes left uh for questions but I'll defer to Clint on that one yeah that's that's okay if you guys have any questions feel free to uh taskball I threw one out the chat but I'll say it here um one of the things I'm looking for the entries to have is not just the service name but sort of its schema you talked about that but also the level of service that the instance is providing so I might have you know different object or storage brokers for instance that provide different levels of service for the same you know self-compatible volumes for instance uh so if I I typically do uh presentations on the subject with a little bit more time one thing that I glossed over uh but touched upon I'm not sure if uh if I touched upon it enough but there is a concept of a plan for a service a service has at least one plan and a plan is a tier or level of that service so one thing that you can use plans to represent is different levels of quality of service so like you may have in the case of a database as a service the the bronze plan may be a table space in a multi-tenant database and the platinum plan may be a dedicated database just for you with high high ops and performance characteristics is that similar to what you're looking for yes perfect excellent hi I just want to add that OpenSDS supports block storage so um self and also you know iSCSI blocks storage in general and we are planning to support file and object in the future awesome all right cool so uh to be respectful of time for being able to talk about the tests I want to close up questions for now if you guys have anything else please send a question to the swg uh google group and um you know I can point Paul to that if something comes in around the open service broker yeah so thank you Paul for presenting all right thanks a lot for having me see everybody all right uh so next on the agenda is the tests um I think that uh Brian are you out there yes okay great I think that you filled in some of this agenda is that right with uh so uh we were on the other zoom channel at the beginning and I so that was just the intro I was giving just saying here for Q&A if there was any follow-up from previous discussion great fantastic so let's let's get into this um so on here we have Brian to to be able to answer the question questions about the tests the test is a project that's been presented to the TOC I think back in May or June or July of last year uh we just had a presentation on it last week and or not last week but the last meeting that we had uh so I think we want to open up to the group to to ask any questions or make any comments about you know what they feel about the project and how it relates to the cloud native ecosystem that's all do you have something uh no I I actually submitted a bunch of comments on the poll request itself um so I'm I'm okay okay um so something that I noticed Brian went during the presentation is like I think it you know the test that solves an interesting problem in terms of like highly scalable uh mice environments uh but the thing that was was missing I think a little bit was you know what is the what does it look like to actually deploy like what does it look like to deploy the test with with kubernetes like you know what is the user experience uh you know how how automated is the lifecycle of having that platform sit within that environment um and I think at the time that the answer was hey that's interesting we should look at it do you have any any perspective on that or or what you think or how important that may be to to this kind of project um yeah so the the test has internally internally to google runs on borg much like pretty much everything and uh the open source also was made to run on kubernetes actually very early um in kubernetes existence uh so it's actually been running on kubernetes for years and I think that's what the primary way um that it's being used outside of google uh at this point there is a pretty uh significant uh community around uh around the tests uh in terms of how automated the lifecycle is I think it is as far as I know um fairly automated there are some things which like resharding uh which may require you know some amount of uh operator work but uh you know routine things like instances being rescheduled just have to be automated because that sort of thing happens in borg all the time um in fact it happens more often in borg than in kubernetes uh kubernetes cells even if you run kubernetes on preemptibles preemptible VMs or spot instances or something like that I think the rate of and it's a pretty less than it would be on borg um so the way I see the test is it's a bridge for applications to cloud native and that's how it started you know youtube started with my sequel and then it just had explosive growth and then it was acquired by google and moved on to borg um and the test is what made that possible so hey brian one one question I had about that so that I saw a kubecon talk about a mysql operator mysql controller that oracles supposedly open sourcing in the next few months um are you guys is the test team working with them um or are there any plans there to for that to support the test I don't know if the the test team is is working with them specifically and the the test has a lot of capability that's not in fact the only mysql operator but there are a few mysql operators they're pretty simplistic in my opinion and the tests you know obviously have some more advanced features like sharding but um you know it's also pretty production hardened and heavily instrumented for cloud native uh operation so you can tell what's going on in terms of the monitoring and the logging and whatnot um you know it has a lot of operator miles on it and the mysql operators really can't be compared to that but it it doesn't actually have any any of the operator patterns in it though right uh well as some operator patterns and that it's and which operator patterns I guess yeah I think I think ambiguity or is the word operator uh so I think Clinton's asking about like the crd's and controllers uh yeah it doesn't use crd's because crd's are brand new right but if you fire it like in the case of a mysql operator right it's going to be a you know upon the controls a lifecycle of everything in the case of the test it seemed like it was pretty much a manual deployment as you scale out different nodes and it doesn't have integration against the kubernetes you know to act as a controller or an operator maybe I'm misunderstanding it but it it seems like a very manual process to do any of the scaling um yeah I'll follow up with Subaru on what the the current state of that is okay and that's the that's the thing that I saw Brian with Oracle announcing that they're releasing a controller and crd's and everything around mysql that's the that was the link that I saw there and is it worth marrying the two or there's going to be a separate effort there yeah I think if you had a highly scalable um but also you know you know where you're integrating and acting as a controller yeah that's a great solution and we also have any any other anything else I want to talk about with the tests any other questions what was the uh Brian what was the the other project that um um that you guys were looking at like the new sequel project that was that was the the step after the test for youtube um but you is actually moving to uh google internal storage systems um in terms of c in terms of cncf uh um cockroach tv actually presented uh quite a while ago over a year ago um to cncf right now there didn't seem to be a lot of interest from them moving forward uh that's us you know a spanner like uh open source spanner like system um so are you saying that uh cncf didn't have interest for cockroach or cockroach didn't have interest in cncf uh the ladder got it okay uh how behind the scenes in google like maybe you can or can't talk about this but the you know the the sequel database is like the mysql database that you guys have like how was that operated the cloud service you guys provide if that's spanner oh the cloud sequel yeah uh good question it does not use betas um i'm off pan i don't actually know why that is but uh it done currently has gone through a few iterations it currently does use mysql behind the scenes i don't actually know what the current details are okay fair enough all right um yeah i don't have any more questions anyway i also have to have questions for brand all right if you guys do you know feel free to send them to the uh the google group um i think that you know we'll we'll follow up with an email to to discuss like what the next steps are what we what we feel to get some more opinions on paper and then uh we'll deliver that feedback to the toc with brand okay thank you cool thank you all right so we've got one more thing on the agenda um um the next thing is to figure out what other projects that we want to bring to uh the swg to talk about uh so i have a an agenda item where it's kind of open so we can either talk about it here or uh you can guys can fill in projects that you think are going to be relevant to to share with the swg to discuss and i think that we're open for anything now as you guys saw today you know the open service broker isn't something that we're looking to bring into cncf it's something that we just want to be more rounded and more educated about so we understand you know the landscape and you know what all the projects are that are out there and i think it helps us better understand you know what you know how projects can be relevant and where they fit uh so if you guys have anything that is storage related anything that's going to be interesting to the swg i'd love to love to hear about it so we can put it on the agenda for you know the upcoming weeks meetings hey hey clinton just a clarification did you say uh the open service broker is something that we are not bringing into cncf it's a it's already a linux foundation project i see okay yeah it's under the cloud foundry foundation yeah sorry about that okay yeah and just a quick comment on the open service broker i think one of the ways um the primary ways i see it being relevant to storage is that it's potentially in the future uh one of the primary ways that higher level storage systems could be consumed by applications in kubernetes and other cloud platforms uh whether it's object storage or some you know there are some very common types of services uh consumed by applications running in public or private clouds or container platforms like kubernetes and storage systems i think dominate whether it's you know caching caching systems or databases object stores key value stores or what uh no sql stores or whatnot um you know there are also other services messaging services and whatnot that you might consume but uh storage systems tend to dominate yep i uh i totally agree there and that's why we brought it on today i think that the the user experience uh in what the open service broker you know can set up in what paul was describing today is how i i think that people will want to be able to consume services and i think that that's how we can get applications you know married to to their information and to their data um you know that's what we think about like this orchestrated storage platform box that you know steven team had been thinking about uh you know something like fit tests i don't think that it's an orchestrated storage platform today because it you know it doesn't have like it doesn't fulfill like the controller pattern or the operator pattern um you know it could but another check box you know in that area is to think about um you know whether something actually does integration to osb because if we want to you know have a platform that's highly scalable you know automatically managed by something like kubernetes uh and then we want to also make sure that there's a user experience which is seamless uh then that means that the osb or or whatever you know is in that area is important for integration so yes totally agree all right uh do you guys have any any other projects you want to put up put on the agenda or um yep all right if not we'll call it a day um i'm gonna add some stuff to the agenda if you guys have anything please do fill it in and then uh you know we'll work on scheduling guests to come on and talk about topics so thank you guys very much and we'll talk to you on the next meeting wait i had a question yep um when we were this is this meeting is a cncf storage working group meeting correct correct so when we were at cubecon you described um the plans for three white papers that were going to be done it sounded like on a short time frame yep what what are the plans for those papers uh so we've got the uh the three different ones were the uh cloud native storage volumes white paper the data services white paper and the orchestrated storage platforms white paper um i think that they're on pause until we can uh get the working groups together to to start working on them and decide on a timeline okay cool so on pause for right now all right i just uh thank you okay all right thank you guys very much we'll talk to you next time right thanks