Kubernetes SIG Service Catalog, 18 Jul 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes SIG Service Catalog 20170718

Description

Design meetings:

- Orphan mitigation
- Name of BindingResource
- Secret parameters

A

Okay, welcome everybody to the Tuesday July 18 2017 meeting of terminated, cigs Service Catalog, we're continuing design discussions today about What's in scope for beta and what's not I will go ahead and well would someone else like to share their screen and should the agenda and be the note-taker I am absolutely awful at talking taking notes? At the same time, I'm.

B

Happy to start.

A

B

Can people can anyone not see my screen I.

C

D

Little small side.

B

That better done yeah. Thank you.

A

Okay, so the first I'm on the agenda for today is work on mitigation.

A

So I am adding links to that into the agenda now and what worked in mitigation refers to is basically error handling for situations where you provision an instance and the provision operation times out as an example and you're, not certain whether it was actually completed at the broker or what it's kind of in an indefinite, State and I think this also applies to updates and there's a facets of touch solution to I.

A

Think that we should do this for beta, because it's about ensuring that you don't have these four framed instances or bindings that might incur a monetary charge or a resource usage that you don't intend. I.

A

Think that the semantics of exactly what the write error, handling are are not super clear and not especially well defined in the spec. So I would definitely like to get a agreement on what the semantics are in the API working group.

A

But does anybody disagree in a vacuum that this seems to be a pretty central part of the spec, but perhaps not given it as prominent treatment in the spec as it deserves currently, but I hope that we can change that as we make clarifications, it seems like by the decision plan to make open, serviceworker API integration as solid as possible, that this would be something we'd want to have for beta in thoughts.

D

So I agree with hardening it up, which which aspect is fuzzy, that we need to get clarity on orden. You can make a decision well.

A

So right now in the spec there's one like table of HTTP response codes and scenarios where you have a timeout or you don't. That is sort of meant.

A

It is like treated as this is just what you look at know. What to do, but I, don't think that it's universally applicable to all the resources that it applies to like I, think there are cases where you'd want to treat a certain EXA code or a certain HTTP status code that might be valid, for instance, I differently, then the same status code that wouldn't be valid for a binding. So as an example as an example, the status code for excepted is definitely one.

A

That's valid for operations on an instance if that incident supports or if the, if the broker and the client support Aysen operations. But right now, since we don't have asynchronous bindings, it's not valid for bindings. I think it would be great if we could wind up in a state where the orphan mitigation is defined like separately for instances and bindings, and it's really specific so that you don't have to make inferences about what might be accepted. And what might not be for a particular resource time so.

D

What do we need resolution on introspect before we can make progress here, or do you think it's independent I think.

A

That we well Aaron has already started opening an issue for this to add some clarification. I would just like to get clarification on bindings, I, think Aaron's issue and poor request has to do with clarifying it for instances, but Aaron you probably remember better than I did. Is that accurate? Yes,.

B

That's accurate and I someone dug, you might have been. You request them to add at least to add specification for bindings as they currently are in master orphan mitigation, specifically for binding sorry, so that might land them I lent. An FPR I think that's reasonable, and then we will deal with the orphan mitigation for async bindings. As we add as we work on work through the async bindings PR as well. Yeah.

D

And that sounds familiar um I guess the point of my leading questions was to get to the point of what can we decide today for our stuff before we make any spec changes, and if are things we give our decisions that we can make right now what the DuBose will be put forward so I view the.

A

Situation basically, as like I think, all of almost all of the details are probably encoded somewhere in the spec, but they need to be massaged a little bit just like a number of other things have been I.

A

Don't think that were there's a any case where there's anything but oh yeah well for binding that one wouldn't be valid, but we kind of treated this as like the one place for everything if we make if we get the orphan mitigation behavior defined for instances separately for bindings and locate those things near the the right portions of the spec I think that's enough I, just it. It seems to me like it, should be pretty cut and dry I just like to get everything merged into the spec before we make additional changes for this yeah.

D

No I thought that wasn't clear. My question I meant to ask, is: is there anything we can do in a service catalog today before those spec changes, go ahead, yeah.

A

So when one thing is that I already have a poor quest open to stop retrying a failure, provision operations that the broker has said have failed, um which is part of being compliant with the spec I, think that's pretty unambiguous I was hoping that somebody else could go and do the same thing for bindings and that will probably I don't think Peter. Those are controversial as things that we should do and they move us in the direction of implementing the orphan mitigation. So there are definitely.

E

A

We can make progress on without having to have clarity on okay.

D

So are there any open decision points, then that we need to make right now, nope.

A

I brought this up as an example of something that should be really easy to agree upon, but that I thought was significant enough, that we should discuss it as a group in one of these meetings.

B

Yeah I think Paul what you said about not retrying is that sounds perfectly reasonable for instances otherwise known as provision on the OSP spec I. Think it's reasonable also to try to do the delete in the follow-up PR to that form.

E

B

Would say we should probably wait until the PR until I hear that I have gets merged. I'll have to add language to deal with binding orphan mitigation and then until that PR gets accepted. I think that would be the right time to do. The deletes unbinding yeah.

A

So, as a next immediate step that we could take on binding, I would suggest basically the equivalent of what I did for instances and the for requests that I have open, which is basically just to add a failure condition and if the broker returns, something that indicates a failure to no longer retry. The binding, yep yeah absolutely agree. Okay, so I I will add an issue specifically for that, and I am hoping that somebody would like to to make that change.

A

That would be a good one to make for somebody that hasn't made as many coaches as myself, which I remember, is every one. So just in terms of growing the pool of people that can make the API changes that one's pretty kind of dry. That would be a good one to make for somebody.

A

A

Okay, does that conclude e.

A

Does that capture everything for that? One I think it does.

F

B

So I think everything is captured in those No Paul. Can you put the binding issue into slack when it's up yeah.

A

I started, I started typing it and once I, once we're done with this meeting, all wrap that one up and I'll put it in the channel sure.

B

Yeah, whatever okay.

A

All right, so next up, it looks like Doug, has an item on there about renaming binding. So in case folks haven't seen the meeting where we discuss this.

A

We definitely need to rename binding because when you use there well, because there is a resource in the kubernetes v1 API called binding that the Scout would the scheduler uses to make assignments of pods and nodes, and so, when you're running behind the aggregator and you use cube Cpl to try to address a binding, you get a naming collision and you have to use the fully qualified name of the resource which is kind of cumbersome. So we definitely need to to change. The name.

A

I am very happy to spend a few minutes talking about what the name might be. Doug I think you've got some opinions on that I've been thinking about it a little bit. If we do that, I think that we should try to time box that'sa, like maybe five to ten minutes, because naming discussions tend to be a strange, attractor and more difficult to agree on than ordering pizza. So if people are ok time boxing in maybe two ten minutes, we can definitely talk about that now. So.

B

Real quick I put into this document a per yesterday's meeting. There is a larger scope issue now, for general guidance on how to name resources. I think that it's just worth mentioning, but it's not worth coupling that issue or that decision to this decision any more than just writing. It is here.

D

Okay, so, following on from the stage discussion or like I, said that should say agreement to prefix everything with service catalog. My proposal for this was a service catalog key because that's consistent with what Cloud Foundry caused these resources, I believe now put in prose Oh for I want to say instance, secret key I'm. Sorry I have to go. Look it up. He had a different proposal.

D

So always in fact, this key was his proposal, but so I guess to be service. Catalog instance. Access key I, don't have a huge preference other than that you have. A plumbing I have a slight preference towards just service catalog key for consistency with Cloud Foundry, but other than that I. Don't really care it's too much. So.

A

If I remember correctly, the service, the the service key in Cloud Foundry, is what you use when you use a user provided service and they.

D

A

It's all good, so can you provide a pointer to the doc? Would you be willing to do that that describes whether it's service key is because I, don't think that's part of the spec at all, like I, have not seen the phrase service key that I remember being in the spec.

D

I'm sorry, a lot of you know it's not part of the spec as part of Cloud Foundry. If you look at the link, I just pasted it in there service Keys are basically your way of saying I create an instance. All I need other credentials, so basically it's kind of like doing, though the binding operation, without linking it to an app.

D

In fact, you can also see it through the telephone command line. If you just do the help and look for service service, key you'll see it in there as well.

A

In true github fashion you're, the link that you made to the comment opened a completely random part of the of the issue. The.

D

Poll, oh, wait. No, wait! Look at the link in the chat; okay, sorry, the wrong thing: does it take you to the Cloud Foundry documentation for service key and in particular, if you want to looks like a command line, here's the simple command line that they sent the chat as well.

A

So how is this implemented in Cloud Foundry? Does it use a binding yeah.

D

I mean basically the open-source program. P I call is to create a binding, just don't provide the what is the app ID stuff? Okay,.

A

I got to say, I. Think service key is not a name that anybody is going to understand what it means and I. Don't necessarily think that making things consistent with cloud Andreea is a goal.

A

I'll I would consider it I'm not saying no, but I would like to learn more about it. Like.

D

I said: I: don't really care that much about what it's called other than I have a slight preference for this cuz there's precedent, but I need a country rules old sport if everybody says they're, not thrilled that, but I have yet to hear very many alternatives. Aside from nails. Well,.

B

Either maybe we can just keep it let's decide between this and Neil's name. That's the only way we're going to get through this in a reasonable amount of time. Yeah.

D

Here's what Neil's is hold on a Service Catalog, that's what his proposal is vs and.

D

So I think those are the two proposals been put forward so far.

A

So here's another one which is I worried that since we tend to explain the open, serviceworker API in the same context as we explain the kubernetes api for catalog, that I am worried. If we say oh and then there's this bind operation in the serviceworker api. That and in the same breath we say- and it's called service key in kubernetes- that it will be confusing I.

A

D

No, what could my one thing, Paul III, think? Well, what you said is true that right now we do end up discussing sort of the kubernetes resources and deserves world API to people, because we're telling them about the open source, burger guy I think this particular issue. We need to look at it. I mean users kibrit at ease and users, point of view where they're not really going to know or care about the open source program yeah, because it's an it's an almost invitation, detail.

D

I think the most important thing here is kind of with even a word that matches encourages users, expectation and meet claims of them, not necessarily for open source broke API yeah I can every review that.

B

A little bit I've done this I've done this explanation independently from OSB. Quite a few times, I haven't tried to explain things with another name besides binding, obviously because that's what it's called right now, but the way that I've explained it is when you create an instance that creates an instance of the service when you create a binding. That is what allows you to access that instance of the service. Now, if I, let's say, I went and started trying to explain service catalog key.

B

What I would probably say is when you create a service catalog key that returns to you all of the data, that you need the credentials and coordinates that you need to access the instance so really what it would be about if we use Service Catalog key, is getting people to just memorize a term instead of trying to get them to make sense of it. In the context of the kubernetes resource set yeah.

A

I think that's bears so I think the yeah instance credentials could definitely be one I, I think I, like instance, credentials better than key, because key is very hard to reason about what that might be in a vacuum right and if you say instance, crit tools, uh that's a little bit more descriptive.

A

Let me be that guy and offer another complication, which is that I think long-term if we've kind of diminished the extent to which we've talked about this, but we usually would run sorry not usually when we were starting this sig, we had talked about it being important to be able to manifest the different parts of the find response into the appropriate kubernetes primitives, so that you could put config into a config map credentials into a secret and maybe make a service with that that fronted.

A

The coordinates that you got back I still think that would be good to do at the very least for credential are sorry for config maps and secrets to differentiate them. So that might be something to think about.

A

With regard to naming this resource and Jessica has also pointed out that.

A

Generally, kubernetes kind names are singular, although I think endpoints is the exception to that. So.

D

Mama was up in the S on credentials. I accepting credential makes more sense. Evil sounds little orleans all right, that's so hard to say, but Aaron I wanted to point out. One thing, though I suspect in most your conversations using the word binding up until now, probably just seemed to make a whole lot of sense.

D

Imagine the future when you have to explain to somebody that they may have to create a binding resource and then a preset binding resource as well I think the word binding being places might actually be really confusing, because one of them is X binding, yeah.

A

I tend to agree with Doug about this, since I definitely view the long term thing that will converge upon to be there's a resource that represents the open, serviceworker part of the bind operation, and then there might be any number of resources that govern the consumption of that binding in kubernetes like pod, preset I could easily see another resource that built a V cap services. Environment variable I could see another one that did an histy o rule. I could see another one that did a network policy rule so I.

A

Imagine that will probably wind up within other resources that it might be easier to avoid the use of the term binding, actually not I, think about it. So I'm not sure. Yes,.

B

This is hard point to your point. Yeah I mean that would it's doable still that it would get harder, but so all that I was illustrating there is that to date, I've had this same tutorial session flush, discussion, I, would say between 10 and 15 times, with everyone from people who are hardcore, CF users to people brand-new to kubernetes and never used CF before mostly people are Microsoft engineers. Some of them are PMS, but they're all Microsoft people.

B

So what I was trying to illustrate? There is I use binding independently from the OSB / CF, binding concept and, in fact, with the Cloud Foundry hardcore people I take great pain to separate the kubernetes binding concept from the CF binding concept for a couple different reasons. But if we changed over to something else, just want to illustrate that I would still prefer that we keep it separate from CF. So if we use Service Catalog key, it would just be a matter of separating it from the CF key concept and then getting the minima.

B

If it sounds more semantically meaningful, then I would just focus on getting them to understand what the semantics meaning meaning of it is, and then they understand it at that point, sir I'm not too worried about the specific name as long as it's something that makes a reasonable amount of sense. You know not gobbledygook or foo, or something like that. I tell.

A

You what let's call time on this one for now and we have another meeting set up tomorrow- I think we could easily talk for 30 more minutes about this, but there are.

B

Other Paul I guess we thought we talked about this for like 15 to 20 at least minutes yesterday and I think it's time to just like make a decision on this, so that we don't like have another 30 minutes tomorrow and then probably another 30 minutes, Friday and so on. Okay,.

A

That that sounds fine to me, with the knowledge that this is also eventually subject to API approval, so we'll probably reassess the name at that point anyway. At least it's it's possible. My own Road I think would be for Service Catalog instance credential plus.

B

A

Okay with the clip imagine that Doug is okay with his own suggestion. Well,.

D

I've, been fairness might as well was just key. I was trying to move to here based on the board's, the group.

A

Okay, I'm not hearing any minus ones, and it has the form of a true compromise since I think everybody is likely to be equally unhappy about the name since it's a hard name to think of.

B

So service catalog instance credential correct, that's the one school, not plural, not floral, I automatically put the s in there. That's.

D

That's the one problem with the maybe I have yes I'm going to focus on it. Well,.

B

So I will say to move the discussion I. Think to the next point kind of- let me just say this as far as the use cases go, one of our main use cases is what helm and and these things would thus be packaged up in town charts and if it serves catalog instance credential, that's what it would just be hard-coded, as in the helm chart. So I think this is reasonable. From my perspective, that's what I'll leave it as cos from me.

A

Okey giggles uh so done since you made I think at least one or two issues. Would you take the action item to record our consensus yep and after that, can we make sure there is only one issue open for this, because I think we have at least two and I know: there's been one that I heard enclosed ah about rigging and hemming binding, so I don't care which one God as long as there's just one at the end.

D

Whatever yeah, okay for the record, I blame parents, but but yeah okay, I've.

B

Probably submitted at least two issues myself so sorry, sorry, all and.

D

The one we were open to your real condition: it was a group reopen from there. You go, but.

B

Doug be fair. I did push today to put this bed I appreciate.

D

B

D

I promise you that.

A

A

Okay, so next up is a secret key format versus JSON property names. I, don't know what this refers to is this about putting separating individual keys into secret keys or individual parts of the bind response into secret keys? Yes,.

D

I suspect so nail is them on the call, so, okay sure but I think it probably too late. The discussions that we're having yesterday too they're an issue or slack again, which one we're not all jason becames, can be valid in our variable names or kubernetes, config map names or keys, and so the question is: what are we going to do about that? If that's the top level s you.

A

Okay, I I have made an issue to consider a mode for.

A

A

Results in a secret being creative, with a single key that has the entire content of the response for cases like I know that there that at least the IBM contingent is interested in making a V cap services equivalent or implementing V cap services for kubernetes and I. Think that's a valid use case and I. Think if there's a mode where you can just say, hey, dump everything into this secret key that is probably going to make implementing D cap services a lot of you here. um So your country idea.

C

Oh sorry, you go ahead, no go ahead! Okay, so your proposal was, for specifically the credentials a secret, but I think that this discussion was started based off of the secret for secret parameters for the instance spec. So would that apply in this case as well, you'd be able to specify or or what's the thinking there.

A

Is that I want to talk about them as separate things, because they're they're different and I'm very happy to talk about that? One too? But let's constrain this part of the discussion just to putting the vine result into it, and we can talk about parameters separately, Paul.

E

I think this is the latter, not the forward. Yes,.

C

It is okay and sorry I beeped. It.

A

Up everybody, no worry, okay, all right! So! Okay, can we get a more descriptive title on the section then and I will I will make another I will append something to the end of the agenda today. So.

B

This is for a found. Property names, in instance, parameter secrets. Is that correct, Jessica, okay,.

E

D

E

And I ran toward eventually reliable yeah.

F

E

You said level under get back, it's.

D

Just out of curiosity, do we really want some solutions with these super locates? On other things we taking takes and blob and trying to stick it into keys? Also.

E

Does would you care or the ones that come back because.

E

Not buried as object because of how them from stuff works. It makes it much easier to inject into the pot. We.

A

Just decided that we were and then we were talking about secret parameters only.

B

A

So are we, are we talking about secret parameters now or are we talking about buying results and where they go? I.

D

Was just asking for clarification on why we're necessary- and these are separate things it.

B

D

B

Think there are pretty different use cases here. One case is how does your app consume? That would be what's at the bottom of today's agenda. The other is, how does Service Catalog consume the stuff you want to send to it, which would be the bullet we're on now, yeah.

E

B

It probably it seems wise to consider this first and then see what we can take from this and apply, if anything, to what's at the bottom of today's agenda. Does anyone disagree with that? No.

A

That's fine, uh so II I I think that there are probably also two different modes right like if you want the control as someone that is sending parameters to just send to have explicit control over the JSON, then there might be a case where you could reference a single key and take whatever's in that key and send that, as the body I think, there's another case, which is probably closer to what folks that are building forms that will collect parameters would want to send, which would be that you might specify a group of secret keys or a list of secret keys and synthesize a body that includes those as a json dictionary.

A

Does anybody have a case for something in between? I.

B

Would be fine with that either or I apologize.

D

I'm, probably a really stupid question, but.

E

I'm still confused about which case you worship were talking about really.

D

Up there on the on the screen, it's diffusing me talking about taking a secret and using that, as parameters to instance, create an a binding, create yeah.

A

That's right, yeah.

D

Okay, so what's the issue there, because my understanding is that those keys are a subset of what Jason allows. So what's the issue, it.

A

Sounds to me like the issue is that null has a use case where he wants to be able to send key. That is not a valid config map or secret key gotcha. Okay,.

D

Thank you much for clarifying, so I got it so.

A

I would say like in that case that if null was able to say here's, here's, the body that I want you to send it's in this particular secret key or possibly a config mat, see that that would that would enable that use case um and I definitely think that almost everybody else, and please correct me if this is an invalid assumption.

A

But I would imagine that most people that are thinking of using this would want to reference individual secret keys or say take this secret and all the keys in it are parameters and send it make a dictionary that is the keys and their values and send that as the body for the rest.

E

Well actually argue that that further, because we've got to convert something that then Jason schema format, which is a simple key map to a secret format, which is not great secrets. The content is stored when you create, usually as data string or data text or whatever it is right. You're making the client do the conversion to about a secret object.

A

I'm not sure what the entanglement is for the schema so.

E

Automatically generated schema stuff that we're using great the forms that are built off of this key. The output you get from that is the JSON object. Oh really,.

A

Okay, that interesting to know the.

E

Exactly what we would send to the broker effectively.

G

Online perspective and we can do different things. This is a magic. Oh, my hat, by the way we I'm a client like the easiest thing for us, is just that I have a secret and the key be something like parameters in the diet. Just give it a simple. Oh, that's super easy for us anything.

E

G

Us to bypass Padilla to some other point like we can do it the other way and I have a quota type. That does it the other way, but we ran into the specific issue very quickly. Your keys didn't allows for the values that, when the perimeter.

E

And the broker uses.

G

With the parameter object in order kind of start, okay.

A

So does anybody especially want the ability to reference individual secret keys to create the parameters.

D

Probably not if you're going to be creating a secret for the purpose of using it for the service broker. My concern is somebody who had a pre-existing secret and then wants to send it all into a broker, just the basic, the good strength. There's say: well, that's fine, but because you're using a secret for some other purpose, probably you may not be able to get the names at the broker needs. So it's up to you to do some kind of mapping to it into a brand new secret. Is that a social.

F

For them forward slider so.

A

I dug I I, don't disagree with you at all and I think we could totally do both of these I think I think the specific problem that we're trying to solve, which we should keep in mind, is what are we going to do for beta, knowing that we can add additional modes or additional flexibility in a later release? So maybe this is like. We are trying to find that 80% use case and we can do the other 20%, as as we have somebody that can point to a specific use case, that they have clear.

D

I wasn't pushing back on at all. I want to make sure they're ready so that we give to people. Is it okay to go with that scenario? You say sorry: you're gonna have to sing your own mapping. Okay,.

A

So yeah I would say if we decided to go with that. That would be the answer and can also say if, if you need more flexibility in doing this, I would love to have an issue with the specific use case created in catalogue, so that we could consider what the right API is to build for people that offers more flexibility.

B

Sorry- and this is a dumb question- I think maybe I'm not following 100%.

B

So if we give people the ability to send a secret in and all the keys of the secret, get transformed into JSON and gets sent to the broker that, as we said already, that has the problem of not being able to send the entire set of possible json keys.

B

So how all are you saying that that's okay, as the 80% in your mind, so.

A

I would say that, like it sounds to me like the 80% would be that.

A

Well, let me before I tell you what I think the 80% is I think this is a case where there will probably be like a couple different types of things that people want to do and I think that when we talk about the 80%, we should think of this, as like the first of potentially in different siblings, so I I would say the 80% based on what it sounds like to me right now is that we could have a mode field or type field or the parameters in that it would have one valid value at first, which we could default as being you identify a single secret and key to that hold the entire body of the or it holds the entire set of parameters.

A

Double son, okay and then, as we as we find, we get enough feedback from users that we feel like. Okay. Well, we've covered, we've got some interesting feedback. We've got several different examples of things. People want to do, let's figure out how to add one or more additional modes to do those we can do those in a backward, compatible, yeah.

D

A

D

I'm a little nervous about this mode thing only because I'm worried about it. It seems like it's, maybe a lot of extra work for users. I may we can fix it by sending spark defaults, a LAN mode, I'm wondering there's some way we can get around it, and this is just a random idea.

D

It doesn't sound good, that's fine, but could we not infer the mode based upon whether they use a to find property name versus not using my property name like let's say, service kinda, like parameters or something like that where, if that is there, it has to be the only one there and there it's a single blob. We.

A

Could do that, so that's that's actually similar to how the API for volumes is constructed, where there's basically a volume source type, which is a union of n other types and those types are inline so that, like as a user, when you go to write a memo, you just say give me an AWS BBS volume or give me a GCE. Persistent disk volume or an I scuzzy draw I scuzzy volume, and you can only specify one of those per volume definition. But you don't have to have an explicit mode field if.

D

We do something that I can make feel better, but I mean hated once we see it, but I prefer to head down that path. Accurst, okay,.

A

Yeah I'm happy to type up this construction that I have in mind. That would basically be like a union type that we add to a instance or binding for both I guess. Oh.

D

Maybe I wasn't clear: I was actually wondering whether we could just say if you define your secret with a single key of this special name, then our our logic knows what to do with it. It's a single blob. If there's anything else in there, then it treats it as real property names and just copies verbatim, all every someone of them I.

A

Wouldn't I don't have a knee-jerk reaction against that, but I need to think about it. A little bit yeah.

D

It's kind of funky, so we have, we need to think about it, but it would remove the need for remote and another special logic on the binding or whatever. We call that thing. The instance I should say so.

C

As a first cut, where we're all in agreement that we were okay with doing the just giant, JSON blob with a key and then we can implement this sort of logic behind the alternative later.

B

I am ok with that I think so. I may be dumb here. I wrote this action item basically Paul that you're going to write up a proposal for this mode idea. I, don't think that I quite fully understand it. So I hope that I wrote down like a proprietary atoms here. It.

A

Is sufficiently vague and opaque as to the meaning of this great.

B

So that I don't sign you up for something you're, not intending ah ok,.

A

By the way, this is reminding me: I have been uploading. The design meetings to YouTube so know that they're up there. If anybody is in this one and I- have been thinking that we should email the list whenever there's a new upload, so I will begin doing.

A

Ok, it sounds like we're done on that specific thing. Next, one Erin handling deletes the instances that have bindings to them. Yep.

B

This has been an open question for some time now. The basic of it is: what do we do if someone tries to coop CTL delete an instance where there's one or more bindings that references that instance, if you look at the prior to Scott, the first prior discussion link yeah, that's part of issue number 801. What we our.

E

B

You decided on or I shouldn't say, decided on what we originally discussed in the last face-to-face meeting. We had was to somehow pass a force flag to coops ETL such that, if you could say TL an instance, it has bindings on it, it would fail, and if you could CTL force delete it, then it would just automatically cascade delete all the binding. So.

E

Before we go doing something special and one-off here, as you guys looked at the garbage collection stuff.

B

Oh I have I I'm just going over just like the prior discussion, so I'm not I, don't necessarily think that either one of those is the right way to go. But Jessica to your point, maybe do you want to describe how garbage collection might solve this because I don't really have much much better than that. Yeah.

E

So, basically, when you're doing garbage collection on the server, so what we've switched to in our own console for end-users is by default. Well, we do something called foreground deletion, foreground deletion says delete me, but first go delete anything that I own. So in this case you would say foreground delete the instance and then that would go and delete all of the findings. Assuming that the findings had owner references back to their service instance, it's just what we would probably want to do and the source mode is what's called an orphan delete.

E

So when you go to do to control, there's a deaf cascade and equals false option, and that automatically tends to do an orphan garbage collection, delete, and that says, I, don't care that there are things that say that I own them I'm going to delete me immediately. These other things are just going to be left around.

E

You'll have to clean them up on your own there's, actually, a third option which is kind of weird, which is called background, dilution and that says, delete me now and then, in the background, go up and clean up everything else.

E

D

Remedy recommends that me. In the first case you mentioned I, guess it's called the foreground, one that the I guess it's the basis if II delete will not return until it deletes all of the children. It.

E

Returned immediately, it marked the object with a deletion timestamp, which is how you know it's been accepted and it adds a list of finalized errs to the today that part of the object and you'll see there's a foreground, something what is called does.

A

Like garbage collector, remove one of those finalized errs when it fishes doing the other deletes exactly.

E

Yep, the same thing happens with orphan you'll, see an orphan finalizer up here. So.

D

What's the added.

E

Background, how do the.

D

Background work.

E

Differently under the covers.

D

E

Background it immediately deletes the object and then goes off and deletes the other thing. Foreground marks the object as deleted, but does not delete it from storage. The local storage don't get it. It's just marked as being deleted.

A

And we have to use that mode because we rely on finalizar x' to do unbinds and deep revision. Yeah.

B

So so foreground deletion is what we were kind of abstractly calling forced delete back in the day when we were at this face to face thing. Yep.

A

Now let me be that guy again and add a couple wrinkles, which the first one is that aggregated api's do not are not supported for this type of garbage collection in 1:7. Yes,.

E

Yes, they are not supported yet not.

A

Support yet, but not supported right now and the if I remember correctly, the behavior of the of Cloud Foundry is that if you have, uh if you have active findings or do you have findings to an instance, and you try to do provision that instance that it will block you but I, don't think there is any precedent anywhere in the API for a resource that you cannot delete. Sometimes so I think that we have to be able to accept the delete. I, don't think we can block the actual HTTP deletion.

A

um If we wanted to do something like that, we might have to make the semantics such that, like you can delete it. But then you have to go and manually delete the bindings before the before the instance will be deferred, Ypres vision, but I. Don't think that's a great experience, probably one that would be more similar to how things work in kubernetes is one where your bindings would get garbage collected and we decided to leak garbage, collect the bindings, unbind them and then do the deep revision. So.

B

Basically, I wrote a really brief proposal and issue 820. That says there is a new field on the spec that defaults to just failing so accepting the delete and then writing a status in a instance that says can't delete. There are bindings open and if you set that field to I think I called it cascade, something like cascade, binding, delete or something along those lines. Then, essentially, our controller would implement foreground deletion, which is which is what again. That was what I have referred to in the past as force delete.

A

So this is a convenient timing for this discussion, because Ziggy API machinery is meeting tomorrow and I plan to attend that meeting and find out what the status of garbage collection support for aggregated api's is so.

B

I'm not sure why so do we absolutely need garbage collection in order to implement foreground delete in our controller that.

A

That's what that's like foreground deletion relies upon garbage collection, okay,.

B

So if our controller now tell me if this is a stupid idea to have our controller, get the delete event, see the deletion time stamp set on the instance see the finalize errs and traverse to all the bindings that reference, the instance unbind each of them delete each of them and then finally delete the instance effectively implementing the garbage collection itself.

B

A

So if we thought that we were, if garbage collection wasn't a thing, we'd have to go and do that I if I go to API machinery, and anybody else obviously welcome to join me and say: when is it going to happen and they're like oh well, it's funny you ask because the pull request was just merged and the cherry-pick is in progress right now, I might say: okay, let's not do that. I think it kind of depends on what the the remaining time until we can get it from the core is okay.

B

So maybe does anyone disagree with putting an action item on here of getting the status of garbage collection from API machinery tomorrow and then revisiting this next design? Meeting yeah, okay, I'm, not hearing any disagreement, so I'll put that down.

A

Sweet well I think that with two minutes and some change remaining, we probably don't have time to talk about the binding mode thing. I will bump that to the spot on the agenda for tomorrow.

A

All right: well, thanks everybody for joining and see you on the Internet see you same time tomorrow.

A

A

Okay, I'm going to wave goodbye now and stop recording thanks everybody for coming and watching and so forth, see you soon.