Kubernetes SIG Service Catalog, 13 Jul 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes SIG Service Catalog 20170713

Description

Design meeting:

- What is the best way to make additional integrations beyond the basic OSB integrations?

A

Okay, I'm, sorry so.

B

Welcome everybody to the July 13 2017 meeting of uber 96 Service Catalog we're going to be continuing to discuss some different design issues for things that we think are required or may be required to elevate catalog to beta. So first up is Michael. Kiba from Google is going to do a demo for us go ahead and Michael. You have the floor.

A

Michael, we can't hear you you're, muted,.

C

Sorry spill getting used to this: okay, yeah, okay, so yeah this. This is sort of a continuation of where we left off from yesterday, because we were talking about how how we sort of wanted to separate the concept of pod presets from a from the actual credential sort of storing and consumption story, and maybe give that a bit more customized ability on the users side to be able to maybe consume services in their application.

C

The way they want to so I was doing some prototyping just around this concept, and so maybe to recap some of the possible ways people would want to consume credentials. We had discussed about like vcap services, where they store everything in one environment. Variable then there's of course, pod presets and then there's custom solutions based off of maybe what the the people are currently running.

C

Whatever their enterprise environment is, and something I also wanted to bring up, was that maybe it's not just the actual credential storing for the application use that we should maybe make a bit more dynamic, but there's also other sorts of environment configuration that we may want to allow to do on binding creation. So some of the examples we have thought were like if you're familiar with Sto having an sto proxy, come up on a binding creation that fronts that that binding or maybe doing something like an egress proxy or a firewall rule for the cluster.

C

B

Michael, are you suggesting that this is something that you would want to do, or this is something that I'm trying to figure out like B, specifically, what you're suggesting regarding you see is just another example of raishin or something that you're saying that we should do for beta. So.

C

I think about having that extensible mechanism in place that allows for something like sto would be a good thing to potentially have for beta, not sto itself. I. Think that that's just an example and the egress stuff is also just an example. So.

B

When we say extensible mechanism, what I think that means is that binding is just for secret and you build another resource in another API server for another integration that you might want, that accurate.

C

um So what I'm thinking is that maybe the the secret aspect is just one component of how the binding is configured in the environment and then maybe having that entire sort of portion after the the credentials come back from the broker as a hook. Point for other logic that can take place that you that people can build their own custom solutions. There yeah.

B

Yeah, and so my version of that is that the binding resource is just about the open, serviceworker binding, it dumps credentials into a secret. If you want another integration, you build another integration uh and have the resource for that represent that integration uh be watching the binding and start working when the binding becomes ready. Is that basically, what you had in mind so.

C

Mines my thoughts- this is just a sort of spit ball proposal, okay, that I did or that I made this little demo off of okay. The thought is that maybe the secret aspect itself is also more of a customizability extension point, and so let me maybe just go through the demo and this gels at all with anybody. This is a first cut and so yeah I just wanted to see if this is something we'd be interested in and if it yeah sparks any interesting discussion.

C

So let me share my screen.

C

Okay, can you see my terminal I can.

A

See it, the clock is really really small yeah you need to I know it's silvus of that eyes.

C

See is that good? That's.

A

Perfect. Thank you very much. Yeah.

C

No problem, alright, so first I'd like to show there's kind of two components to this: the first one is the traditional Service Catalog walkthrough, with the user provided services that we know and love. So let me show the state of my cluster.

C

So this is just giving me a cube config file for the API server. So now.

C

So we have the UPS broker oops and we have the UPS instance. But then.

C

What we don't have is the binding yet so I'm going to create the binding next, and so what I want to show. First is a little bit of the architectural changes that I made. So this is in the kubernetes api server I'm going to get the pods for the catalog, and so now what we see is there's the API server and the controller manager as we're used to, but I've also created. This other thing called so here, just as native UPC, that's sort of an old ish name.

C

We were kind of thinking, but it's because, like Oh user provided service like it's kind of user provided client, but anyway, this is just a a sort of plugin that you would be able to create. So the idea here is that the controller manager handles everything up until the the very up until when the credentials are passed back from the broker and then what you could do is create your own plugin that handles that next step.

C

So the controller manager would pass the credentials and any sort of configuration parameters to a plug-in, and the plug-in here is just a refactoring. In this case of the secret creation and the pod preset creation of that, we have in master today of service catalog and.

D

Did you make a change in these service as a look both to will be plugging? Yes,.

C

Yeah so I can I can show you what sort of is happening so.

A

My college totally sure I understand, but still you described there, it sound like you're, saying that after the binding is created, the concert after the binding. No, so the binding is created by the user, the controller talks to the service broker gets the credentials, sticks it into a secret. Then you optionally, starts calling plugins to do. Customized work is that right.

C

So everything there was right, except for in this case I, had included the aspect of secret creation in the job of the plug-in. That's yeah! That's totally just my decision there, but us I've opened the plug-in here, and so what we see is that it is the same old here we have like inject secret, where it's creating the secret and then, if you're familiar with the the controllers binding code, and then it creates the pod preset here. So it's just a refactoring there, but the interesting part oops can't scroll, okay, yeah.

C

The interesting part is that the the interface there between the controller manager and the this plug-in here is through just normal ttp with a json. It's a HTTP, POST call with JSON blob, and so here you can see.

C

Let's see we just unmarshal everything from that JSON and then treat it as if it wasn't like. We were inside the controller, so I'm sorry go ahead. Was.

A

Only trying to subdue the reason for you're doing something you said the the action of putting the credentials into a secret is done as a plug-in I assume, because you wanted the flexibility to say in some environment they may not even want to store these as secrets at all. They know I'm, just like a goody custom with. Is that right? Yes,.

C

Yeah, that is a one big aspect to it, and another big aspect I'll get to a bit later, is that you could actually get into situations where you start stacking plugins that start to modify as you go, but I'll I'll talk about that a little bit later: okay, thanks yeah, and so now what we do is.

C

Let me just open up the the binding, yeah Mille examples: walkthrough.

C

So now what I've created. So the only change here is that, instead of just having this alpha pod preset template as a aspect of the spec, it's been pushed up. One level into this concept called consumption parameters, and so the consumption parameters here are everything the plug-in needs to know in order to do its job so I, since this plug-in in this case, is creating a secret and the pod preset I just gave it the secret name, namespace and then the pod preset template.

C

And then it's able to go from there doing exactly what we're used to and just to show for completeness oops.

C

So there's no pod presets.

C

No secrets and if we create the binding.

C

Now, hopefully we get the pod preset and we get the secrets as well, so it does exactly what we would expect in the normal walkthrough flow, except it's just abstracted into this other plug-in.

A

C

A

You put the plug-in definition on the on the binding spec itself. I could definitely see that as being an option for someone who wants to customize every single binding differently if you something that the only place would go.

A

Or do you see this if we actually did adopt this type of approach of also sort of having sort of a default definition that says yeah I'm not going to force every single binding creator or every single application developer to add that into every single binding expect, rather we're going to default, one that you can override or something like that. Yeah.

C

Yeah, that seems that seems reasonable, and you can also have that can be incorporated into the plug-in itself is to have a default there. So if it gets an empty sort of consumption parameters, payload it knows I'll just do what I know to do. Got it. Okay, that's looking hot, so.

B

My gut reaction to this is that I don't think this is the right pattern, all right, here's, why is a I?

B

The the probably the first one is that if you use this pattern, you expose yourself to a couple of different risks and inconveniences. The first one is that if this plug-in that you call goes down and I'm, not sure how you configure the plugins for the record, but if a plug-in that you call goes down, you don't have anywhere to put the secret mm-hmm. You do not have anywhere to put the results buying operation, Oh, you, you don't have a place to persist it I.

B

We do not want to add like persistence, cashes in kubernetes controllers, we don't basically don't have a precedent for that and that's not a place. I want to go. The second one is that I, the lifecycle of the binding is now tied to some arbitrary criteria that are themselves like by they are necessarily undefined because it's a plug-in mechanism. So let me describe an alternative to this. I. Do think it's the right approach and is, by the way cool demo. I can appreciate the work it's good to prototype on these things, um so I.

B

The the pattern that I have in mine is like is very similar in terms of what it tries to accomplish. It's just a slightly different factoring so say, for example, that in by the way, um I I look at secret right now, as like the place to persist, the the bind result.

B

I do not think there's a good way to get away from that, because we don't have like some raw resource to throw it in and since it has secret information in it, people will expect the same safeguards that they want for secrets so anyway same if you have the binding that is rolled back to the state that it was in as far as the API resource itself so like remove all the alpha pod preset stuff.

B

um If you want to integrate with a pod preset, I think there should be, as I was describing yesterday a preset binding resource and you create the binding in the pod preset binding. At the same time, the pod preset binding references, the binding that you created and the controller that backs the pod preset binding me, the pod, preset that you want to create, along with the lifecycle of the binding.

B

So when the binding becomes ready, then the pod preset controller can be watching bindings and say: hey that one's ready now I'm going to I'm going to create the pod preset when the binding I get deleted. The and actually the the this resource could conceivably create or add an initial error. I'm sorry a finalizar to the binding via the initializer mechanism, which is basically a remote admission controller so like. But let me just talk through this again. Really quick, you create the binding.

B

The initializer for your other resource adds a finalizar to the binding when the binding becomes ready. The piped reset binding controller makes the pot preset when the binding gets deleted. The the pod preset binding controller, clears the finalizer and deletes the pod preset and then once the all, the other finalizes are cleared, the catalog controller can can actually delete the secret and do the unbind and I I would characterize the advantages of this approach, as you can build, as many integrations as you want, they can have dependencies between them.

B

So, for example, say that you want to make a another integration. As I know, a lot of people want for gif do where you do X or Y activity related to Sto. You can make an FeO binding and point it at the the binding resource and have it do its work and manage the SEO rules on the same life cycle as the binding Mike again.

B

My concern is that we do not want to accrete additional behaviors that effect that the behavior is a binding resource, because it will get really hard to reason about what the behavior that API resources in different clusters, because it's it will become dependent on the configuration of the cluster and the catalog controller in a particular cluster to know what the behavior is going to be.

B

So I'm all about having people build other pluggable, behaviors I think the right factoring is not a plug-in mechanism to binding its other resources that reference, the binding that can hook into the lifecycle and I. Don't think, there's anything about what I saw here. That would prevent us from factoring what you showed that way. I think probably the salient point, like the biggest difference to me in terms of like fundamentals, that change about the situation is that in your pattern, you might not actually create a secret?

B

Is that something that's like very important to you to not create a kubernetes secret, or is that just a coincidental effect of the design that you showed yeah.

C

It was, it was mostly a coincidental effect. It's a thought that creating a secret is itself sort of a environment configuration aspect too, after we've gotten the credentials back from the binding, so it'll like. If we're not concerned about the the sort of Oh, what do we do if things are? If we're ignoring the idea of that, we might have to persist. Information anyway should plugins go down, then it would itself be just another pluggable feature is my thoughts. Yeah.

B

And if, if we had a place where we could put the payload, that would stand up to an API review, scrutiny, I think I might be more open to this approach, but I think I would still have a reservation about complicating in kind of invisible ways: the behavior the blinding resource. My experience has has definitely given me a lot of data points that, like the simpler things, are and the less entanglements they have the easier that they become.

B

The reason about I do think that we have the primitives that we would need to hook into the to hook into the binding lifecycle from other resources. um I, don't know what your thoughts are about, that. What.

C

Could I, um let me maybe say a couple of things as to what I thought were sort of pros to this approach, and then maybe we can ask- or we can talk about how these would be handled in an alternative case or in the sort of proposal that you've designed sure, because the idea of first first I think a nice one is in the case where you are not needing to intimately hook into the kubernetes sort of API in the code, because this is a more it's just.

C

It's just a HTTP like post endpoint with a JSON payload. So that allows you to have flexibility in how you implement the actual plugin. So I actually had some more of the demo where I did I had two plugins running together and it's a console plugin for service discovery, where the application uses the console DNS as opposed to kubernetes dns, to resolve where the service endpoints are and then a volt plug in for for the secret store.

C

And so what was interesting was that the console plugin it was in Python and then the vault one was in go and the idea would be that you could then. Another aspect is that the plugins are an ordered chain that allows you to do something like you can have the fur plug in in your chain be the like the sto plug in and what that would do is it would. It gets the credentials back from the broker. It says: okay, let me create a sto proxy and then for the rest of the chain.

C

I will substitute. I will keep a record of what the actual end point was, but let me substitute it in with a with the proxies endpoint and so the rest of the plugins. If you had secret store after that, it would store a reference to the sto proxy and not the actual service endpoint. So you're able to do some complex sort of manipulations of the what at the very end, the app is going to actually read by chaining these plugins together. So.

B

I I do not think that there is any reason that either of the things that you have said it mean that we have to add this to binding. You can make another resource, that's like the plug-in binding that has the same semantics as you've shown here, but that doesn't entangle the actual binding resource in the binding controller. Does that get you to what you want? Well.

C

The as far as the sort of generis ism of the code like you, you would have to write a a watch on the binding resource right. That would tie you in some way to to the go code and to the kubernetes libraries and everything right.

B

And I think that's a small price to pay for the binding resource being only the open, serviceworker binding, and you could do that work once in a plugin, binding type, a resource and the controller to backs it, and then that thing could delegate out to the plugin mechanism that you want to use. So the other thing is that we don't have a precedent for this type of extensibility in any kubernetes api resource and I can I would bet you $1 that this is not something that would pass API rate. Okay, that's another consideration.

B

D

B

D

You can do exactly this thing as a separate resource, just as all set on top of binding to just take this secret as input, and then you, as you said, you can say, have a an ordered list of plugins to invoke through a guy or whatever. You want actually I.

D

Think I'm sure. If you watched the demo, I did with B Smith I'll put on a sitting on top of a lock so essentially actually like the use case is similar to what you described and the way we solve. It is the way that Paul describes, so we make a new resource on top of winding and like we can do ordered like we can build the dependency graph and whatever else, and in this generic way. We can like to solve any use case.

D

Basically, and even if you think about your plugins, we can just like we stole. The plugins in ours needs a resource for example, and invoke that I'm into the dime and also some things.

C

So with the creation of a separate resource type, does this: does this require the user to have to create multiple like a finding resource and create something else every time they want to create a binding? Yes, but.

D

But you can wrap it just like pull digital data like you need books, binding and 4% 4% to be able to inject the credentials into the port, but you can create a separate resource called 4% binding and you create it once and it will manage both objects for you. So you can create only one object, and this will wait.

A

D

That true baby, it entices it.

A

Isn't it possible for someone have to create a new resource anyway? You're gonna have to create a controller, so it is technically possible for someone to write a specialized controller that watches bindings and then creates these additional resources as the bindings are created and manipulated right, yeah.

B

That's that's exactly what I'm referring to and, like honestly, there's really nothing from stopping somebody to wrapping the entire resource, although I would suggest that would not be a fantastic idea, wrap all of binding and add additional fields to it. So if you wanted to, you could just create one resource, but I I will be honest. Perfectly honest I.

B

Don't think that creating two resources instead of one is a problem provided that they can work together and as far as they that the dependent resource of the two can hook into the resources lifecycle that has a dependency on um and I, also just to bring this conversation back to Ada.

B

The the decision plane that I have for beta is that I want I think it would be in our best interest to ensure that we're concentrating on things that make the open, serviceworker API integration rock-solid and that uh and then also make the kubernetes api surface really really good in terms of like knobs for Brooker type settings should be on the broker.

B

Instead of like configuration parameters to the controller stuff like that, and I I do not see that we need a plug-in type mechanism to get there, I I wouldn't I'll not make the same mistake. That I did yesterday and say the word. Never, but I don't think it's necessary for beta and I think there are ways to accomplish like exactly what you want to do. They don't involve a scope, change to the binding resource like uh and one more thing in my brain is there have.

B

There has been some work done in another incubator, repoed to make the overhead of creating a new API server itself much much lower I. Don't have the URL in front of me, but there is work on going to make it so that you should just be able to stamp out a new API server and add your go types to it and just start running so that it's like something that you can get to in an afternoon instead of something that takes a month and I.

B

Think that might be one of the things that influenced you, I don't want to speak for you. I am curious to know, though, was that a factor like latency required to get to a new API server yeah.

C

For sure, just the inertia I guess the friction there of being able to implement custom customizability options there with how the binding manifests. I guess was the biggest thing yeah I.

D

C

You know a huge ability to customize so long as.

B

C

B

So, by the way, we're going to put a link to the API server builder in the chat, um and just so everybody knows and that's what it's called if you're watching on the internet, it's cuber, Nettie's, incubator, api server, builder I, fill with rock who's been involved with the sig in the past has has been working on that along with a couple other people I think.

B

So that's something that you might want to take a look at so I did I. Does anybody else I see Doug? You have your hand raised yeah.

A

So so Mike a couple questions for you, um I, totally sure I understand just from a straight functional perspective. Are there aspects to your proposal that cannot be done through the mechanism that that Paula nail, where talk about of creating additional resources just from straight functional aspect, just one.

E

Of the things I need to.

C

Think of, though yeah I guess the one aspect is or it's the same con that Paul was saying is that the mechanism like the binding creation, is tied to this other chain of plugins. But one thing that gives you is that the binding or I should say that the the I'm not familiar with the finalize errs that you are talking about. But if you have the plugins B criteria for whether the binding States it's in a ready condition as opposed to having I guess this asynchronous controller watching it's like.

C

Oh the bindings ready, but it's not really ready for consumption until I do the work that I need to do, but I guess you would get around that by having two separate secret. So you'd have one that the that is just a store of raw information passed back from the broker and then you would have the other that the I guess consumer would actually use, and they would wait for that other secret. Or can you close.

B

By maybe so yeah, that's a very good point. ah Less I think the the issue we're talking about is, if you build other API resources to characterize your other integrations.

B

How do you know when everything is ready to use and I've actually talked through this with Jessica Forrester Red Hat, because I was pretty certain a maybe late last week that we would wind up splitting pod preset entanglement out of the binding resource and sent a you basically have this exact problem in a user interface, because what it means is that the binding only represents the open, serviceworker part of the integration you as as a as as a user.

B

You got to know that these other resources that you may take in to represent the other integrations I've also become right. So there is. That is one of the trade. Oh well. Let me say there is definitely a trade-off between having one place, to look and being able to reason easily about the system and two to have to look at other resources to see if they're ready.

B

um My my great fear would be that it with a plug-in type mechanism to the blinding resource that it might become really impossible to figure out the state that the system is actually in, because you wouldn't have a resource that you could look at about seeing what state these other integrations are in so, for example, say that I say that you have a plug-in mechanism to the binding resource and you you do.

B

The open service broker part of the binding, and then you want to make a pod preset and now there's another entity that you have to that handles that part of the integration, but there's not a way for that thing to surface its status into the binding, and even if there is a way now you you actually still have a flavor of the same problem as you do with a separate resource, because you've got to be prepared to find to to look at basically in any arbitrary number of other conditions.

B

Assuming that, like the mechanism, we're communicating from plug-in back to the binding would allow you to set a condition on the status. Now you've got any number of things that might manifest themselves in the status for that resource and different authors are going to implement them at much different levels of quality and I.

B

They might use overloaded terminology that makes it hard to figure out it's kind of anybody's guess what will happen, and that's that's one of the reasons that generic plug-in type mechanisms are something I've found to be very difficult to support. They take a lot of care ah and I think that they're they're, also like extremely seductive as programmers like it's easy to to look at a plug-in type mechanism and say: oh, this is going to this is going to make things easier for me.

B

They tend to be like many other things, be it first really really hard once people start using them in ways that you don't think about, and one of the like I am I am all for people building other integrations. I know. A lot of people are really interested in SEO. As an example, ah I think it will be in our best interest if the behaviors of individual resources are really clearly defined and I and easy to reason about and have behaviors and implementation quality that is equal with a well behaved.

B

Kubernetes resource folks have any thoughts about that. So.

A

Paul a couple things first I like to call time on this discussion because we're almost at 45 minutes now and Michael, it seems like you've, got a lot of good feedback and I think it's now sort of balls in your court to decide what to do with that feedback, whether to rework the idea or to say nope, gonna drop it, but either way. I think we should. If you do want to continue the discussion. We probably should set up another call to discuss that. That sounds fair yeah.

D

A

The other question is well I, just for the notes purposes. I wanted to get a crisper answer to Michael's question, because I think it was a very important one which efficient was that with the last one, the ass, which is, if you do this other resource model that people are advocating as opposed to the plug-in model. How does someone know when those other resources are done with their job right had of the client know?

A

That system is ready, because without the without those other resources, they may say: oh, the secrets they're there for the by native strawberryk and ready, but the other resources may not have been created and then their job yet, and what I think I heard you say is short answer. Is there is no good mechanism right now if it lets the person whoa those other mechanisms about those other resources, yeah.

B

Let me let me give a very clear answer to that. So, if I build another resource that integrates on top abiding, that resource has to have its own status section and has to have its own ready condition so that I can know that that one is ready to and if I, if I create, if I as the user, then go and create a binding and pod preset, binding or prod you later binding I've got to know that, like cool open service broker bindings ready.

B

Let me check out that fob you later integration and see if the Frog you later is frog. You lating, appropriately before I, go and do anything right.

A

Okay, so just check and make sure out that I come I covered that in one sentence in the notes, but I think I did okay, make.

B

Sure you put fried you later in there very important whole.

A

B

A

Whole Rob, you later, okay, got it all right. Okay, all right. So what I'd like to do is move on now. I in the notes. I specifically said: I did not want to talk about specific next steps for the pipe reset split thing, because we promised people would give them a couple of days to think about it. So I figured we'd wait until at least Monday on a regular call before we actually start talking about concrete puzzles for what to do next or people. Okay with that, okay.

A

So the next problem that I put on the agenda is I, thought might be. Something we could tackle today is issue one zero, zero, eight and you get the link pasted into the chat on this is one the opened it so Derrick open this one. Basically, it's about main collisions between our resources and our communities, I believe the one that first popped up with finding as the problem.

B

A

Instance might be another one, so yeah.

B

So I in general, ah by the way for the record when we chose the names for these, we decided as a group that I don't think anybody thought they were like amazing names. But we didn't want to spend time like shedding on names before things were a little bit more developed, and basically, everybody had talked to about. The naming of these resources has said that they're terrible uh I, think instance and binding uh certainly should be renamed and by the way, just for the record.

B

The the binding resource in the core is uh I. I would like to see a show of hands of who are the people that, on the call that I've heard of this before I.

A

Did because Morgan identity right at the paws of it? Okay,.

B

Yeah, so the binding resource is a very simple resource that the scheduler uses to assign a pod to a particular node. So the binding resource has like the name of the pod and the node that it should be on, and the API server like mutates a pod when a binding is created. Now, if, if we were building this system today, there would just be a binding sub resource on pod, and if we ever have a b2 pod API, probably there will not be a distinct binding resource.

B

But that's what a binding is just a little piece of history there and instance so binding is, is bad because it collides with that and actually, if you use the aggregator with kubernetes and you try to get bindings, you'll have you'll find that you have to use the fully qualified name of the retaining yeah.

F

That's what I was saying, no I'm wondering where the what what the failure mode that we're experiencing is specifically and is there anything we can do about it, especially if this other binding is something that's like deprecated or not used whatever? Oh, it's.

B

Used but it's part of the v1 API, so we have to be backward compatible with it. That's.

F

Not going a lot yeah.

B

B

Sorry I'm having a kind of having a brain fart here, I be oh, so the failure mode is with the aggregator. It can use cube. Ctl get bindings right.

F

It doesn't know which fine we want and it tries to resolve it and they yeah.

D

That's right inside.

F

The core stuff is higher than the priority or whatever of our stuff, which, which makes sense yeah.

B

And what you can do is you can actually use the fully qualified name to address the resource and then it works, but yeah I think that we should consider renaming it and the feedback that I've gotten about instance. Is that no one knows what an instance is so I think now we're in the enviable position of having something mature enough, where it's probably right and good to think about what the? What the best means that we can come up with our for I definitely think this stuff must have four beta. So.

A

So there's a proposal in the issue that I put in there to prefix all of our stuff, with the word service nail suggested, perhaps Service, Catalog and technically I person allocated either one. My only concern was I thought. Service Catalog might make things kind of verbose, but at least is very clear. Yeah.

B

It would be very clear, I think, oh yeah, let.

A

Me just finish my thought, sure sorry I thought you were done. No, what I would like to suggest, though, is we come up with a constant they with a prefix and use it on all of our resources, not just some of them, because I think consistency is very important here. So I was wondering we can least get agreement that we will prefix all our resources with the same thing and then we can bike shed on the right prefix.

A

E

Think about that I totally agree with that I think prefix, and it also provides a bundling because right now you can't you can't really tell that all these resources are related to the same thing and they really they really are tightly coupled I'm.

B

Not sure that we necessarily need a prefix, it might wind up depending on the prefix in might stutter and resource names. I, definitely think that we should, on a case, resource by resource basis. Ask ourselves what the best name for all these resources is since and I think that we have issues are scoped to be like rename binding rename instance.

B

What's the right arrangement and by implication, naming for service class and plan, so I definitely think those should all be ones for beta I'm sure those will be tons of fun to just figure out what the right names are. You're probably spend a week just on that.

A

So Paul I didn't follow what you said there you seemed like you were. You were not necessarily in favor of using the same prefix for all of our resources. Yes, because it's because of some potential conflict key. Can you look at the proposal that I put in there? I gave a very concrete list of what changes and what doesn't change based on the proposal. Just using the word service I'd like to understand where you see a potential problem with that yeah.

B

I would but I'm just sharing my gut feelings. Understand.

A

I'd rather talk concrete, it just got reaction. Okay,.

B

Well, that's my gut reaction. I'll, happily review your proposal well, but I think do do. We all agree that we should that this is the the time to find the right names, regardless of what formulation of the names there are.

A

It definitely got betta thing. Yes, okay,.

B

All right so doing he says talk about the specifics on this one, or can we move on and talk on it about the next one on the agenda? Well,.

A

I'd like to well, unless you think it's going to take the rest of the time, I'd like to at least have people look at the list and see what they think. Okay, now I'd like to that's.

B

A

So if you look at the list, as I said, my Viper bowls just put the word service there, I'm okay, with service catalogue. If we actually have to just make perfectly sure that we're not going to open up to something else, but it does make things a little longer.

A

Michael is that you sharing couldn't hear you through talking Michael I.

C

Didn't know I was Michaelson.

B

Sharing this whole time well,.

C

E

B

C

B

A

Was gonna say thank you. Michael for sharing I appreciate that yeah.

C

No problem make.

A

The font a little bigger.

C

A

And maybe switch to your bank account screen.

E

There you go yeah, okay,.

A

I want to see that password file, please.

F

I'm going to request control.

C

A

So the list here seems fairly straightforward to me, like I, said I. Think the only problem with just the word service is: if someone else decides hey they, like the word service too, so that point maybe service color will be better, but otherwise I did I, didn't see anything obvious in here. That was going to be like a name conflict just by the single name itself. Well,.

D

The problem is that communities already have a service object and I can imagine easily that there will be service, something which will again clash with other naming. That's why I mentioned that service, catalog or FC, or whatever.

B

D

B

And the prefix is not gonna fly.

D

B

Anyone I don't.

D

Like it, but it's just like to avoid any confusion, indigence, oh.

A

So, just to help be thing along. Let me try something here. Iii agree with what you said. Service may be too generic. So what do people think about as a starting point of prefixing everything with service catalog? No.

C

A

Long, yes, okay,.

E

Somebody is there a I'm wondering if this is going to be a more general problem in kubernetes. Like is, it seems, like a you know, it's the it's. The name spacing problem right. We have very succinct names that are namespace somehow and and other people who are incubators or whatnot will have this exact same problem. It's like this. Is there something we can push there, that that will help us do this or because I'm looking at this list, I like service I, think I.

E

Think that's fine, but I agree that services pull in it already and it, and it might not make sense to some people of the nervous versus. What's a service instance seems like having a long enough namespace that that tells where these things live is beneficial.

B

Here's here's my reaction. Looking at this I think service broker is I'd, take service broker or I'd. Take open service broker, I.

B

One alternative to service instance that Clayton Coleman is very fond of, is provisioned service, which I'm not sure how I feel about I will just mention it for completeness.

B

Binding is really tricky, especially if you think about like the binding is likely given the fact that we want to split things out from binding that are additional integrations to only be the open service burger part of the binding.

B

So it's tricky to know how to name that one. So.

A

Paul can I suggest something here: yeah.

B

A

Think it might be beneficial to try to focus on a consistent prefix, because I think I heard enough. People say that they'd, like the consistency factor so rather than looking at each one individually. If we can brainstorm around possible prefixes, there have been quite a few there than listed in the chat, SVC cat OSB api, those kind of things they just see. If there's one that jumps out of people as a potential for a way forward, we.

B

Can totally do that, but I want everybody to understand that, like the we are going to have to pass a API review and the III, and just because we like something does not mean that it's going to carry any weight when that API review happens. So we can.

B

We can talk about what we prefer, as a group I, do think the best way to make sure that we don't just like, spend a lot of time bike shedding on something and then, when we talk to one of the owners of kubernetes they're like well I, don't like these names to see these is is probably to try to engage the API review team.

B

There's an actual github team that can help us make these naming decisions uh just just to call it out that, like we can decide all we want and then our decision will mean nothing if API review doesn't like I understand.

A

But I think I'm hearing enough people say they want us to leave, try if we can to come up with a consistent, prefix and understand. We understand that they may get shot down, get get shot down later, but look I think it's be beneficial to make forward progress here to just even come up with a strong, a proposal for what that prefix a day.

B

Okay, I, don't think a prefix is going to yield the names that are ultimately going to be successful, but like alright, we only have three minutes left anyway in this meeting, so I'm happy to use it to take boats and all I kind of stop right.

A

I, don't think we ever be able to jump into a new issue. So now and there you said plus one are you saying plus one which one I'm just curious: Gilda prefix, Oh, ATP chuckling.

F

Is API, meaning Thanks is.

A

That again, Morgan no.

F

Getting to the API review meeting would be the most useful thing to do as fast as possible if they have time and it's the beginning of a release. So, okay.

A

So of the list of ones that have been mentioned: service Service, Catalog, OSP, API, SC, fragile ater of those that have been listed if they're, one that jumps out at people that they feel strong enough to say. Yeah I, like that one and then wanna propose that I think.

F

We're looking at this a lot wrong scope: okay,.

A

What do you want? No.

F

I, don't care I think it shouldn't matter, because we should be in our own scope where we're not colliding with. You know the fact that coop control does this lookup thing is sort of an artifact at how cute control works and not AIT's not useful for us to have this discussion with that. Wait.

A

But I'm told but I got confused. Morgan I. Aren't you talking about something that we have no control over right now.

F

A

So we can't fix it so I think we have to come up with a solution given the constraints of of the world. We live in yeah.

F

And I think we need to involve the core people. Well, yes, service cat, sure I like yes, so.

E

It sounds to me a little bit like there's there's a broad group of people who want to have a prefix, we're, not sure if prefixes will fly, would it make sense to just go with something like service and it's a strawman we pre-filter in service and then the immediate next step is we go to the API group, and we say here are here: are resources you know we've given them a common prefix, because we feel there needs to be some scoping or namespacing.

E

Please please tear these apart and let's have a conversation about it. I mean.

F

The problem yeah, we need to do that, but the problem is that we're colliding with the the core resource and us making a bunch of names that don't happen to collide right now is not a permanent solution. But if we're worried about this binding, specifically thing, let's just prefix everything right now get it out of the way and yeah get the API meeting as soon as possible.

F

E

Is the API group also the right place for us to raise the the more general issue? That's here, which is people are going to create resources and they are going to collide, and there really needs to be something excellent.

B

Well, there is namespacing, like the the api group is part of the fully qualified name like the resource by the way, I have a hard stop like right now, so maybe we can continue this conversation on slack ah short, okay. That sounds like alright. Well, thanks thanks for joining everybody, this was another good one. Everybody have a good afternoon or morning and I will talk to you all on the Internet bye, bye I was waiting, but I was off-camera. Bye.