Cloud Foundry Community Advisory Board, 21 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Cloud Foundry October 2022 CAB Call Recording

Description

The topic for discussion is the Interoperator, which helps bridge the gap between Kubernetes operators and Cloud Foundry installations.
Project URL: https://github.com/cloudfoundry/service-fabrik-broker/blob/master/docs/Interoperator.md
Presentation by Anoop Babu and Jintu Sebastian

A

Thanks, hello, everyone welcome to the October edition of the cloud Foundry Community, Advisory Board call it's a pleasure having everybody here today. It's a special month uh this one. So, as some of you have probably heard uh the cloud Foundry Day is scheduled to happen ahead of the coupon this year. So I asked next week um it's a single day Advent. So we have a lot of fun talks prepared for that.

A

It's a good mix of a Bosch uh newer projects like karifi, paqueto and Community updates, and all of that fun stuff um I, would encourage everybody to register it's free to attend virtually so.

A

Excuse me, so you can, you know, join us from wherever you are all of the talks will be streamed.

A

um Obviously, other talks are also going to be available on YouTube right after, but it would be fun to have folks register and attend virtually so uh the big demo for uh today's call is going to be about interoperator.

A

A reason I'm excited about this topic is interoperator is designed to bridge between the Cloud Foundry world and the kubernetes and services world. Services is obviously like a Big Ticket item here at for the foundation and in the cloud Foundry Community generally, uh it's got like you know, obviously, a very important position: architecturally and Engineering wise.

A

um The open service broker API project, which the foundation also helps govern, is again like a big piece of what we do here. So what uh the demo today is going to Showcase is interoperator, which basically Bridges this gap between services and Cloud, Foundry and kubernetes, and things like that during.

B

A

Demo today are Anup and Gen 2, so welcome both of you. An open, Gen 2, are both part of the sap btp team, so the sap business technology platform team they're, both based out of uh the Bangalore office and their contributors to their active contributors to service Fabric, interoperator and all of these wonderful uh tools that we make use of. So you guys want to kick this off.

B

Thank you sure, damn thank you for the intro, and so today we are planning to have a demo for interoperator. So our idea is to have a high level architecture view about like high level overview about what is interoperator, is all about and um going through multiple scenarios and to have a and I know we will take you through a demo and then we can open up for a q, a section um that's what today's agenda is so I will share my screen.

B

um Just a minute I have make sure it's sharing my screen.

B

B

um Just a minute.

C

Yeah I think habits. Sometimes when we update soon uh happened to.

A

Me you have to pray to the zoom gods and the demo gods.

A

So, while you're getting set up, uh maybe I can just fill the silence uh with some very tiny updates about the cloud Foundry Day schedule.

A

So if folks have have not been able to peruse that um this.

A

Is a keynote that we start off with and the keynote is by Catherine McCabe, uh who is on the cloud Foundry governing board, and she also happens to be like the chair of the board. So it's going to be very interesting to hear from her in terms of what her vision is for the community for the various projects, and you know for us in general, I guess um and then the next.

A

um The next talk is by Julian Julian again comes with like a lot of experience with Cloud Foundry as users as consumers as contributors, and things like that. So again, that's going to be an interesting stock for me because it it encompasses sort of what was his experience with, like the older Cloud Foundry stuff, how his experience has been with Bosch and things like that and also goes on to.

A

You know share what he looks forward to and then there's like a like I mentioned, uh a few combination of um Bosch based and pequeto and Curry feet and all of these different areas in general and there's also a talk by Eric who's, part of our Toc and who's like who I like to call like the Gandalf of the CF Community, because he's been here forever, I guess um and then the last sort of segment is like a bunch of lightning talks.

A

So we have four I think, maybe five uh that all go into different aspects of the community. Some of the work we've been doing in updating our um infrastructure for more efficiency and better costs, and things like that.

A

So yeah, that's uh I, just thought. I'll insert a brief um advertisement of sorts for.

A

What the various talks are.

A

A

Yeah go for it. I'll shut up now.

C

uh You are on mute.

B

um Can you hear me now yeah.

C

B

Oh yeah so um coming to interoperator the overview of interoperator.

B

um Why we need interoperator comes from uh why we like there are like if you look into the kubernetes world whenever you wanted to create a service, so you will be mostly going for kubernetes operator approach. So operator is a combination of you know like set of custom resources in kubernetes and custom controllers associated with it, which will be watching your resources and make sure that um your resources will reach us, its Desert State from the actual state.

B

So if you, if you look into the kubernetes Hub uh kubernetes operator Hub, you can see a lot of operators are available. So, let's say I say um so. Let's say I say: service provider you wanted to make your um kubernetes operator or your service, which is been hosted in kubernetes, has always be. Complaints then um like, if you have to do it, uh so you can weekly, basically make use of interoperator.

B

uh So basically, what we will be doing is we will be exposing like we will be mapping the OSP apis with um kubernetes custom resources of that operator. So that's what basically interoperated is so interoperator. You can consider it as a OSB adapter, which will make your service or the kubernetes operator um and OSP complaint, and so, if you do a multi-cluster setup of our internet operator so um like basically, if you install interoperator in one cluster, it will help you to provision instances in multiple clusters.

B

So that is also one of the important features of feature features of indoor operator which we will come through in the later slides. So how we can make use of in the CF world is that, like let's say you have a um sorry for the disturbance.

B

um So let's say you have a service um in kubernetes. So mostly it will be an operator and you want it to be make it compliant um OSP complaint so that you can get uh use in the CF so like only when it is always be complain only. You will be able to register with the CF and make use of It In Crowd Foundry.

B

So for that you can install in your operator and then um interoperator will be the front-end part, which will be serving your um OSB request, and will you know map it to the custom resource of the operator? So this is what interoperator is all about. This is the summary and coming to interoperate a specific um some architecture. Details.

B

So interoperator has some specific custom resources created in um kubernetes, so first one is SS service, so this is equivalent to the OSB service that we have so for um so your operator will be providing some Services right, and so those Services needs to be registered in interoperator as a service and similarly, like all the plants that are available, um needs that are available in the service like there will be some Services as plans that will be supported by your service, so that plans needs to be registered as SF plan in interop data, so, um like your operator, can provide multiple services.

B

So, um let's take a very simple example that okay, you are and have a postgres operator which will provide you, um postgres access service and each have multiple plans uh like a standard plan and Premium plan Premium plan, and so in that case you are serving as a service needs to be corresponding to your poster service, and you are for the plans uh premium and the standard. So you need to register that as an SF plan in interoperator then comes to S Sub clusters.

B

So SF clusters are the list of um clusters that you want in an operator to manage, or in other words um you can even say that in the Clusters in which you wanted to provision your service, so that needs to be added register as SF cluster. So per let's say you wanted to um provision your servicing file clusters each five clusters. You needs to carry um SF clusters yeah and then coming to SSL service instance and as a service binding.

B

So whenever you have an um when um an OSB, a promotion requires come, um the interoperator will records all the information regarding that call in as a service instance and similarly.

C

B

A provision binding bind request, come uh all the details are captured in as a service binding. So these are the interoperator specific custom CR that you will be seeing then coming to the major components that um interoperator have is. um First, one is blocker, so broker will be, is easier.

B

um The um adapter part, which will be converting your OSB call into custom resource so um uh so broker will be uh serving your API request and it will capture like when, when it's approaching called it will capture all the information, as in the CR SS service instance, and similarly, for uh whenever a binding call comes, the broker will capture all data as part of ss service binding um yeah.

B

That's what the main mainly what Brocket is and whenever like every two catalog call of like OSP call comes um like it will be just reading all the information that are available in SS service and SF plan, and then it will map it to the OSB catalog and will provide the information and then comes proportional part. So proportioner um you can. That is another customer.

B

I say it is the command of the custom controller we have, which will make sure that okay, your SS service, binding or that SS Service, uh instant CR, is getting mapped to corresponding uh resource in the um resource in the operator. So um that is what personal does then. You have scheduler, so scheduler is also another custom controller which we have, which will decides in which cluster uh we are going to provision the service. So, let's say like um as part of SF classes.

B

Cr you will be have you will be listing um more than you can have one or more SF cluster in your interoperator. So uh when you have more than one cluster so in which cluster this instance service needs to be provided, that will be decided by the scheduler component and the multi-cluster deployer is the component that this manages your clusters, which are listed as part of SF cluster CR.

B

So this is um the basic overview about inner operator and interpreter components, and next is like how can you make use of interoperator and make your kubernetes operator and OSP complain? One. So, first is that um you have to identify the Clusters where we wanted to approach like provide your service, and you have to install your service service operator there. So right now, interoperator doesn't take care of installation of service operator. So that needs to be done.

B

Then, um if you have more than one cluster, you have to select one of the cluster as primary cluster and then, as part of step. Three like we will be installing um interoperator only in the primary cluster, um so um that will be the where yeah, the main interoperative components will get deployed and then comes um uh application of like registration of SF, cluster, ssrvs and SF plan so which are clusters you wondered uh which are clusters. You have installed service operator.

B

Those information needs to be passed to uh interoperator through SF, cluster and um yeah. What all are the services and the plans that you provide as part of this operator that you will be registering as part of as a service and Sr plan? So this is these: five steps will make your operator OSP complaint, um so I'll go through some scenarios to will get a better understanding about uh how you can set up interoperator and make your uh operate on an OSP complaint blocker.

B

So in case of a single cluster. So here you only have one cluster and you wanted to provision your service here, and that means that you will be installing drop it also in the same cluster. So as per our setup, okay, like you have like um so basically like you- have to install service operator your own in the record clusters, so you will be installing service operator first. So since we only have one cluster, so this will act as your primary cluster um yeah. So then you will be installing interoperator in this cluster.

B

um So um as uh interoper have four components but as part of installation initial installation, we will be only deploying three components of inter operator which are broker multi, cluster Dipper and scheduler and yeah. So coming to the next step, you have to apply SF clusters CRS. So here you wanted to provision your service in demo cluster, so the SF cluster CR, corresponding to demo cluster needs to be um uh yeah needs to be applied. Okay, though, when that happens, um the multi-cluster deployer, which watches on your all the Clusters that interoperator manages my interoper.

B

How so this will? This is already watching on your SF cluster, so SF cluster will uh create the promotional component here. So it's the duty of, or you can say, like the proportion, is being managed by multicluster component yeah, so yeah, and then you have to apply your SS service and SF plans here to make the setup ready.

B

So this is how, in the case of a single cluster deployment and coming to a multi-cluster scenario, so here I'm taking three clusters: demo, one sister, one and sister two, um so you wanted to provide your service in all these three clusters. So in that case uh your first step will be is to um install your service operator in all these three clusters. First, then, you have to decide one cluster as your primary cluster, and so that will be like right now.

B

I'm decided to take demo as my primary cluster, so here um I will be installing inner operator, so interoperatively um only deploy the com broker, multi-cluster, deployer and scheduler components.

B

um Then uh then we have to apply the SF cluster CRS. So here you wanted to provide service in demo, demo, cluster sister, one cluster and sister two, so the CR corresponding to these three uh um clusters needs to be applied. Once you apply that um so a portioner will be created- and you know like all the CRS that are part of interoperator will be copied to um to the sister clusters as well by interoperator. By this will be. This is the job of multi-cluster. So multi-cluster is the multi-cluster.

B

Deployer is the one which will be managing your all the Clusters. So whatever like taking care of provisioner deployment and installation approach. Provisional and, like you know, coping your interoperator CRS and uh everything uh will be taken care by multi-cluster. Then you have to apply your ssrvs and SF plan. So even the sources will get copied to sister clusters by in multi-cluster deployer, so this will make your setup ready.

B

So this is about multi-clusters deployment, so I wanted to bring you one more scenario in multi-cluster deployment, so here also, you have three clusters: uh demo, cluster sister, one and sister two cluster, but in this case, in this scenario you wanted to deploy your like. You wanted to provide your service only on sister, one and sister to Cluster only, and you wanted to um install your interoperate interoperator in demo, one cluster, so this will serve as the primary cluster and you will be. You need to provision your services in system and sister two.

B

So, let's see how we'll be doing that so here as part of First Step you how to install service operated on required clusters, um as we have decided that we need to provide service only in Sister, one and sister, two. We have to install service operator only in these two clusters. In the moment we don't need to install it, so we need to select one cluster as primary cluster. So for us it is demo one. So we will be installing in row operator in here, um so it will deploy in the operator.

B

Then we have to apply the SF cluster. So in this scenario you need to provide you. You only wanted to um provision your services only in Sister, one and sister two, so only you need to provide CRS corresponding to Sister one and sister 2 to the inner operator. So once you apply that, um then um MCD will create professional only in system one and sister. Two.

B

um In the last scenario you have seen that okay, like we, have been creating professional in the demo one cluster as well. So here we are not doing that because, like we already uploaded just like um SF cluster CRS for sister, one and sister 2. and it will propagate all the inner operator CX as well um yeah that will be taken care by a multi-clustered Empire company. Then you will be applying SS service and SF plan which will make your setup ready. So um so these are the scenarios.

B

I will just go through how the service portioning flow works. So here uh let's say you have this, like you have done your setup. So you have three clusters and demo uh demo, sister and sister, one and sister two and your demo is your primary cluster and you are done every setup done uh now. Let's say like you are getting um an OSB request. Osb portion request from uh once. You register your broker. You are getting an um promotion request, so what happens is um once you get the request?

B

Your broker component will be the one who will be serving that request. It will create a CR um called as a service instance and the all the details regarding that call will be captured in this CR, so that will be done by broker. Then the broker part is done so next, what happens is scheduler comes into picture? Scheduler will decide like identify in which cluster we need to install um this um service. So, uh let's say like it decided to take. um As per its algorithm, it decided to take sister one cluster.

B

So in that case, um what what like once um so? What did they say that it will decide on the cluster so once it decide on the cluster, it will update the SS service instance with the cluster ID. So once the cluster ID is set, um MCD will comes into picture and what I'm serious is um it will propagate um this essay service instance to the um to the correspect like to the required cluster.

B

So in our case it is the step one cluster, so it will copy uh your ssrb's instance to there um that then MCD asked Danny's job now professional component comes into picture, so professional understand that a new SS service instance been created.

B

It is watching on it, so the provisioner is the one which will be uh copying your um just a minute, yeah, okay, so copying your um as a service instance- and uh you know it will look into your SSR weeks at the service and the plans that you provide and based upon that it will convert your um ssrb's instance into.

B

um Okay, so it will convert into a s Service instance into service instance yeah. So this is what interoperator does now. You have created the custom resource in which the service operator works. Now the service operator will take care of the life cycle of that one um yeah.

B

So um like we have one more field called um a state which will decide upon like whether that uh instance, creation has succeeded, failed or which, like what is the state right now? Is it progress or not, and once the service operator take care of its job. Like let's say it's, a creation is what they have to take it. So once it's done um so we have um a multi-clustered deployer, which is watching on cluster and all the CRS.

B

So it will identify that and it will update the state first in Sister cluster one first, then it will propagate that information to the primary cluster. So this all will be the part of that managing the Clusters and like whatever adaptation happening on the service instance, will be taken care by multi-cluster deployer. So this is how the provisioning flow works.

B

So, similarly um for binding flow, similar approach, uh whenever I am binding, request comes, we will be broker, will be creating a necessary service binding with all the information and so uh seems like we already like.

B

um Then the McD will identify like in which cluster it is already deployed, and it will propagate that as a service binding to the corresponding uh cluster and then in provisioner will kick in, and the provisioner will actually will convert this as a service binding CR2 service, binding CR, so that service operator can take care of creationing of The Binding.

B

So yeah, that's all about a binding flow, SL yeah. So now we will go through the demo and understand like how um yeah interoperator Works Anu will help you I, like I, will handle it. Yeah.

C

uh Thanks jindu, thanks for the uh explanation, I think then uh I am jumping to the demo. uh So uh there's a share screen. ah Okay got it.

C

uh Please let me know if the screen is visible: uh I have a terminal open. Yes,.

A

C

You thank you ah so today, uh as uh jindu has explained, uh we can use. You can choose any operator uh from this, so we have a very big uh uh um well, the number of operators, kubernetes operators uh in the operator Hub. So if you go come to the operator Hub, we can see that there are a lot of operators uh that is now listed here. So it's almost uh 270 operators and uh the uh so today we will as an example, we will be choosing the postgres operator.

C

ah So we like databases, so we are picking this operator and trying to make this operator uh OSB complaint connecting this operator to our cloud from the environment. uh So uh um this as of now I. So this is a uh this operator- is by it's an open source operator process Operator by our uh sarando, uh and here is the GitHub page, where there is a good wealth of information and documentation about this operator.

C

um So uh I already installed the Rando in my cluster kubernetes cluster. The cluster name is demo and you can see that the salando operator code is healthy and running. So the next step is so uh from the documentation. I figured that we can create a postgres port uh uh with one of the examples, so I have an example from sarando. That is, if we create create a hammer.

C

Operator is operator provides this kind, and if we install this, the documentation says that we will get a salando port. We will get a postgres port now, let's try this out so without this is before integrating interoperator.

C

So usually if someone wants to create an uh postgres, Port postgres deployment, so what they need to do is uh let's go to the document, so uh they need to create. Using this uh example, uh yaml that uh salando has provided now. Postgres operator has provided so I. Okay, sorry I am not in the right location, PWD. Okay, sorry about that.

B

C

Copy the command uploading yeah applied so now if I go to the cluster. So this is the view of the cluster know this yeah yeah. So the the this is a tool called kns, which is very. It gives a very good graphical representation of uh the ports in the queue we discussed or the the resources in the communities cluster. So we can see that now two, we we now go to postgres uh deployment or ports. So if we check deployments yeah, we deployment.

C

In the default namespace or it's a stateful set sorry, let's go to Port itself.

C

Yeah, so we have two ports and uh if we check this post rescue yeah, we have one instance of this postgres SQL kind, where we have this version codes and uh the GB. So this is the contents, so the size version and CPU I think only the size is mentioned. So this is the uh CR that we need to create, but now we need we need to we. We know we are now planning to integrate this to our Cloud Foundry environment.

C

So for that, as uh we we've seen in the presentation, the uh the steps that we need to do are first, we need to install the service operator and clusters. Yes, we have done that. Then we need to select one cluster's primary. Yes, I have selected one cluster's primary. Then I need to install interoperator in the primary cluster, which is fairly simple. uh We can install interpreter using the helm chart, so we have the helm, charts available uh running this command. Helm installer will install interoperator, so the one.

C

So if you want, you need to give the Ingress URL so that we can create an Ingress and, and that can be connected to the CF environment plus the command is very simple, uh then Next Step, so we are going to uh we have already ah so now the interoperator is installed and it's ready. Let's go to our CF.

C

So now, I have, if I check the CF Services.

B

C

Are no Services service instances running created in this phase space and we can see that we have a service broker with Team. This is our service broker installed in this cluster? So uh let's see these clusters in the interoperator in space.

C

So if I go to interoperator namespace.

C

And deployments.

C

Now we can see the all the components of interpreter are up and running. Now, let's do our CF calls so now I'm going to so. Let's see the services in CF Marketplace.

C

There is a postgres native service: let's create a service using our CF commands. Cf creates a series: I am creating a service by the name demo, one.

C

Now we can see that the service creation is in progress.

C

Yeah it is ongoing, so let's go to our demo. One cluster.

C

And see why it is happening so, uh let's go to demon cluster and list the ports or uh postgres SQL kind in online. All namespaces.

C

Yeah we can see that there is one new postgres, SQL kind is created. uh So uh now we see that it's, it has a specific name. Cf cap called uh the uuid, so this uuid is something that we is the uuid of the CF service that we have now just now created it's Creation in progress, and if you go to here, let's list the ports, pure ports.

C

So yeah here we see that uh so here we can see that there are two ports. These are postgres ports, uh which has an mcf cap called, and it is now created so just like how we create it.

C

um The uh ports in default namespace uh with the yaml file example of postgres operator. Now we are doing it from our CF, so that means we are able to integrate uh the postgres operator to our CF environment.

C

Let's go back to cfcli, let's check the state.

C

Create succeeded, yeah, we are good. Similarly, we can also create a binding, let's come and I'm going to create a binding for demo. One named demo, one key here, this yeah CF, creating a service key for this service instance with the name demo, one foreign.

C

C

Is key come on.

C

We have the URI of the postgres so directly. We can use this to connect, let's remove this yeah, so Now using the cfcli uh so using the CFA. So now we have the connection between the kubernetes cluster and CF, and even we can do the service provisioning. We can do the service binding and we can also do the other operation like we can also delete The Binding uh deposition, the instance and uh so how this is happening.

C

So if I can also do the uh catalog call from maybe a browser or even Postman, so all the OSP calls now works. So I did a catalog code. We do catalog code, uh so we can see the catalog it's showing some information about the service and plan. Now, let's see, let's see how we are able to achieve this using interoperator. So.

C

uh So, let's so, this is done with the help of s of plan and SF service. So if we.

C

C

We have something called.

C

Accessories and SF plan.

C

So uh SF service is has some information about. We are just. We are giving some metadata information, but what is the name of the service should be? The name is postgres native and that should be sarando and some information documentation URL. So these things will be coming up in our catalog code and SF plan. Is the tricky part where we have some placeholders like uh we have? We have a session called templates where we have something called actions, so we have action for sources status provision.

C

ah This one is interesting, so this action states that what should we do when there is a promotion code? So here it says that so we are supposed to create.

C

We are supposed to create a resource in kubernetes with this details, so here uh the type of the resource should be of coin poisonous and there are some placeholders. That is like the name name we can be. We are using a name prefix and then instance, ID instance. Id is something that we are getting.

C

We are passing when we do the postgres when we do the provisioning core from CF, so the CF is passing this instance ID to us and then some metadata information and then uh information about CPU limits. So uh how I how we are creating this uh provision field uh in SS plan based on the example that we got from our processor operator. So we know that if we create, if you apply this custom resource by the name kind and with these details, Salon is operator, is going to create a postgres for us.

C

So we are Translating that information to our plan here. So when a provision code comes uh uh interoperator now knows that, okay, what needs to be done now knows that it needs to create a resource with this information and then, similarly, we have something called action bind where we say what should be done. What should we do for the bind operation? So here we are, we are creating a resource or we are updating the same uh postgres resource and with their with uh some details about the user.

C

So uh these two SF service and SF plan SF plan is the main part where uh we can uh make uh interpreter understand that what should be done next to create this instance here. So that's the integration part so.

C

Now, let's go to the next part, that is multi-cluster setup. uh So uh now uh we have so now, as we uh discussed before now, we can have all the service instances in a single cluster, so we they can integrate um the interoperator with any number of service instances. So now I have postgres operator. Maybe there is an radius operator, so all these services and plans will be visible in the catalog um and we can use a single interoperator to serve all this.

C

uh uh All these kubernetes operators any with the DB or anything um so but then uh it might be beneficial to have the interoperator in one cluster as a control plane, and then we can have the other operators in different clusters. Okay, what is clusters, uh or maybe there is a higher load, so we need to have uh we might it might be beneficial to have many different clusters so that the the kubernetes API server is not loaded.

C

So uh now I am going to uh app play.

C

A cluster to uh uh uh to The Interpreter, so uh for that, what we need to do is we have one resource called.

C

uh Sf cluster, so what does this asset cluster has?

C

uh This is the surface, so it has. It has a secret where we store the cube config, and then we are explaining about how where to get this secret. It's a small configuration. Okay! Let's go to our so I'm, going to apply this to cluster, to interoperator yeah, it's configured, yeah already yeah! So now, if I do okay, cumulate, Cube CTL get.

C

Sf clusters and interoperator namespace.

C

B

We have work that.

C

uh Now, if I go to the sister cluster and I try to get ports in interoperator, namespace.

C

Now we can see that when we there is a new cluster, interoper is creating a provisioner in there in the cluster, so that permission is nothing but an agent of interoperator which helps in deploying in the services here in this cluster. So this cluster also has the saranta operator. Let's see if the salando is up here on the phosphorus arbitraries for uh up here, and so how to check that yeah here.

B

C

Oh sorry, yeah, it is running so now I go to my cfcli I'm, going to create a second instance.

C

So where is document.

C

Creation in progress, so if I go to the second cluster and list the ports or namespaces.

C

It takes some time but yeah we'll be creating some.

C

Oh okay, the first uh yeah.

C

C

Create and created the SF cluster in the right name space so.

C

So the idea is so now: if I have this new cluster, uh the the um the SF service will be created in the second cluster, so yeah. So that is also done so now we can proceed with so so uh deletion and uh uh removing of the unbinding key. So uh so now we covered all these steps. So first we need to install the service operators in the cluster.

C

We need to select one class of primary and then instead and drop it in the primary cluster and then apply SSR V SF cluster and applies the service and plan, and now we are good to go uh yeah thing. That's all.

C

um Any questions.

C

C

I I can stop sharing and past I will I'm handing over to jindu.

B

Yeah so like um so that's all about interoperative and um so I will share the this. We have um interpreted as part of service fabric broker.

B

um Yeah so and documentation is also available um in the service fabric blocker. If you go through documentation, a lot of um about like uh how to make use of interoperator um the basic details and what will have the main important features that is available in interoperator, you will see and if like a plenty of documents to um implement it in in your own clusters and and roadmap, is also available. It's available in our Wiki page yeah. So you can contact us on service fabric channel in in Slack in case of any queries.

B

Yeah, that's all I'll handle it around.

C

A

I was just wondering so obviously the focus of the foundation is um quarify right now um not to make other projects feel uh stepmotherly, love or anything. But um how do we um connect this, or how does this you know work with corifi? What would be steps to take um where we can demonstrate both interoperator and query fee um together? I mean if you could just give an idea, I think people would be interested in exploring uh that direction.

C

Okay, uh so so uh uh I believe with corifi. Also, we need an interoper. We need an OSP complaint broker for any of these kubernetes operators, uh so we can connect. So we can use the interoperator uh or OSP capabilities uh to connect. So now we have connected to CF environment. So, rather than that, we can directly.

C

uh If I'm not wrong and then the the uh so the uh developers don't need to the service operators who have already who already have a kubernetes operator, they don't need to develop a new OSP broker. They can readily use this interoperator, but I think Ram. That's a very a good point. uh I think I need to explore more about how we can uh integrate these two, both maybe yeah, that's a homework for me.

A

Here of homework for us, I guess yeah.

A

All right, if there's no questions, I think we can uh call it close. um Thank you so much. Thank you so much.

C

Thank you. Thank you. Thank you for, uh uh for this opportunity and I think interoperator. So now we have um so uh it helps in Bridging the Gap between Cloud, Foundry and kubernetes, so we are experiencing it in our organization in at sap. So we have a login service which, which has an operator it uses an open search, uh logging El case tag.

C

Then it uh it they have their own operators and with interopter we are able to uh seamlessly connect it to our Cloud Foundry environments and then, uh and the scale is also very large. So almost entire organization uses these operators for General, creating the dashboards uh I, treat it all flows to interpreter. uh It is handling very well so I think it yeah.

A

Cool um again, thank you very much for the presentation um and yeah I look forward to seeing you all on other community calls and things and well after CF day. I. Guess thanks everyone. Thank you. Bye-Bye bye-bye.

B

Thank you, bye.