Kubernetes SIG Service Catalog, 24 Jul 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes SIG Service Catalog 20170724

Description

Design Meeting:
- Update on PodPreset and service-catalog API server
- Background on TPR and CRD storage backends
- Kubernetes names of ServiceClass and Plan
- How to handle deprovision requests for instances with bindings
- Broker update semantics
- User provided services

A

Welcome everybody to the July 24th 2017 meeting of community service catalog uh Aaron. Would you share your screen, so we can follow the agenda as you take notes,.

B

Yeah give me one sec.

B

Okay, can anyone not see this I can see it.

A

Okay, so first up, we discussed in architecture sig this morning or I guess early afternoon, each of time the situation with pod preset. So we got a decision out of that to move the settings. Api group wholesale to Service Catalog API server, and that also implies that we will implement pod preset with an initializer instead of an admission controller for anybody that doesn't know already, there's long been a desire to have admission controllers that are not compiled into the kubernetes core and that's what an initializer is so Google has.

A

Generously, given us vanilla to make that happen and to help get pod preset odd to a beta level in turbine Nettie's 1/8 online. um Well, that's the update on that. um I do think that we should I have perhaps in tomorrow's design, meeting a discussion of what that means. These are the odd please set integration and catalogue going to beta, um but we have a very full agenda today. So I think we can discuss that tomorrow or later in the week next up, Erin crts.

B

Yeah can someone finish the notes for plot preset, then I will give it a shot. Okay, so I think most have seen issued 987 that has discussion on migrating from TP, our storage back-end to the CRD storage, back-end I'm, going to share context here very briefly on. Why then Deus built this integration?

B

So for those who don't know the issue we had was we had customers who didn't want to hook up Service Catalog directly to an ED CD wherever that might have been and at the time I think the options were basically the same as they are now that is either the at CD that kubernetes core talks to or to just throw a net CD somewhere into the cluster. So we built GPRS as a storage, back-end.

B

Now, of course, TPR is, are going to be there deprecated now and they're going to be I believe eliminated in communities 1.8. So this discussion started as an issue, as should we migrate to see our DS I think the obvious answer. There is yes, we should migrate off of TP RS to something the requirement that we have to be clear is not. We must do CR DS, but we would like to have something that hasn't required: an SPD to be sprayed onto the cluster and used exclusively by Service Catalog.

B

That's where the PRD discussion left off. I know that there's some interest from Google and from Atlassian that they may one or both of those groups may want to implement a CRD storage, back-end I'm going to have a discussion with at least Mikael Mikkel. Are you on the call now I believe I did not see you I.

C

B

C

Speak for you, okay,.

B

Great, so I was going to have a discussion Neal with at least him, but I think you were going to be there as well. That was going to be in the early evening. My time I think the morning your time about how to proceed here with implementing CRD back-end support, so with that I will leave it and Neal. If you want to fill stuff in, please go for it.

C

Well, I think that both you and Google Hughes case analysis is pretty much the same. That, like the reasoning for using GPRS or series, is pretty much just not willing to manage a separate etcd cluster and just using the same etcd. It is being used by core communities, but not directly, probably, but through the API, so yeah I, don't I, don't see any extra requirements for using theories or any other resource. Oh, we don't care a lot of what it is like switch from GPRS to series just for us.

C

It just makes it mostly just renaming providing the same very so. I think that it should be also straightforward, because it's based on TPR, so I don't see any other options. Then using said it yeah.

A

So I have one question that I that I have about. This is whether we.

A

Whether we can actually do this right now uh and wholly migrate on to uh see our dues or whether we need to keep TPR support around which support is being very generous right. It's more like it's there and if you can try it, but I wouldn't say that we offer support on it.

A

um I wonder if the Microsoft Google and have lasting folks on the call can say whether they feel we can ditch TPR or whether we need to keep TPR support in at least until we have CRT support or if we need some period where they're at CD, TPR and Ciardi are all technically have app ways in the code associated with them. So.

B

What we can do and what I think we should do is leave CPR in the state. It is now which is just declared in Docs at alpha when and we can concurrently build CRT support in and then when 1.8 comes out, we can declare TCR support deprecated and only refer to it as in alpha in the 1.6 and previous stocks. Sorry 1.7 in previous documentation, and that would then cover the use case for people running 1.6, 1.1 point 7 in before and of course tell them again.

B

The does alpha and then covers the 1.8 plus users for CRD and the hopefully work involved. There, of course, is to just add the CRT support, yeah.

A

So we are going to have this problem again because I see our DS while more stable than GPRS are still not designed as a data store. So when I've spoken to API machinery type folks, maybe Walter- you might know more about this than I. Do we had discussed like a basically totally opaque blob resource that would be suitable as a data store for aggregated API s and obviously that doesn't exist yet, but I think the desire and the community.

A

It certainly seems to be strong enough that it's arguable that we should build such a thing, especially if the API machinery, maintainer czar, not I, think that CR D is unsuitable as a long term place to store data for aggregated API s. So it's worth considering what our deprecation strategy is going to be and I think this is perhaps another area where we're out in front of kubernetes, because I don't think anybody else has any concern like this about supporting different data stores. Oh so.

B

I feel kind of strongly here that that would be great, but I feel that the deprecation policy we have that I just suggested right now is just kind of good enough and I. Don't I'm not suggesting.

A

That we block anything on this I'm only saying that we will have another sibling that will have to think about in the future. That's all so.

B

That's that's great I, plus one that but I do feel like we have enough on our plate in terms of stuff that we're taking on from the community. Of course, pod preset is the biggest example there, but I'd rather just implement CR DS next to the existing TPR implementation and then carry that pattern forward. If and when we get the opaque blob API, and that would be great, of course, yeah.

D

If I just quickly, hang on I have definitely already seen a very alpha version of a blob presentation go past, my desk, so it is definitely the community is looking at and if you're interested I can try to have a quick overview of it ready for next time. That would be awesome.

A

I will +1 the implements er D next to t PR I prefer not to carry t PR forever, ah but we can sort that out at a later date.

C

Do we want to use the client go for the site, I think someone said I haven't looked at it, but some of that that they're using REST API now for working with to be our slope clang go types.

A

Walter, what is the current best mechanism to work with TRG types from a client standpoint.

D

Actually, that's a really good question: uh there's two guys in the office Emil and Sean who we're looking at this right now. I, don't know the latest status, but on I would say that you want to get moving on CRD, because TPR is supposed to be deprecated and those are the discussions about which needs to be removed in.

C

And which means that if we are using triangle, once we migrate a rebase on to 1.8, we just won't have to cuss at all, so I think we can sync up with this change. So before we base on to one point, and we should probably ditch-digger I.

B

Would be fine with ditching at that point really the strategy can just say if you are one point, seven and prior and you want to use TPR for some some reason whatever it might be, then you're restricted to versions X and previous I.

E

Don't want a message into a discussion, but I was a little bit distracted and the call, as you talked about this is notice from a blob storm. Just out of curiosity, what would be the difference between a blob store version, an object store.

C

One of the things.

D

C

See is just like, for example, now, if you using two graphs or theories, you can use cube CTL and, like all the objects, I expose, they're all objects and, like anyone can access the like data beneath the not not using the click. Service Catalog, API server, so I would I think that it would be useful to hide all these objects and I'm, always through so simple. So.

A

I think one of the major facets that the API missionary group thinks feels that CRD is is not good enough as a long-term location for just arbitrary serialized data I is that they do not. They feel that the versioning support and Ciardi is not strong enough to be the basis for arbitrary API data. Yeah.

D

The other things I would add to that are 1x. Eb is really not designed for large objects, I'm using actually investigating a couple of large objects basic stuff. So we would like to keep control of, what's actually in FCB, to make sure that we can get good behavior out of kubernetes. So that's one very important piece.

D

The second is that we sort of feel like, as people begin to scale, it's going to start becoming more and more important to have multiple data stores so that we can isolate certain behaviors, and you can certainly see where you don't necessarily want.

D

Kubernetes attacking service catalog or vice versa, in their behaviors and isolating their data systems, is going to be important towards that goal.

B

Esso, so another idea that I've thrown around much longer term is providing an option in service catalog the API server to use external storage outside of kubernetes. That's something that's kind of in the the hobby ideation phase in my head, but I wanted to throw it out there for someone else to think about as well. If you have ideas in that space and at the end, any in stock I.

D

Mean that sounds reasonable, but the other thing is even on the kubernetes side, we'd like to give a standard API or doing exactly what you just said, so that you can, we can do it consistently and things can migrate easily from AWS azure or whatever your cloud provider happens to be so.

E

Aaron just to circle back around to the need for something for Denis 40 pairs in to begin with. If I remember correctly, I thought during winter space spaces, you guys had needed it because you wanted the Service Catalog stuff to run I want to say outside the careers cluster, but at least not right next to the Gray's core processes, or something like that and then and there might be like firewall issues or something in the way that we're going to from you know: okay.

B

What was the issue? Because no, we still we wanted to run it inside of the cluster we didn't want to have it share the kubernetes core at CD. We also didn't want to have to basically plop down a net CD on cluster, just forced just for the Service Catalog API server right.

E

I understand the latter part cuz, you don't to manage a separate identity, but can you elaborate on why you don't want to use the same at CD, because in this model, that community is heading towards where it's separate API servers, they're breaking up the cord to separate little components? This seems like it just falls into yet another component. Why would service catalog be different in that picture?

E

B

Because opening up network access for a pod to the core at CD, it was extremely problematic for some workarounds. You.

A

Also can't do it on a lot of clouds like on GK. You do not get access to the SE e.

B

Does that mean that so Doug? Let me just clarify real quick: it's the the problem that we've never had the problem of saying we hate customer. We want you to allow service calleb to store data on a CD. The problem has always been. We want you, the in order to open up network access directly to at CD o.

E

We mean, as opposed to going to the API server yeah.

B

So TPR is was the solution because it's always been okay to say this API server you're going to store stuff on down the cords. Okay, here.

E

Okay, sorry I completely forgot it's directly access the CD, as opposed to API, should I forget about that piece. Okay, thank you good sure.

A

Okay, so it sounds like we have consensus to to implement CRT and keep CPR around for the time being, and it sounds like that is good enough for somebody to go and begin working on it. I do I had been thinking in connection with CRTs that uh they were very labor intensive for Aaron I think it would be really great if we could, if we could get someone else or some other parties multiple to make a contribution for CRT I.

A

Think Aaron's already jumped a lot of hurdles in the dark to the benefit of the those who will implement such a thing, um and hopefully CRT support will be a.

A

Much less of an unknown to right support for then GPRS I, wonder if we have anybody who is willing to raise their hand as someone who would like to work on that. That also has time available to work on it. I.

C

Believe follow-up from Google to Jessa can be sure that they can work on that.

F

C

F

I think soon ill may have been indicating that he would have cycles this quarter to work on it. I know he's not here now, so we need to follow up on that yeah.

A

I, don't think that we can rely on Sanel as that person, because his primary responsibility to my knowledge is things to do with settings API, group and pond preset. Yes,.

F

A

Heard in another, and give me a worth.

F

Working with to other people on his team, okay, so when I say Sunil I mean Vanilla's team. Okay,.

A

I will I'll ping him offline about that? Yes,.

B

So that if you look at my screen, I, don't know the third that this person's name, but the cutest github handle here said above I think it's somewhere above maybe they said that they would be willing to, and then, like I said, also McHale said he wanted to talk about it later this afternoon. My time it looks like on all said that he could do it.

C

Yes, I said like I: do I could do it, but yeah you can scroll down I! Think it's probably one of the way position, officious yeah this one yeah.

E

B

C

So I don't want to use, have like a conflict on making yet.

B

But I'll tell you what I'll take is an action item to a figure out who what party or parties are going to do this and be then coordinate those parties party or parties, and help them out with whatever they need, while they do it so.

A

I'm sure you've already done this errand, but it might might also be worth thinking about I. Having done the the exercise already with TP are thinking about what how the work might break down such that it could be parallelized or split up between people. Joseph I have.

B

A

Excellent I suspected as much so.

B

I've wrote this in the issue to I'll update in this issue.

B

Notes from this discussion as well as notes from the session, with last seen, guys that Neil I think you'll probably be at and then further if I have discussions with Google, etc, etc. This will be the issue of record.

A

A

So next one I had something that I put on the agenda: I'm going to move it to the bottom, because I think there are other things that are probably easier to actually get consensus on during this time, so that we've dug name of service class and plan. Oh yeah.

E

This'll be easy, I.

A

Think we actually started talking about this on Thursday of last week, but.

E

Not I don't think we did this. This is the idea of what to do with the fact that the service class name, the plan name, might actually change from the broker when you do a refresh and that, therefore, because those things can change, we can't use those names for the resource names inside kubernetes, and so what the heck do we do about that now. The reason I added this to the agenda was because I had a proposal in there. You get the link to it on a sec.

E

There's the link to it. I, don't necessarily want to go through the details right now, because I think it's best for people to read it offline and think about it. I just want to bring it to Abel's attention and, in particular the bits I want to draw to fuel attention of the other.

E

What I consider to be the controversial bits which are for from an end users perspective when they actually go to create an instance I want them to be able to reference the service and the plan by the nice human friendly name, the changeable nice human friendly name, but once that resource, once the instance gets put into the API server I proposing that we twiddle that field to be the you know, some unique UUID kind of a thing: that's going to be the real name of the instance and plan and I'm not and what's controversial about that to me.

E

Is this notion of the API server changing the users data on them on the fly? That's one bit that.

A

Breaks that breaks patch, but we think wait what you're going for is you want people to think about it and perhaps we'll discuss it at length if we get.

E

The I just want to bet the others. The other controversial thing which is dynamically generating data on the fly in response to a get that's something else, I think is either controversial or new for kubernetes as well, but anyway go up and think about that. Because it's going to take a lot of thinking, discussion, I'm sure.

A

This actually might also be something that perhaps we can discuss and then surface in the sig architecture office hours I am loath to invent new mechanisms here, but should definitely discuss it. Yeah.

E

Okay, Bob we're on top, though um you said this is going to break patch. Can you elaborate on on how it breaks patch.

A

A

A

Will have to think for a moment to construct an example of exactly how it breaks it. But because.

E

The service name field would be right once I believe, for instance, the plan name may is updatable I believe with the service plan name itself, I'm. Sorry, the service name itself should be right once so.

A

In in general, though, like forget about patch, my most pressing point of discomfort about this is that, like I, would be totally fine with tooling. That did this for you, but if, if we rely on magic in the API server, we still fundamentally have races so that you might unintentionally a couple yourself to a class. That is not what you thought. It was okay,.

E

I think we need to explore that Morgan. Let's try follow that to me. This is.

A

Very beautiful like if, if you have and honestly I'm, not sure whether.

A

Whether porcelain would totally solve this um so say that say that you allow users to post the the human readable name if they post the human, readable name and at the same time a broker is being updated and I like the names shuffle around, so that there is now a new plan or in like another plan that is renamed to the name of the old plan, but has different semantics.

A

You might wind up with not what you thought I'm actually extremely curious about how Cloud Foundry handles this, because they they must do something similar to a similar to like the porcelain that we've discussed, because the experience that you have as an end-user is one where you are just referring to the human readable names.

A

um But that said, I also happen to remember that Cloud Foundry as a platform does not have an automatic realist interval like we do so they perhaps they don't do any prove like don't take any preventative measures to avoid such a race, because they consider the the update of particular brokers catalog to be manual once in a blue moon operation.

A

I'm, not quite sure, I understand the race condition, so the race condition is that I refer to service plan a while I'm posting that the controller is also relisting the broker and the broker used to have plans a and D, and now it has planned a B and C, except since the names are mutable, it changed the old plan, a to be the new plan B in the old plan, B to be the new plan a and you got the new plan a when you wanted the old plan. Okay,.

E

That's not so much our race condition to me as much as just things, change on the recovers and I. Don't think we can ever fix that. To be honest in.

A

Yes, Morgan, they do all have grids and.

E

I thought that in some way, they're not.

A

They have IDs, whatever is in an ID, which we know to be also a subject of some debate, but.

E

So Cloud Foundry does need to go with under the covers to reference everything, but from the end users, perspective. Condrey does not necessarily avoid this exact problem right when we go to reference something by the human readable name.

E

If between the time you did the query and the time you actually try to use the human readable name, if that human, readable name that points to something else, then you're going to get that something else and I'm not sure we can necessarily even fix that either because it that's just a fact of life, someone renamed something on you and reuse of that name: you're going to get the new thing, because you have no way of knowing whether they meant to point to the new thing or the old thing. So.

A

I think the takeaway here is everybody read the issue and perhaps we can discuss it. Maybe tomorrow so I work, yep, okay,.

C

B

Doug is your: is the issue? Is your proposal in issue 802?

B

Yes, the last comment.

E

E

And for those of you missed, the exciting news of the chats master is now fixed.

B

Excellent thank thank.

E

B

For doing that, but.

E

Yeah, luckily it was, it was just a simple missing repository issue. Thank God, nothing more serious.

E

What was missing so on Friday, we merged the PR that created other architecture version. Ok,.

G

E

I got it okay, so the robot wasn't allowed to create, doesn't apply.

B

Okay, I think we're at a of's on the names of service classes and plans. We have an action item there.

E

Years and I believe, if you want to take notes when you talk to it, okay,.

B

Yeah, so this one we've gone over this three times now, I think every time we've kind of punted. This is what should we do if someone tries to delete an instance that has bindings that reference, that instance, the OSB spec, doesn't currently say what to do here. That's something I'll be bringing up with the four in the meeting tomorrow with group I.

A

Believe professionally they actually prevent the deletions. They say they know. You can't do that, because there are findings that are active, yep.

B

Beat me to it, and the refresher here is that was going to be our default. Behavior I would be hugely in favor of just doing that. I.

A

Am, however, I do not think that we have any place in kubernetes where we prevent the deletion of a resource. So I think that we have to accept the delete, uh and perhaps what we could do is accept the delete, but then not actually do the deep revision until the until the bindings are all themselves deleted. Yeah.

B

That's what I was about to say they just put it into.

A

B

What I said in before Aaron yeah and race condition? It might be a better user experience to write in these, in a condition in the instance listing what bindings you need to delete. First, in order to finish deletion of the instance.

B

Beyond that, I would say: let's do that and we can add machinery later if we want to do some sort of cascading delete, they're.

E

Going to be ending vacation to the user, that, though, delete did not actually go through, not.

B

Oddly, but they would be on the status field so.

E

They have to go out of the way to look for it right.

A

Yeah but that's with parity with all other deletion, driven behaviors in kubernetes too right like.

A

Any of these other behaviors, you don't get the delete, rejected I mean.

B

For instance, namespace deletion can fail or I've had it take days that, by the way, the reconciliation works, yep.

C

So instance, just will have a deletion time stamps up right, yeah.

B

So it'll go into finalization, it will still be in finalization, but there will be a condition written down that says you can't delete this right now, because the following bindings still point to it have the list of the binding names and then say you need to unbind by deleting those bindings. Once you do that, then this instance will be completely deleted. So.

A

One thing that I've just thought of is: we would definitely also need to block new bindings from happening at the API server level after you had an instance that was deleted, but still had active bindings. We shouldn't allow new bindings to that instance to be created. What.

C

About updating bindings.

A

C

Get that not what about updating bindings existing biting I.

A

Think updating so actually what what's the use case for updating and updating a binding? Alright.

C

Do we, it will have a request for updating binding, though we.

A

Don't yeah updating a binding doesn't mean anything because you can't update the parameters on a binding, currently isn't.

E

That but that's in the works right, I.

A

Know async in the works I, don't know off the top of my head. If that includes updating, because there's a.

F

Separate issue for for updating, I, don't think it's gotten traction rates recently, though, so.

A

I I will say my statement was intended only to apply to new bindings that we should reject.

E

New bindings, so one of my mark mark the question of updating existing bindings of the TBD until the spec actually supports it sure it can decide later what we're going to do about it is.

B

There light is there a different issue for updating bindings and service? Catalog does I. Think Brendan was a saying yeah, oh I know so.

F

I think that was re enough with a current service broker. Spec. Oh okay,.

E

F

Don't know that there is one in the Service Catalog repo.

G

There's some other way to handle a secret rotation without an update, nope.

A

It's it's a pretty big gap in the API that a lot of people have identified right.

E

So that that's in the so, let's just because as DVD and suspect, supports it Doug. What's this that we should mark is TBD up updating existing bindings I'm a deleted instance gotcha.

F

Is this important? You know it's good for us to identify things that are important to start driving more in the open service broker spec. So this is something that we should start driving more for this or or do we not care I.

E

Thought we cared a lot about being able to rotate the credentials I.

B

Would say it's worth bringing up Brendan, haha but with respect specifically to issue a 20 Cal I, don't think we need it in order to make progress. Okay. Does that answer? Commission yeah.

F

I was asking more specifically for this because, because there's a lot of things that we can punt until the spec is ready, but there are also things that we probably use to push this back. If we need to sometimes a case yeah.

B

I would agree with what Paul says that just block new bindings for the instance and since we don't have machinery to update bindings at all right now, because it's in marination so to speak in those B groups, I think it's okay to just push forward on implementing block new bindings. Do the failure on finalization that we talked about and then go and talk to the OSP group sort of in another thread about general I love.

A

The idea of the kubernetes incubator, org being renamed to the kubernetes in their inator.

B

Let's, let's go to sega architecture and make it happen.

B

So Paul question about blocking new bindings on the cubes. Let's say you know, keep CTL create or whatever would that still go through and then the new binding have a failure condition set on it. No.

A

B

A

In this case, the you have an admission controller that just rejected the binding gotcha.

B

B

So I'll take an action item to write down the decision and number of what is this a 20? You.

C

Both do the admission controller, I think checks that there is an instance with this name or something like that. We.

A

Actually don't, as far as I know, I'm double-checking now, but we certainly could use such a thing yeah we do not. We only have one that checks to ensure that the kubernetes namespace exists, so we can make it a distinct issue to have an admission controller that prevents a binding from actually you know what we shouldn't have that, because you might create them out of order. Yes,.

C

That goes like should I questions. Look like you can create blogging with lot of existing. Then you can delete instance and like it could be literally in red. The mother, yeah.

A

So I think in this case uh I think in this particular case. The difference would be that the emission controller that we've been talking through would look for the presence of an instance that had a deletion time stamp on it. Okay,.

A

But actually that miny might not even be sufficient or might be wrong for another reason, someone to think through I guess.

A

So who put broker update semantics on the agenda.

B

Before we go there, does anyone disagree with these decisions? I've written down under the previous I.

A

Don't think it's a failure, condition I think it's just a condition.

B

Cool all right COF for me, okay, who.

A

Puts worker update.

E

Semantics so I did because I did because it's still an open issue, but unfortunately, I haven't had a chance to write at that. Concur, repose 'el, but just let you guys know what the issue is primarily.

E

So there are two issues here: one is there, gonna be cases where brokers just vanish and we need to make sure we can delete brokers, instances and bindings without ever making the call out to the broker. However, some sort of forced type option I'm not sure we support that right now and also we're having services and plans that does vanish when you do a refresh from the market from the from the brokers marketplace. How are we going to handle those? Those might?

E

Those may be very related to other issues we talked about, but I need to do the homework to investigate it and I was a concrete proposal fellows kirlyam's and in our code. Okay,.

A

I'll take an action item there to make an issue for the vanishing broker case, because I think that's a little different than broker updates. um I can do that today. That's.

E

Fine that you're going to include a proposal yeah.

A

I think I think for I think the proposal is just that you should be able to force delete those things, but.

E

I'm not sure they're going Nestea else and I heard that general direction I just mean I was just going to take the time to write up a proposal. If you're going to do it, go for it. Yeah.

A

I can do it. Okay,.

B

So that actually kind of relates back to the previous one, the handedly provision to an instance with bindings we did have. We did talk overall about doing this thing called forced delete and this might be the place to start its implementation.

B

Yep I would agree so Paul. Maybe you can just make that a note in your proposal. Yeah.

A

I think that there are I think in my it's probably more complicated than forcefully, because we'll have to finalize we'll have to finalize the four bindings. For example, if we just force delete the binding, something still has to go and clean up the, so it might be kind of tricky to reason through yeah I think it's actually I'm, certainly more complicated than it seems on the surface, but I'll take a first pass and writing it up and we'll just see what falls out of that sounds.

E

Good, so Paul I want make sure I understand. Are you writing up the issue that says the broker vanishes and they're pretty forced to leave everything or you take an issue of the brokers still there, but the service isn't plans that you may reference are now gone. I'm.

A

Going to address the issue of the broker vanishes- okay, cool I'll.

E

Take a second woman.

A

All right, pretty user provided services on there. Okay.

E

This was mine as well, so right now, user provided services are just like any other service and we created a user provided broker to deal with those and as I was going through, the walkthrough and playing with Simon plugins stuff. I I did not have the greatest user experience with it and it may seem like a minor thing, but it kind of really bug me. The more I was looking at it and it's the fact that one I had to explicitly set up a broker to do it now.

E

Granted an administrator might do this for me, but it does seem really annoying to do that and then the bigger issue for me was when I created my instance.

E

I had to get a plan name, which makes no sense whatsoever for user provided service because they don't have plans, so you have to put in a plan name of default, and it just felt really odd to me between those two things that started making me wonder whether we should file the cloud fabric pattern and just have a well-defined resource called user provided service instance, or something like that. That way, they don't have to feel like they're doing something hacky or specialized.

E

It's just here's a special type of service instance, and it's the same kind of user experience. The cloud gives you and it doesn't seem to be one month. It feels cumbersome I want to bring it up and get some discussion going on it. The.

A

Whole thing with the ups broker does seem janky to me too. I am not necessarily against a first-class support for user provided services. I doubt there and must-have for beta. They seem more like a GA thing to me.

E

Yeah I don't have a huge preference, obvious I'd, rather sooner rather than later just we can work out the design details, but it would be additive so I, don't necessarily with pushing it out. I guess before I go off and actually write a work.

E

Formal proposal, though, where whatever time frame they might be in I, would like to have people think about this for a day or so so, maybe tomorrow, people come back and say whether they in general think it's probably the right way to go to have a specialized resource or whether no the current approach is the right way to go. Does that we'll think about for 24 hours? I prefer that does your office resource.

B

You mean something kind of more specific than an instance. It's sort of like a specialized instance.

E

A

What is Cloud Foundry do for user provided services in bindings, basically, nothing to give a plan. No.

E

Basically, you could, they have a specialized, select, a better phrase resource, we say basically create user provided service and you give it credentials or you give it. You know whatever information you need to create it, and and then you create bindings off of that.

H

C

H

About how the I guess user experience would be as far as like doing cube, cuddle and whatnot, because it's what you did get instances, would it list the special user provided services under that.

D

H

Okay, so it have to aggregate them and then same for like bindings. You would specify the user provided service name, but it has to know that it's not actually an instance. It's a special resource, so there's some sort of stuff under the covers yeah.

E

I know this is the right phrase to use for for go line, but basically I would I kind of envisioning user provided servers as being not quite a subclass because it doesn't have plan, but it's similar in that sense, but maybe actually fit away around, maybe normal instances more like a subclass of user provided service because it actually goes one step further by adding plan to it, but I'm ABI Shima phrase it that way. Cuz look this confuse the matter so.

B

Then Doug, when you do coop CTO get service class. These things would also show up they're just without plans.

E

No because they are not services that you create instances from you would be doing a coup. Control create user provided service type. Okay,.

B

There would there be a relevant way to list the user provided services available from the catalog. You.

E

Would not be asking for the catalog at that point, would you be asking for is give me the list of instances of services, and this would show up in that list. The same way MongoDB would show up in that list. Gotcha I'll read through your proposal. What's up non-verbally engineer issue yeah that Haga what.

C

The use case for user provider services compared to typical brokers and subway so.

E

The use case that I'm most familiar with is the one where you have credentials for a third party service already, but then you want to access it using the normal service broker. Mechanisms like so so.

A

You get one hundred posted node into the cap services yeah.

E

Basically, yeah I wanted to tell the system: hey, hey, hey, don't don't try to provision the service already here. Are the credentials I'm, giving it to you upfront but go ahead and let me bind to it the same way. I would normally, but it's kind.

C

Of a bitter still so it's broker another object right. So you just manually create.

E

Instance- and you may not think you.

C

E

Create the instance, but you do not have a service broker involved.

B

There's kind of more than that too right I've, seen this thing used ton for things that an operator wanted to be quote multi-tenant, so they they spin up the or whatever and they put the credentials into Cloud Foundry. And then they say this is what to use you bind to it as normal, but it's shared across every binding, the actual database table or manga collection or whatever is the thing that is shared multi-tenant lee across all of the bindings, but isn't that correct? Well that that.

E

Is that that is a use case, but that's basically the same use cases where I describe, because in that case, the user or then gets the admin created the MongoDB through some mechanism right, whether it's actually through Cloud Foundry or through this one API directly to comm or whatever it doesn't matter. But then, when they go off and create the user provided service they're telling what sound, what those credentials are basically the same thing. How.

G

Does it handle it if a second user provided services created? Does it use the same default plan ID? There is no plan.

E

Okay and the user provided service a completely independent, because all it is store to store credentials.

G

Okay, but it since there is none, it's no longer a good there. It's just ignoring it. It's no longer good I'm.

E

Like even for the plan, yeah.

G

E

That's why that's why I'm suggesting that we create a resource that doesn't have a plan field in it, because it doesn't make any sense in this use case.

E

C

So for user provider services, do we even use or is the API at all, or do it just like? Have a manually created objects? It's.

E

Basically, all mango you never can never go talk to a broker so you're right. We never use the actual OSB api. Okay.

E

So now you're going to write up a more formal proposal for this I yeah I was going to wait until tomorrow, just to make sure no one had a huge objection to at least considering the idea before I went through the work, but yeah I'll wait. I'm.

A

Fairly dubious about being able to do this without adding a large amount of complexity relative to the return on investment, but I look forward to reading your proposal. That's.

E

All going to take it slow, yeah.

C

I wonder if it actually should be in the scope of Service Catalog or just create your own port process greatest secret manually and just inject all the environment, variables or whatnot. Well,.

E

It's interesting, you say that, because that actually might be the right solution. Yes right, we may look at this and say you know what we don't even want to solve the this use case via Service Worker concepts. It all depends on how we do like I think the pod preset binding, because that's almost outside the scope of our Service Catalog API anyway, right yeah.

F

That's a really valid point: I think the reason that it's part of the Cloud Foundry platform on which we're basing this is because Cloud Foundry is also a pass, and so they need this mechanism to be able to inject credentials into a running application in the past. Whereas we don't have that mechanism, we don't have a pass, and so I I think that's a very astute observation that, if all we're doing is making this whole extra object thing that then turns around and puts it in native kubernetes resources.

F

It may be a great idea to cut the middleman out there right.

E

Yeah I mean if the solution of this might be just drop, the user brightest service concept entirely and say you want that concept, go, create a secret, create a pod, preset, binding and you're done.

A

Just make it on three cents: olicity.

E

Yeah so work through the the rosalynn see how it feels and we can then hash it out later, but.

A

This was a discussion, so port we're in time now. I will put the default values of parameters on a namespace level thing into discussion for tomorrow. Thanks everybody for joining, see you all on the Internet.