Kubernetes SIG Service Catalog, 7 Sep 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes SIG Service Catalog 20170907

Description

- F2F at Kubecon?
- Cut 0.0.19?
- Delete nightly travis cron build?
- K8s names of service classes and plans

A

Yep, thank you all right. Welcome everybody to September 7 2017 meeting of kubernetes six Service Catalog Erin says be Arby's Doug black! You do your thing! First, I! Don't all right! Well! I, wouldn't want to step on anybody's toes.

A

You wonder your thing than Aaron: do.

B

You want me to talk.

C

Hello yeah go for it, Aaron.

B

Okay, so normal thing today, I actually wanted to give a very quick announcement that I just put on the document before we start the poll for the keuken 2017 face to face has been up for about a week now, a little bit over. We have eighty eight point: nine percent of the votes given for Tuesday, that's December. Fifth, eight people voted for that.

B

You can go to the poll I believe the link is a couple of places below on the agenda, so we are going to meet for a face-to-face on that Tuesday, we'll get a room for that meeting. It'll be able to hold quite a few people.

B

So that's all for me just a reminder: we're gonna do the speaker, queue I, think everyone on this meeting is familiar with how that works and I will be taking notes. Would that go ahead? Doug all.

C

Right personal agenda, so Paul cut a release last night version 18, and there was a problem with the bill process as a permission problem and and kibbles has fixed it. The pr has already been merged. We have some people that IBM are really anxious for the multi arc images, which is what was not built as a result of last night's error. So what I'd like to do is create another release. Tonight version zero, zero one, nine, but I want to make sure that there wasn't any objection to it.

C

You know joins differences, we're not waiting a week, we're just waiting a day to do it, but we have some internal need to get a power official build out there sooner rather than later so. I wanna make sure everybody's okay with me doing. That is there any objection to creating your 0-105, no objections, but let the record show internal needs were accommodated. Thank you extremely much all right. Moving on then. So it's not Morgan looks.

D

Like you got a hand up, go ahead, no.

E

I just wanted it all so no objections all.

D

C

Got no dough all right! Thank you and kind of related to that as I was trying to figure out what was going on with the build last night. I noticed that we have a nightly cron job on Travis that actually just builds master and I. Think that might make some sense if we don't have regular things being merged into master. But since we do on a daily basis, have at least one or two PRS merge, it means master will get built on its own every single day. I!

C

Don't think we need to waste the CPU resources under those machines by doing a nightly cron job I was wondering if there's any objection to us deleting that lightly cron job, at least for right now,.

A

I'd be okay with it, especially because the number of executors I believe is for the incubator org in general, not just our project.

C

Exactly just shared I think it's more important that we clean up after ourselves, yep, okay, not have any objection, shall I make it known. Okay, thank you, sir Doug.

B

Are you okay with doing it? Yes,.

C

Luckily, have permissions I'll, do it yep all right? Next, a real topic issue, 802 names of plants and service classes now I know not. Everybody was on the call yesterday, but I did walk through a couple people. This proposal that I want to talk through now about how to deal with the names and changing of service plans and service class classes, and they paste a link to the proposal on there Morgan. Do you want to share that or you want me to share my screen area?

C

Okay, so go ahead and go to the next page. So just let everybody know the issue here is how to deal with the fact that a Service Catalog, spec I'm, sorry, the openers broker. Api spec allows service, hey, Dawson, I'm. Sorry, yes, I! Think.

B

Pau put a hand up about the previous point. Oh sorry, okay, I.

A

Just I just wanted to say I think this is one of the trickiest most insidiously complex problems that we had to deal with, and I really would like us before. We feel as though we've made a final decision to get some feedback from one of the owners.

A

Because I'm, not at all sure I'm, not I'm, not positive what they will say about either of the approaches that we have on the agenda for today. Oh not.

B

About the previous point, okay, well taken. Thank you for that Paul. Are we good to continue you're welcome and yes, cool.

C

Sorry, Doug go ahead all right, another problem, so just to recap, this issues about service class names can change and plan names can change, and obviously that means that we probably cannot use those as the kubernetes names of those resources, because cases that allow you to change names so in thinking about this problem when it just the quick summary I'm, not cleaning paul endorses this, but this is a result of a conversation of Paul and I had so not claiming anybody likes it or hates it.

C

Just just who was part of the conversation, so so in order to attack this problem, I got to be best to start looking at plan names first, because I think it a little easier to focus on those. So as you walk through these slides, you're gonna touch this on plans.

C

First, and my assumption here is that plan names must be unique across all plans within a given service, so they're not globally unique they're, just within the service, which means that the same plan name can be used by more than one service which just goes to reinforce the fact that we actually cannot use the plan name as it's real kubernetes name went forward because it's not unique and just to be clear as Paul polluted to earlier.

C

There is no right answer for this, so, ultimately, in all these conversations are about to have we're looking for the least bad solution going forward. So don't expect this to be anybody claiming this is perfect. Okay, so moving on next slide, Morgan actually jump forward to.

C

All right, so, let's take a look at what I think we want the user experience to be like for creating a service instance. In this particular case, there is a MySQL service out there and there's a plan called free associated with it.

C

We got this from the broker, so it's not under our control, but I believe what we're showing here on the screen is basically what we want, the user experience to be meaning the user provides us their own name for their instance, their native their namespace, but we want MySQL and free to be what appears inside the service instance, because that's what the broker gave us and I think that'd be the ideal solution.

C

Okay, so the key point here is this is using the real human real names, not something else that we either manufactured, or god forbid, even the ID. That's associate with these things. That's the last thing we want to do so. As I said, I think this is the ideal UX all right. So moving forward.

C

Alright, so if someone was to do using the previous animal and then they were turn around and query the service instance with my proposal, this is what they would see back and the stuff in red are the new fields that would appear. Everything in black was basically what the user provided. So, let's walk through these one at a time first would be a plan ref, which is nothing more than an object.

C

Reference to the service plan that they're that free is associated to or free represents, external ID is the UUID that we use to create the instance with the broker. That's as it is today, and the only thing that's really sort of new here, aside from the ref plan or plan ref is the actual plan name and that's set to free, and the way to think about this going forward is the plan name versus actual plan.

C

Name are kind of similar to what pods have or not pods replica sets have, with relation to the number of instances you've requested for the replica set versus the actual pods of the replica set right. But in this case, what we have is the user asked for the free plan and then the actual plan name represented. The status section represents the current state of the world as viewed by the broker, meaning he agrees. This thing's called free okay, so we get there, those two fields, perfectly aligned and everything's great all right. Any questions on that.

C

So far, all right so go forward. Two steps Morgan. So actually just one step. Sorry, so what happened at that was, let's say what happens when the broker updates, as planned, named to no cost instead of free for whatever reason? Okay. So now, let's go next slide. What's going to happen here, and this is strictly from the users perspective I'm not talking about what we do under the covers, and we detect this.

C

This is just from users view what they're going to see if they query that service instance is actual plan, name changes to no cost. Everything else remains the exact same so again. The difference here between plan name and actual plan name represents what the user originally asked for versus what the view of the world is from the service workers, point of view or the real environment. That's that's probably the the part of this proposal. That's that's a little bit weird.

C

If you want use adjectives to describe it, is that the the planning of an agile actual planning can be out of sync, because what the user provided us is not does not match the reality of the world as it stands today, but that's actually act completely accurate with dead zactly. What happened right?

C

The user asked for one thing, but the state of rule is something different, so the user can see the historical view of what's going on in terms of what they asked for and the real world any questions on that: okay, moving on I'm trying to go a little fast because I, don't think this is terribly complicated.

C

So now, let's say what happens when the user says: okay I want to upgrade my plan from free to know to gold, they'd, look at the yeah mo they change the plan name to gold and do a put so let's go to next slide, see what that looks like so here it's going to get exactly what they would expect the plan name as provided as input is now gold.

C

The plan ref will now be updated because they're now pointing to a different plan than they were before, I mean if it's thicker, that I pointing to the gold plan and the actual plan name is gold as well, because that's the state of the world alright moving forward if they were to actually list the service plan. So this gets a little bit to what's going on, though the covers. What they'll see is the kubernetes name for the service plan is the actual ID.

C

So, even though we're using the static native the static ID for the kubernetes name notice, the user hasn't actually seen that in their normal workflow, they kind of have to go out of their way and dig under the covers a little to actually get exposed to this ugly ID, but normally they wouldn't, they should not have to see it at all, which is exactly we want. The only other thing that's kind of interesting here is the service class.

C

Ref of the service plan will point to obviously the the service class itself, and it will point to that by service ID rather than service name and that's sort of a a heads up to where I'm going with this meaning I want to use the exact same mechanism for service class claims as well. Not just planning names all right going forward. I, don't see any hands up. So if you were to actually list the two service plans that we know about, but you'll see.

C

Are these two things here right, you'll see metadata down name for this, for the no-cost one is an ID, not no cost notice. External ID now is duplicate information, so I would suggest that we actually look to remove that feel because I don't think we need it anymore, and if we do adopt the notion of service classes using the same mechanism, then the service class ref will just have the ID for his name as well, and the exact same thing happens with gold.

C

Okay, keep going so under the covers. What's really happen here, as I mentioned, what we're talking about doing is I'm. Sorry, let's talk what happens when you do a relist and the and the controller notices a rename, so we're going to do is we're going to update the service plan, dot name with the new name and important to understand this is not the kubernetes name. We already have a name field, that's in the specs section and that's the one I'm talking about I'm, not talking about the kubernetes metadata.

C

That name and what will then do is we'll go through and find all service instances that reference this plan and updates the status dot actual plan name to the new name. Okay. Now it's important to note here. That's the the field that we're touching is not in the spec, so we're not changing the users data on them per se.

C

What we're changing is the status and that's allowable for us to modify now, obviously going through and touching every single service instance that references a plan may be a time-consuming process or expensive from that perspective, but I, don't think it's critical that this change happen instantaneously across all instances. They can be in an eventual consistency, type of action, because this field called actual plan name, isn't really used for anything. It's it's informational purposes only for the user just to give them the state of the world. They don't ever really need to use it.

C

So, and so it's not that big a deal, but I don't expect this to take that long to update. So it's not it's not a big problem. In my opinion, the most important thing, though, is when we detect the name change that going forward. If the user does try to use that plan going forward, they have to use the new name, meaning no cost, not free, and that will be instantaneous.

C

That I think, is the really the only requirement that we have going forward here. All right. Any questions on that. Alright, next lesson, taneous one more time it will be instantaneous, is the plan name. Change will be instantaneous. So if the, if the minute, we notice I'm sorry the minute, the realist is done.

C

If the user tries to use a plan, they have to be using the new name, not the old name, because that's what the broker knows about. So if they were to to list out the current plans for a particular service, they will see the new name immediately, not the old name, okay with which happen automatically, but it's just the the twiddling of the survey of the existing service instances might take a couple of seconds depending how many there are alright. So moving forward.

C

C

Alright, so what I'm sure I've mentioned earlier is I'd like to do the exact same thing for service classes, so inside the service class resource, the kubernetes name field will be its ID and the name inside the spec field will be the human readable name so go forward. What does that mean for a service instance notice here it's stuff in red is what its new.

C

Beyond what we talked about earlier service class rep will point to the service class itself, probably by ID, and then the actual service class name will be the human readable name MySQL. That way. If the service class name changes, the user can see the class name if they recently asked for versus the new class name.

C

So the exact same mechanism, alright moving forward. It looks.

E

Like the same mechanism, it.

C

Is the same mechanism? Yes, I said yes, okay, let me let me pause here and make sure there aren't any questions. I, don't pull your hands up, but before I start talking about additional suggestions or open questions that sort of came up after yesterday's or during yesterday's phone call. I wanted to sort of pause. Here's I think these are all additive things that we could do if we, if we like this general direction, so I don't want to sort of confuse things by going too far too fast. So let me take some questions.

C

First, like it's Paul you're up first.

A

So I can think of how this breaks cube, CTL apply, which I realized only since you started talking about it here. I think that I'm personally going to need more time to think about this. One and I, like I, have said earlier: I think that I also run up another a different proposal that I'll describe after you're done and I would like I think it would be good if we could take both of those, because I think that they're probably the two ways we could try to skin this cat and see what the owners got.

A

C

No I agree with that. Can you elaborate a little on how you think apply brakes? Yes,.

A

Like this, so for reference, what apply does what keep CTL apply does? Is you point it at a file and it makes sure that what is in that yellow file is in the API server, and so what you could do is you could say that you have a file with a service instance and you use that either with apply the first time or use it with cube, CTL create, and so now your services instances in there and then Brooker changes the name of plan and now you're yellow file.

A

Has your llamo file, has the old plan name and when say that you changed the parameters in line parameters on the instance and you run cube CTL apply again, it sounds to me like you would get kicked that that the update request would be forbidden because it's using the old plan name. Is that right, no.

C

I think would be okay because we talked a little bit about this tangentially yesterday.

C

If someone, let's actually change your scenario slightly first, let's say someone notices that plan name and actual plan name are different if they wanted to, they could do a put to the service instance and change the plan name from free to no cost. We should be able to look at that and detected and say: okay, that's a no op and allowed to go through because, as we know, what the real plan name is right.

C

So if you take that the next step further, if someone gets the yamo from the service instance- and it still says free and they update the parameters when they do the put or the apply as you're suggesting we can look at that and say: okay, you know when I, when I send my update to the broker. I know what the real plan name is. It's no cost. You know forget the fact that the user originally put free. We know what the real plan name is its no-cost.

C

That's what we use on the request of the broker and I think everything works. Just fine and at the same time we could use the update the the plan name of the spec or not, you know that's sort of the users of the site or they want to mop. They got yeah.

A

So I guess my only suggestion would be to give some more treatment to that scenario, so that it's clear that this proposed solution addresses it. Okay,.

C

That's not a big deal like I said: I, don't think it really changes anything because we have all the right information to send a broker, so I don't think the broker should barf on anything. So let me just have to talk about some of the things that we talked about yesterday in the call so I think I, think selay suggested or our questioned whether actual plan name and actual service name might actually be generated. Fields.

C

That way we don't have to have to worry about this notion of a time delay between a realist and users team that the new value, so that's something else for us to consider. We might be able to make those generated fields I'm, not sure what kind of impact that has I know. Paul you've had some concern about generating fields in the past.

C

Okay watch, yeah that we did. We did mention that one yesterday yeah for those of you don't rip, don't know, watch will not work on generated fields because I believe that watch acts or does its business on the database side of things not on the output of a get, and it's during the get process of saying that we would actually do the generation of this field so I think. Yesterday we talked about this.

C

We acknowledge that that would be a problem, but we weren't sure how big of a problem it was because we weren't sure how how many people would actually want to watch the actual plan name, but it is from a sharp to architectural a pure perspective. You correct it would break watch.

C

The other thing we talked about was I think this was from Aaron yesterday. He was saying that one thing we may want to consider is because there could be a time delay between the realist and all the service instances being updated. Perhaps we had, we should have some sort of dirty bits on the service instances. So the user can see that this. This migration of all the service instances is underway and hopefully Aaron the the nested bolts.

C

There shows the exact flow that you were thinking of yesterday, which is we detect the planned change we go through mark all the instances is quote dirty or change on the way or something like that, and then we actually go through and update the service plan on the service plan itself to play a name on the planet itself, then we go back and actually touch all the instances. I think that was a full. You describe. Okay, thank you, yep.

C

So that's something else we can get consider yeah I think Aaron also wondered whether we should include a timestamp on the service class and and the plan to indicate when the name changed in case that's interesting to some use cases and then, of course, what I mentioned earlier is. If we do go down this path, we can remove the external ID property, so I'd recommend we actually do that and then I think relay mentioned. Should we then move or should we move some of these fields, in particular external ID service plan, ref and service class?

C

Ref into the status section since they're, not under the end-users control, they're, more managed and owned by the controller itself, so they maybe they make me they may make more sense to be under the status instead of the spec.

C

Any questions on those I, don't think any of those fundamentally change the proposal they're just additive things we can consider alright. So let's go the next final I think this is the final slide, one more in terms of the current issues. Obviously, 802 I think this directly addresses that 686 I'm, sorry 868. If we remove the external ID, then I think we can close with no action 868, since the field goes away. If we do keep external ID, then yeah I think I think it was Paul.

C

This we could just create an emission controller to to block updates external idea to make sure no one else can update it hanging, including the service controller, either think but anyway my problems will be to drop external ID anyway, and just close it, but anyway, I think that's the whole proposal and discussions cool.

B

So we've got Paul I. Think Paul. You have two hands up, not sure. If you address the first one so I.

A

Just the first thing was that I think we should close 868, because it will necessarily be addressed as part of the eventual solution to issue 802.

C

Well, I'd rather wait. Can we have the solution first or close? It just in case we're wrong, but yeah.

B

Okay, cool any other reactions, comments, objections, etc. On this proposal,.

B

Own once stunned silence, all right so sounds like we might need the day or so. Maybe, since we're not gonna meet tomorrow, maybe the weekend to think about this, and we also had on the table bringing this to some of the kubernetes owners to see what they think and possibly get sign off. Yeah.

A

I, don't think we should consider any consensus on this binding until we get approval on at least one option to choose from and I have I have an alternate to this. That is also been.

B

Eaten so I'd like to put an action item out there for this proposal and for the other one Paul for yours, for you guys to go and bring something or some thanks to the owners to get their take and then bring it back. So we can all get consensus and I think that sounds.

C

Reasonable Doug yeah, that's fine I, just who are quote the owners. People.

A

In the top-level owners file of kubernetes, ah those.

B

Guys, okay, thank you. Alright, so I'm gonna put this down. This is Doug and Paul.

B

All right is that just about accurate, Doug and Paul.

C

Yeah I looked write to me. I would I would like, though, before we do that I'd like to make sure that or I like to see whether this group has a preferred approach going forward. To be honest, if we, if it has a group, we prefer one approach, but then the other guys go for a different direction. I think that'd be bad.

C

Okay, so I'd like to see if we can come to consensus, at least within our group not necessary today, cuz I do think people need at least the weekend to think about it, but maybe on Monday before we go up the chain I'd like to see if we have consensus within our little group itself, first, okay, so.

B

Paul is your proposal on the agenda for today? Yes,.

A

It is on the line below the first line. Under this got it that's.

B

Okay, alright I will remove this action item and put an updated one after we go over your other proposal. Okay, Morgan. You want to open that so.

A

B

Just one second, so are we all? Does anyone have anything else on this proposal? What a dog is presented going once, okay, which link hard but.

A

It says alternate proposal: okay,.

A

Okay, you might want to put a little a little bit yeah, please, ah okay, so assumptions that I I should air before I talk through this are that name. Changes of services and plans are deprecated as we agree to an open service worker API face-to-face, and that means that we don't have to accommodate them in a first-class way and another assumption from a thread.

A

Email thread that we had with cig architecture is: users should never have to look at non human, readable names of services or plans, and so, if you scroll down a little bit yeah there, we go scroll back up scroll back up there.

A

We go okay, so the proposed changes are that we take all of the existing fields on service class and service plan and move those to new spec, structs and add status to service class and service plan, that we retain the existing external ID fields and ensure that these values are immutable for a particular for a service and plan, and that we make the kubernetes names of service class, the broker name, service, class name or service name, and that we make the new kubernetes names of service plan, broken name, service class, name, slash service plan name and that we add a new status in active boolean field to service class and service plan.

A

And so, if the broker changes the name of a service, we set the status in active field on that service class, set a status message saying that the service has been renamed and do not allow new instances to be created of this service and then basically the similar semantics for plan. So if the broker changes, the name of a plan will set the status that inactive field on that service plan and.

A

Set a status message saying the plan has been renamed: do not allow new instances to be created on that plan.

A

Service instance keeps the same fields and uses the full turbine Eddie's names to reference service, class and plan, and then, if you scroll down Morgan, there are like proposed API changes. So people can see what this would look like and I forgot to add the oh, no I originally when I started. Writing this up, I had inactive on spec I, moved it to status. So let's look at the example so.

A

Say that you have a broker test broker, whose catalog contains a service test service with plan example plan one you get the following resources, so you'd get a service class with the name, test, broker, test service and all of the current fields that we know and love under the spec and you get a service plan called test burger test service example plan. One.

A

With all of the fields that we're familiar with under spec and then, if you scroll down just a smidge more a service instance referencing, these would have in the spec service class name test per core test service plan name test burger test service example plan, one which I will reiterate that I do not think there is a perfect solution. I think these api's are deeply and profoundly mismatched and.

A

The the following, bold in the next sentence, is a symptom of me thinking. It was funny to make them bold at like 2:00 in the morning when I was writing this up so know that that's my attempt at humor and say that if a broker is poorly behaved and intentionally uses to use deprecated, behaviors and renames example plan one to example, plan 2, then we we get the following. We have a good old briefing to the point named chest, burger test service example. Plan 1 would have status inactive as true and have a message saying.

A

This was renamed to test protest service example plan to just rolls right off the tongue, not a lot of work to say, say it once say: twice say it as many times as you want and I have another service plan test for test service example plan to with the fields that were familiar with. So basically, the difference between these two approaches are that the one that I'm suggesting makes knows.

A

Basically does not attempt to achieve something like visibility into. There was a name change.

A

That's on the instance, although I guess we could make an additive change to this and say that when you, when this happened, we might put some piece of status on the instance but I'm going to stop talking now. I see, do you have a question or something to say, remember we're being recorded, so you should hold all things you wouldn't want to say in front of the internet for later nevermind.

A

F

It seems like one of the things that, by doing the inactive, an inactive message allows you to do is to go ahead and convey additional information rather than just rename, which I didn't see in the original. If you scroll up the problem statement, what problem are we trying to solve.

E

There isn't really one I can go to the top of the issue. I guess.

G

Now the idea is that.

E

The name change thing: yeah.

F

So it's only the name, change thing, but also I, don't remember if he talked about this in the context of the the OSB face to face or if we talked about the kubernetes, but there was some thought about: how do we go ahead and duplicate versions or point users to a different version? So this plan allows for that to happen as well. I think it would be beneficial to capture that somewhere, because you provide a solution, but you don't provide a problem.

A

You don't feel that what is on the screen right now articulates the problem.

F

F

Think that, for example, the inactive message is not necessarily captured in this one, because basically we are solving couple of things. That is not just the breed name. It also says this allows you to go and roll forward a version provide a pointer to you and everything else.

F

This work assists broker, can change the name willy-nilly, and the problem we are trying to solve is because we mapped those names. The cube resource names which are immutable and both of these solutions that I proposed solve those as well. I would also like to capture the additional problem or a requirement or whatever the heck. It is to go ahead and say we also would like to confine other things to it, because otherwise, I don't like we will meet the inactive reason right. I.

A

Think Doug, you and I could probably work together and come up with a list of the all the problem we're trying to solve and state, maybe a little bit more clearly or and.

F

I'm, sorry, that is not meant as a criticism I'm just saying the the solution is way more complex than what the original problem statement is. I. Think it's an elegant solution. We talked about that in the face to face, as in it's a very good use case, we should support. I would like to make sure that we have here's the concise statement of all the things we are trying to solve it with this and I think we can solve them with this one particular approach.

B

Cool I put a hand up. I also agree. This is a pretty elegant solution. My only issue is with the naming. So if oh sorry Doug it's okay, please I missed that. Please go ahead! No, no go in finish, I'm! Pretty much done the naming here, because it includes the broker name. It feels a little bit well. It is a little bit less portable across different environments that run different brokers, but those brokers provide the same services.

A

Fortunately, service class names or service names are only unique within a brokers. Catalog.

B

I'm talking about instances referencing a service class, a kubernetes service class resource, so in that case the serve the community service class resource names will be different across different brokers. That's my concern. I.

A

B

Underst infant clusters.

A

Where the broker has been added with different names like I, called it Asher and Jerry, called it Asher with two R's.

B

That's right so to choose. The two different service classes will be named differently.

A

If you installed the broker in the same chart as the rest of them, I guess it doesn't matter, but.

A

Yeah I guess in a chart you might have to say here's what I call this broker and use that to generate these things in line right.

B

So yeah, that's all for me. I, like the I, like the way that the indirection works. If a plan or service is deprecated, you can follow it to the non deprecated newer one I like. That, though, is it for me sorry about skipping. You Doug, please.

C

Go ahead, yep, not a problem, so viel a I think what you're talking about there is something that's a little it's much broader and I, don't think either these proposals are actually trying to address it. That whole notion of versioning of these things, I think I agree with you that we did. We did talk about that at the face-to-face, but I think that's something that has to be solved.

C

That's a spec level, not as part of this, because the current version of the spec, when it talks about a name change, they're, not doing it as some sort of versioning thing, they're doing it just because they treat these the name as just sort of a as a as a human, readable thing. It's not meant to be something that's set in stone right. It's almost like a description field in a sense right can be easily changed, and so it's important understand that the inactive, what's it called an active message.

C

Whatever that thing is that Paul had, and it is that's simply there for people to to follow the link if they ever need it for some reason right. It's not I. Don't think meant to represent some sort of versioning scheme right, so I think it's important distinction there and if we want to try to address the problem of you're describing or.

C

Do we lose Doug I? Don't here, Doug, I'm, sorry, I hit the mute button by mistake. I think that's something we need to address in the Specht. We actually want to talk about a real versioning scheme. I, don't think it I think it'd be a big mistake for us to try to add that to our stuff when the spec itself doesn't even talk about that now to the proposal itself. What worries me about this is twofold. One is asking people to do.

C

Concatenation the names I think is not only just kind of hokey, it's actually very problematic, because if people start using dashes in their names to begin with, then the potential for overlap between brokers, services plan names to met to match up previously existing one in the system goes up them and so I think we're asking for potential conflict in the future, whether it's a big one or small on I, don't know, but the fact that we're just going to do string concatenation on these things and ask the user to perform these things, you know have to duplicate the service broker name in multiple places.

C

Just so they can do a string. Concatenation I, don't think, is a good user experience. That's why I prefer the approach I gave because it gives us the exact user experience. We want people to have without any potential risk of conflict whatsoever.

C

To me, the most important thing is user experience on all this. If we have to jump through hoops onto covers, that's our problem, but as long as the user experience is nice, that's faster, but what matters most.

D

E

You Aaron is there a direction.

B

Right sorry, good good I was muted, apologies, Morgan I. Yes, you are next go ahead.

B

E

Multiple points, I guess the I don't see how this is any better than this.

E

You can say: yeah, oh yeah, that's the broker name, I mean that's the, but it's not gonna say broker here. It's not gonna, say service. Here, it's not gonna, say plan. Here, it's gonna, say cute. You know X on my sequel, free or something it's not. It's not gonna. Look as pretty as this looks. Ron I I need to just come up with somebody who's providing a service man.

E

So I don't see how that's more user-friendly than than just a unique whatever is first of all. Second, this is ridiculous. It's too long. It's no!

E

A

Not a reason yeah.

E

It's kind of a reason: there's definitely the this. These get put into labels sometimes and things get funky. When you do that, if we've already seen that entire object, specs get serialized and slammed into labels to I mean.

B

As the keys was the key, the.

E

One person that time.

B

E

And then whatever Doug said, was pretty good Aaron set a point of you. Can you can use this to follow the updates? I? Don't I, missed I, missed the explanation of how to do that, or is that in this thing at this part, I was.

B

Referring to the inactive message, okay,.

E

Well, that's not necessarily I mean I, guess we're setting that so we can choose to have that, but that isn't guaranteed to be that that that wasn't specified in this thing as far as I can tell so, if you want to you want to make it specified, you know you know updated too. It's not a message. It's an actual field updated to. You know pointer to the next plan that that makes sense. Otherwise, I, don't I. Disagree with that statement, but okay done cool.

B

Cables you're up next go ahead, so.

H

Though I wonder about how the second approach would deal with like the default plans of services, because I feel like default is something that you could definitely have. Multiple plans be named default at like different times, but because you're using the that can concatenate its stringing as the kubernetes resource name. That could get us into a lot of trouble like if one at one time there was a default plan and then it no longer became the default and a new one became default. So I'm curious to hear the answer there, I.

A

This matrix of the emission controller you're, referring to would probably have to change too. If there is one one plan that is not. You know.

H

So I don't mean that, like default, I mean literally the string default like if then like, because that's kind of a name that you could see bouncing around. In my opinion, I I am still not sure what you mean so there's a plan in the service class called default, so you have like default light premium or something and then they, the broker manager, decides to change that.

H

So like let's get rid of the default plan, let's change to be our default, so they renamed light to default, and then it's just default in premium, so the name changed, but the kubernetes name, we're gonna have a conflict there. If we mark one is inactive, but then we want this other we're creating a new one that has the exact same resource name as though old default.

A

So you're talking about if there are name changes multiple times and you like rename default to not default, and then you rename it to default again. No.

H

No so let's go, we have three plans. We have light default and premium onion, one sir. Then we decide we don't like the the default plan anymore. We're getting rid of that light, becomes our new default now, so the service broker decides to rename light to default and get rid of the default plan and or mark it as normal or something and and so now lights. New name is default.

H

A

Think this is a case in point of why renaming services and plans is extremely user. Hostile, yeah I, don't have a good answer for it. I, don't think anybody should ever do it and I yeah, I I. Think it's a terrible thing to do to users is my response to that. Okay,.

H

But but this situation would break down in that case right yeah. Yes, it would okay just wanted to throw that out there right.

A

And and I'll say for the record, this is not an attempt to comply with infinity renames, because I don't think that we should allow those I view it as a major weakness of the spec and like the the prior guidance that I've gotten from Brian grant is that we do not need to necessarily accept all the shortcomings of the spec.

A

We should make move to make the spec better and and do what is right for us, assuming that we don't get ahead of the spec but I think after open service, Berger, API face-to-face, we all agreed. This was deprecated. I made a pull for it, yet it's not merged, but it will be shortly. Hopefully,.

B

Okay, so quick time check, we've got seven minutes left. We've got three people on the queue, so this is probably gonna be the last item we talk about with that. Paul. Have you next on the queue? Do you have more to say, I just.

A

Want to know where we all send the bill to Cloud Foundry for the amount of time it's taken to discuss this.

B

Yeah, maybe put your Bitcoin wallet address in the issue: okay, Doug you're up next go ahead. Yeah.

C

So just to sort of follow on with what kibbles was saying, because I'd never actually got to this. It was in my original slides. One of the reasons that I don't like this approach is because once a broker chooses a name for like the plan as long as that plan continues to be used by somebody in some platform to which that brokers registered, they will never ever be able to reuse that plan name and that places, in my opinion, a really large burden on the broker going forward.

C

That is not part of the specification, and that creates quite a large interoperability issue, because that means they broker. That today is can be registered with Cloud, Foundry and reuse. An old name that they happen to use three years ago may not work with with kubernetes going forward, because we've kept around there's old plan, name it and the planning has been deprecated or marked as inactive, but because someone's still using it in our system.

C

We won't allow them to to to register for their broker with us anymore or allow their relist to go through and I. Think that's a problem going forward, but I just want to point out that even if Paul's PR for the deprecation of allowing renames goes through, it is just deprecated. It's not flat-out banned, which means it is a valid use case that we know some brokers do use.

C

Today we don't know whether it's a large or small percentage of them, but we do know it does happen today, which means all those brokers will not be able to work against kubernetes going forward or they'll. Have this issue point forward, so I just want to point that out cool.

B

All right, veal, a you, maybe have a hand up so go ahead. If you do well.

F

Yeah I mean I I do again think that and and maybe I'm just beating the dead horse. It's I feel like we have simplified some of the assumptions and some of the constraints that we have in solving this problem, because I've heard a couple of times like you know like in in this case, the the one of the most users should never see goods, and then one of the things I heard later on is well.

F

Usually shouldn't see these things with the metadata names and I think the better way to go and say is you can't confuse them, but I'm not sure that really requirements, but you could certainly see where, in this case you could have I, don't know work or test, and the protest service would be named. The plan an example plan, so I I didn't I I was expecting that the the is we're just examples and and we would choose a delimiter that was not allowed in the canteen I.

E

Mean the name is, is that's it, it's simple its letters and dashes. That's it. Okay,.

F

Well, whatever I guess I guess we will use unicode turd as the delimiter um Julie.

A

It's like we were separated at Birth man, I was thinking the boot character. That's.

E

That's not a letter or a so ah well.

F

Yeah anyway, so I feel like we are kind of doing this I kind of feel like we as we are talking through these things, there's a couple of things that are coming in that are not necessarily stated and I feel like they need to be gathered somewhere. They are gathered in this recording that nobody's ever gonna. Look at.

B

F

B

So we have two minutes. The one thing well, there's two things I've heard here: one is: we need to consider these two options more before we go into before we go into the the owners and ask them what they think we need to have a better list of requirements is what I've heard. Are there any disagreements that.

A

B

Okay, go on once anybody else. Okay, I'll write up some action items there, I'm gonna, assign them to the late Paul, Doug and myself and will solicit others to join. I will also take an action item to move the orphan mitigation and scope of service cat resources into Monday's meeting and also I. Will echo Morgan's plea to review pull request number 11:06, because I know that hasn't been mentioned yet that the link there is in the agenda?

B

What that is there any other business that someone would like to cover in one minute going once okay? So this will be the last meeting of this week. We'll see everybody on Monday thanks, I'll see ya.