Kubernetes API Machinery Special Interest Group, 25 Jan 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes SIG API Machinery - 20230125

Description

[cici37] Clear GA graduation criteria for CRD validation rules(PR)
David and Daniel agree on suggested GA criteria
No other criteria mentioned.
[tallclair] Webhook Match Conditions https://github.com/kubernetes/enhancements/pull/3717
Secondary authz checks
[andrewsy] Mutating Admission with CEL
https://github.com/kubernetes/enhancements/pull/3776
General agreement that there is conceptual alignment on wanting Mutating too in the future.
No rush probably for 1.27, making sure we can address the items discussed in the meeting [TODO: add here] and see more feedback on the Validating use cases.

A

um Hello good morning, good evening, good afternoon, depending where you are uh welcome, to seek API machinery for kubernetes. This is our biblically meeting. Today is January 25th 2023.. We have three great topics to discuss today and we are going to get into it right now and the first one is from CC and I will give you the spotlight.

B

Thank you um hi. um So um today, I want to discuss the antique right here. Ta um great graduation criteria for the crd validation use. So, as people may be aware of the um charity, validation rules um has been beta since 1.25 and we were trying to promote it to GA. If all the graduation criteriors are made, and initially we were trying to Target it for 1.27 and we got an import from.

B

To move it to next release because we were trying to introduce the formatted message in current release, so I would get it aligned to see if there is any other concerns. Besides this um and get the graduation criteria clear for this cab.

C

I have been or I guess, I should say we we have been very pleased using it. We haven't had any significant difficulties.

C

um The old object seems to work well for us. We haven't gotten many complaints about that. uh I'm I see no issue.

B

Thank you so much.

C

um I guess CeCe probably has already pulled in your comments.

D

uh Yeah I uh actually have not looked at this.

C

uh Okay, the scalability was the one that I thought you might have comments on. So uh for us the power is worth the potential degradation. I know you guys have tighter tighter requirements.

D

Yeah I guess my question would only be like how much um how much user feedback have you gotten on this feature.

B

um David is.

D

Very valuable, but uh has anyone else used it yeah.

B

Oh just mentioned, like um some other um companies, are starting elaborating the power of this feature and also like from Google internally, like some team also started to uh migrated to uh try this picture out, um yeah, so I guess so far. We didn't hear a lot of complaints about this and uh uh in terms of the scalability, um even for the beta phrase, we have like the initial kind of data collected for the scalability as well.

B

I have a interpretation uh writing all the data, um some some of our data and I guess it's been reviewed by um Joanna Jordan, primarily um I can share with others who are interested, but yeah and I have already listed it as the ga um graduation criteria here as well, so I'm not sure if there there is other concerns. Besides those.

D

uh No, if people are using it and you haven't, heard complaints, that's a pretty good sign. Thank.

B

You yeah I, guess the major concern I'll feedback um I collected from Jordan earlier is like um he want the format message to be in beta for at least the wine cycle before we motivated to Jay so I guess um we all started to promote, uh try to promote this feature in 2G in 1.28, if you know, but nobody have like a major objection.

B

Yeah. Thank you. So much.

A

um Cc you've been running um for some time already. The triage meetings um for this thing, we didn't saw any issue from anybody. Also, there right.

B

No, we don't. Okay.

A

And um hypothetical question imagine you're running a large Fleet of kubernetes clusters like you work for a company like Google, uh all right or other cloud provider. um Is there a way for us to see uh how many people is using um cell for crd validation versus the other mechanisms.

B

Oh sure um they actually have like a couple metrics um for this so like, if you yeah I guess, hopefully the metrics will help to collect those kind of things that.

A

Was my question, thank you.

A

Okay, so it looks like there is no more comments. uh So um what are the CC? Did you get what you wanted and do we need to document here? The action items for the next steps, I.

B

Think that I guess all the information I need. Thank you so much for the input. Okay, good, very.

A

Good, let's go to the next W team. Are you there.

E

A

Thank you for coming. I will be with you.

E

um So uh yeah I'm still hoping to get this uh kept in for uh 127 Alpha um I just wanted to put it on the agenda to kind of one give anyone an opportunity to. um We have some feedback, uh but also specifically I. Don't know, if is David on the call.

E

um Yes, he had a comment about uh secondary authorization on this that I wanted to discuss in a bit more detail. um We followed up a bit on slack and I. Think where I stand on. This is, if it sort of depends on how we Implement secondary authorization for uh General cell admission.

E

If it's done as something like a function call in the cell library that we get for free here, then I definitely think it makes sense if it requires more kind of auxiliary configuration outside of cell, then I'm not sure I want to commit to it at this point.

E

So what I'd like to propose is basically leaving it out of the cap for now and seeing what shape it ends up taking for General cell admission, and then we can kind of add it back later, but I don't feel like that should be a blocker for web hook. Mac match conditions.

C

So my concern here is that the the use of a subject to say this subject is this user is not required to go through a particular admission check, looks a lot like a permissions binding to me right in other places. In our system we model that actually, as permissions bindings, uh the GC admission. Plugin is one concrete case.

C

Where we say: do you have permission to delete a particular resource and if you do have permission to delete all resources, we don't have to run this check at all, and this looks like a very similar thing that is binding up permission inside of a cluster scoped configuration for an admission web hook and if we have this particular binding mechanism, but we do not have an alternative binding mechanism that lets someone reuse the permissions Bindings that our system already has. Then we can drive people towards.

C

I'll say a pattern that I, don't think is going to scale well.

C

And so I would like to see the two, the two coupled together, I'm, okay,.

A

B

C

But I would also then defer the ability to create a user binding at this level right because if you look at like user bindings today, you can bind users at the level of a namespace, for instance, and this could be done here. But as you start trying to enumerate it, it would get very clumsy in a single object.

E

Yeah I definitely see where you're coming from um part of my thinking here is for like a more complex policy um evaluation like finer grain control based on on bindings of users.

E

That feels like something that should just go in the web hook itself, where we're not trying to replicate the full admission and business logic here, um but rather just uh kind of opt out when the web hook needs to be called both for performance reasons and like reliability reasons.

E

um So, if you're using this as a full way to like opt privileged users out of a policy I'm, not sure that's quite The Right Use case for it, um but then again, I could see how someone might just use it. That way. Anyway,.

C

I'll say that that's how I read the example you provided right, I read the example you provided as nudes should not be subject to this particular policy. There's no reason to check them. They have sufficient privileges to take the action.

C

um I think we do a similar thing with garbage collection admission saying: do you have so many permissions that I don't even need to try to evaluate all of your uh I? Don't need to evaluate the rest of the submission plug-in because you're just going to come back true for everything and- and it seems very similar to me- but I- want to have I'd like to have the pattern based I'd like to have people choose which pattern they mean right. I can see valid uses for like nodes.

C

Just don't need to have this check run on them. uh I think I see more uses for. If you have this much permission, we don't need to make this check.

B

C

I, don't what I worry about is. If we only have the one mechanism, then it will be tempting for users to start codifying policies that are like things like inside this namespace. This user doesn't need this check and they may instead have wanted to model that, as if you have these permissions in a particular namespace, any particular namespace doesn't need to run and yeah.

A

E

C

I'm hoping that we do get this for free with the the shared library that you did specifically call out. So thank you for that uh I'm hoping we get that for free with a specific library, but I really don't want to have user-based skips without having the option to do a permission. Space, skill.

A

C

To avoid blocking Alpha, are you okay, coupling those together and saying we will do both or neither and.

C

And we expect to be able to do both I think we expect to be able to do both right. Like is Joe here, um I.

D

Think Joe is sick. Today, uh yeah do we do any user base skips anywhere in the in the system at all.

E

um There's hard-coded system Masters opt out.

C

That's a group well yeah, sorry, uh user, I,.

A

Meant user and group.

E

C

Use the screen.

E

um Yeah groups is the example given in this cap as well: um okay, how about uh exempt uh exempt bindings in APF?

E

How do those work.

D

uh It's true that those are about users or groups and not about uh permissions, but.

A

D

The thing they're doing is not very much like a permissions check. um I guess uh I'll. Think about that. One though.

C

Yeah, that's actually useful. I had thought about that one.

C

uh It does uniformly apply across the rest of the filters, as in there's no other way to set it up as a binding is there there might be.

D

C

Mean I think I might claim that as a mistake, I wish I had caught previously, as as opposed to intentional design choice, yeah yeah.

D

uh I mean: how do you get users into groups? If you can get a user into a group, then with the permissions and uh but I, don't think you can.

C

Varies by System, uh for instance: openshift has a resource you can set uh for the IEP. They provide.

D

Yeah, but with our back I, don't think you can do that.

E

um I do think there are cell use cases where we won't want to enable secondary off checks, um not sure it makes sense in the crd validation case um and there's also uh it's more speculative, but there's discussion of using a similar kind of cell-based pre-filter for multiple authorization web hooks.

E

um That's pretty clear case where you would not want that enabled.

C

I do agree. I think that the static validation for crds I- guess it's for CRS static validation for CRS has a significantly more limited set of information coming to it.

A

C

If you look at the other resources, even talked about for um providing cell uh cell policy I think one of them was actually trying to expose a name space. I, don't remember where we landed on that we'll have to look uh but that, for instance, it would not be present in uh CR validation,.

E

um I think I'm I'm sold on including this uh I'd still push back on blocking the alpha on this, um especially since, for it wasn't blocking the alpha for um General cell admission,.

C

Could could we couple them together so so my concern really is I. Don't I don't want to have a way to write a binding into this policy that is better represented using a binding system we already have so.

B

C

I, don't want to block Alpha on it either, but I, but I don't want to be able to specify a user without also being able to specify a secondary Apple checks. Then we know the right thing, so you could have an alpha with. Everything else.

C

E

um Yeah I don't think that significantly harms the ability to get feedback and prove out the alpha um if it's a blocking condition to Beta I'm, not sure how much value there is to filtering that user out of user info out of the request.

D

I guess my question is: if you're gonna do it with a binding, is there a reason? Is there still a reason to have a user in there.

E

I can imagine something where, like you, want to label objects created by a user or something like that, um and you want to assert assert that the label matches the user I don't know, that's a contrived example, but more complicated checks where, uh but maybe that doesn't apply to the match conditions as well. Yeah.

D

I think we've shied away from uh story like like in fact I think the position is it's kind of an anti-pattern to include user information in an object um like the classic example. Is somebody wants a object that only they can delete, so they want to put their username in the object to do a check, but then they leave the company, and now nobody can can delete the object um so.

C

uh Maybe I can think of one what what if someone had a system where their SRE team had a special group? This isn't a thing. I actually know deeply, but, like one team has a group, but they give cluster admin now if they gave cluster admin controls, they would just delete, never mind uh that wouldn't work.

E

um I could imagine something kind of like the nodes group case, where you just want a kind of hard-coded.

A

E

A hard-coded expression in there, um but you don't you- don't want to generally have a permission that can be bound to other users. You just want to say like this, never applies to nodes, or this never applies to the service accounts, um or this never applies to authenticated users or something along those lines, um and it's just kind of a simplification to not have to create those additional objects.

E

Actually, maybe the bootstrapping case that uh Tim Bannister brought up would be another one where the ability to opt out some uh bot user, that's instantiating objects would be useful.

E

To kind of like decouple the um dependency on the roll bindings being created before the web, Hook is defined.

E

For example, if you had a web hook, that was.

E

Operating on roles and role, bindings.

D

That might be a convincing argument if yeah I'm not sure, if the like conditions to make it necessary will hold in practice anywhere, though,.

C

But it is true that you would have a hard time doing a permissions check without being able to create the binding.

D

Yeah, so it's like you'd have to have a web hook, that's going to operate on role, bindings and an actor that is excluded and.

D

The role binding can't be created before the web hook. I, don't know why the real binding can't be created before the web hook.

E

If you have, you know just a directory of manifests that some add-on manager is applying and they get created in arbitrary ordering and the if the web hook gets created. First, it prevents the service definition the hacking that web Hook and the role bindings opting out of the web Hook from being created.

D

um Is that a requirement that, or is that a scenario that we try to make work in other places that you can create things in an arbitrary order?

D

I mean it's nice to have, but like in controllers, we usually do that by retry, loops and stuff yeah.

E

D

E

This case, a retry Loop, doesn't work yeah.

D

You're saying once you're saying, create it and the wrong creating it in the wrong order. Wedges the system.

D

E

It's a place where namespace exemptions is probably the better solution, but.

D

Yeah uh I'd have to think about that more. It still seems.

D

Okay, yeah I'd have to think about that one more.

E

um Okay, I'm, uh okay, with adding a kind of call explicit call out to the secondary authorization um and as long as it's not a requirement for Alpha, um we can probably revisit the weather to filter out subjects from the admission review, uh request.

E

um I. Think one argument for not doing that is uh it makes the um API a bit more complex. To say, like you know, the object that you have access to is the admission review, but we filter out some subset of the fields as opposed to just you have access to the full admission review, object.

C

Yeah I'm hopeful that doesn't come up in practice like I, really do look and say if this is using the same Library as as our cell validating commission policy.

C

um If it doesn't come for free I'm going to have questions about just how much reuse there is.

E

Think over time, yeah I agree with that. um I was talking about the uh my understanding was we were discussing whether uh user info should be omitted from the admission review that gets passed to the expression so to force the user to use uh secondary authorization checks- oh I, see, but also, if that secondary.

C

E

C

I was about to say, I'm, not sure the secondary authorization check is likely to have a what is the user? What are the groups? Yeah and I would like to be able to put in this user in these groups. So at a practical level uh that becomes a problem, so yeah I do think that it's worth discussing in docs that that, if you find yourself using this as a binding, especially if it's something that can be bound at a namespace level, you really want to use an actual check and not hard code binding.

D

Yeah I mean people can do this wrong today with web books, because we send the user to them. Yeah.

A

D

F

E

Foreign okay, I'll update the cap I think we can move on.

C

um You had one section that was unresolved, I, don't remember what it was, but I remember there was one there did I get resolved.

E

uh There was one that was marked as non-blocking for the beta.

E

uh Or sorry non-blocking for Alpha was on uh resource constraints.

E

Okay, so cell gives us the ability to uh bound the estimated run time of an expression, um I think exactly what we want to constrain, that to is TBD.

E

C

uh I think that after this I have no other reservations about this cap, have you reviewed it Daniel? Do you want to do you want to see if Joe has a look at Joe's had a look at it.

D

Yeah this was talked about at the last meeting that I didn't make it to is that right, yeah, yeah, yeah I haven't had a chance to review it. um If both you and Joe are fine with it, uh then I don't need to I review it, but I'll probably try and look at it.

E

Sounds good thanks.

A

Okay, very good. Thank you! Team, David, Daniel um I. Think we've got the third topic today from Andrew's side. Are you there Andrew.

F

Yes, hi hi here with yet another topic on Cell, hopefully uh aren't sick of it. Yet it's the end of the year yeah, so I've been um prototyping. uh Mutating admission would sell with some early feedback from uh Joe uh Tim and Jordan I. Initially wasn't planning to propose a kept for 127.

F

um Giving validating is, is still you know, very, very early stages, but I was able to get a decent prototype working by having cell Expressions that can resolve to Json patch objects, which we can then apply against objects uh via built-in admission plugin, um which ends up being kind of similar to what we do with mutating web books since I think we end up using um Json patch under the hood there.

F

So basically, the the kept proposes um introducing a new API called uh mutating imagery policy that uses the same uh binding pattern um with support for parameter objects much like validating, and it allows Forest cell Expressions to use a custom, uh Json patch type, which we can actually statically type check during validation and whatnot um yeah.

F

The cap has some like examples of what I think are common use cases um uh for mutation, um so yeah like uh forcing DNS policy or injecting like a HTTP proxy environment, variable to containers um things like that, um so yeah mainly I'm, trying to figure out what the appetite is for something like this. In the sake and what kind of concerns you would want to see address before um we're happy with trying to land in Alpha.

D

um I've got two thoughts. uh uh Actually do you want to go first, David.

C

uh I'm still Gathering I'm still Gathering and ordering my thoughts I'll. Let you.

D

Go okay, I've got two thoughts. uh One is the issue with doing mutating is that we haven't gotten any experience on whether we've done things right uh for validating um right. Like did we get all the admission, all the configuration details and like what it applies to and like the because it's pretty validating one is pretty complicated, with like three objects involved to hook up, parameters to um uh objects and rules um and uh I I'd feel a lot more confident with mutating uh version.

D

If we knew if we had some experience with the validating version, and we knew that people like understood and could use that correctly uh and we're happy with it.

D

um My other the thought on this, and this isn't the details that uh is the Json patch, is pretty surprising because, like it's got a bunch of paths in there like I, don't how do you type check the paths inside a nested inside a uh Json patch object, so that that's pretty surprising, um although I believe that it was easy to do.

F

So I should clarify so the the type checking is not against the path value. It's more against. um Did you specify all the required fields for the patch like.

A

The operation, the.

F

Path, but the actual um validation against the actual mutation would be runtime like if you specify a pod, the spec field that doesn't exist. That would be a runtime error.

D

Yeah I think I'd feel a lot more comfortable if it was a uh like the the whole. The whole theme around cell is that we type check things early and um uh so it's surprising to see a uh Json. It's like a like a field path that isn't typedract looks like David has a hand up.

C

Yeah, so uh my first concern is actually the same as your first concern. uh I want to have confidence. We got the validating admission policy. Correct uh I did find to be one of the more complicated apis I thought to use when I was reading it for review.

C

So I don't want to put a super high threshold on this before this will go to Alpha, but I do think. I want to see I'd like to have a chance to get some feedback on the validating admission policy beta before I tried this one in Alpha in case we made some significant mistake with the bindings the parameters.

C

I wanna I wanna get more certainly at least with the second Alpha, like it's not feature complete. Even yet the validating celebration and I think we at least have we have to have that much and we have to have feedback on.

C

um Maybe that doesn't require beta feedback, but at least a complete half of feedback. The other thing is Json patch surprised me in part, because I thought their I thought there were some things that Json patch had a hard time expressing.

D

um There so so there are with our objects. The thing is, uh the problems are mainly with uh concurrency, so you can make a Json patch say anything, but you have to do things like reference specific indexes in lists and that doesn't work very well when other people could be mutating it at the same time. But in this case all the mutations are done in serial. So there's not an issue with that, and that's also how our mutating web hooks return things. This Json patch.

C

um Yeah, so our mutating web hooks were built before we had server side apply where it is today. uh One thing that I wonder is whether it would actually make more sense to express the I want to set this in the form of serialize, either yaml or Json, where you say if I were doing a server.apply. This is the thing that I would want to apply there. So.

A

C

Of having replace paths back DNS config, namespace servers, it would actually have spec colon come down. Indent DNS config come down you're dead and the namespace servers I wonder if that.

D

C

A

D

Just I expected to see something like constructing an object of the type uh that is going through the pipeline and then having that object merged with the uh pre-existing object somehow and that could be server-side apply. uh It could be that logic or it could be um something else, but.

F

Yeah, there's a there's an unresolved um section somewhere in the dock, and one of the things that we would consider in the future is supporting other custom types. So one of them being like an apply configuration which um contains like the desired behavior for service side apply, and then we could also, in theory, support um strategic, merge, patch and Json merge patch as well.

C

F

Think what I'm.

C

Saying is I would like to see a comparison of alternatives where one alternative is a Json patch and the other alternative.

C

uh The others that you mentioned sound good, but the one that occurred to me was uh I guess it would be apply, configuration from this list to try to figure out what makes sense, what makes the most sense to try it. First yeah.

D

I I would say I'm not in favor of having runtime like multiple things supported at runtime I think we should figure out what the right thing is and build only that so Alternatives in the design uh until we decide, seems good uh but um I.

D

Think in this in this thing that there's not really a reason to do strategic, merge, patch um and I yeah I I, don't like Json merge patch, because the you have to get the field paths correct, um apply configuration you could do, but there's no reason not to construct a um so. Maybe there is a reason not to just construct an object and that's if you want to delete a field, um the syntax isn't clear for every like every field type, so maybe apply configuration model. Data model would be correct.

D

C

Guess that would also surprise.

D

Me honestly, yeah.

C

If we consider that to be rare, like it seems like deleting a field is less likely to be used than injecting a field, we could choose one format for injecting a field and one for deleting.

D

Yeah yeah Antoine has a good point in chat, which is which is uh web. Hooks are currently like a mysterious uh exception to uh ownership. Semantics um I guess is the problem with cell that you can't do uh like I guess what I kind of expected is just like you know, object, dot, blah blah blah. You know that you know index 0 or index of cell expression uh equals like value that I want, including like clearing it. um Is there a reason why that's not easy, with cell.

F

uh So yeah, like the where I was going with the initial prototype, was basically that, like you, you break down the specify, the feel that you want with an expression, and then you have a a value that the expression resolves to, um but that got tricky because you have to like you, don't know how that field can expand like it could be a list or an object with many fields, or it could just be like an intro string like it was hard to um do it correctly, uh whereas with Json patch, it's kind of like you.

F

Can it's much more robust and it kind of.

D

But we know the schema right like uh if you, if you select a field which, uh if, if you select a field which expands to a list, we can stop you at compile time. Can't we.

F

Yeah, you could, um but you wouldn't know if, like you wouldn't know, if, if you can actually apply the actual uh value right until runtime, which is the same thing with Json, why? Why wouldn't you, though,.

D

Like sell is, is typed, so if you have ones like, if you have one expression that selects a destination and another expression that selects the value that you want.

F

Well, to go there, for example, like if you're setting a DNS policy in a pod spec, that's invalid, like that. Would then fail like that, like you could you would you would allow that object, um but then it would just feel validation for pods. But then, if you had like a crd right which had no validation for that uh field, but um the like the like, you would allow the object. But then you can't actually check the values of the object until runtime.

F

You know what I mean I.

D

Mean but we, the the uh validation, runs shortly after uh the mutating part of the admissions stack. So um uh all I'm expecting.

F

Yeah, so that would be a case where you would like fall back to validation for the.

D

Actual all I'm expecting of this uh of this uh cell is that you, you uh obey the sin. The the type syntax right uh I don't also require that it's that it's semantically passes.

F

The validation.

D

F

So you can statically type check if an expression resolves to like a Json object or a Json list or whatever, but you can't type check anything past that.

D

um So, but that, but that isn't type checking right like making sure that you uh have like IP addresses in the right range. That's not a.

E

D

Check, that's so yeah like I'm, not I'm, not expecting this to force people to only express valid objects in the sense that it passes. The validation I am expecting it to force people to express valid objects in the sense that it conforms to the schema. Yes, yeah and Json patch doesn't force you to conform to the schema.

D

Yep, that's true, um so I guess that yeah, if just to make totally clear what I'm, what I'm trying to say yeah makes sense.

D

um uh Okay, yeah I I mean I, guess.

D

Maybe if the cap was structured, like um you know, for configuration and whatever we'll do exactly what what uh validating uh admission policy did and it focused on the um like just the like the mutate, the part of the mutating parts of it.

D

um That would keep it short, the like I'm, not sure if we can take code entry uh well I. So so maybe maybe if maybe we could take code that actually did the mutating part of it without taking any of the like API and configuration stuff. That way, if we change our mind on the validating, we don't have a bunch of extra work. To do um is that seem like a option David like if we get a library which which uh demonstrates the uh mutation um I, don't know if I'd say no to that.

C

I Rock I, don't think I would say no, but in terms of just in terms of realistic timing, I.

D

Yeah I mean I would prefer to make faster progress on on validating, okay.

C

uh That's that's where I'm biased as well. I also think that trying to figure out what what how we want to express the mutation itself is is important and I'll confess this kept was probably opened recently. I hope so otherwise I'm really embarrassed uh yeah. It was. It was open recently, so I hadn't seen it uh I haven't looked so when we did validating there or when we did we're initially choosing cell.

C

There was a comparison to what currently existed in the wild and I haven't had a chance to read this apologies if it's already there, but have you compared this against how uh how existing mutation is described right as I recall, Opa allows mutation as a for instance, uh and comparing this to that seems useful.

E

C

Against mutating web hooks, I could see where you came to Json patch, because I think that's what we did there, uh but I think with the evolved world of server-side apply and using that schema to make good decisions about how to actually do replacement and merging. We have another option I'd like to see considered before choosing One Direction or the other.

C

B

That sound, reasonable.

F

Yeah I think that sounds good, um so I guess I'm trying to gauge um for 127.

F

If we want to accept like a provisional cap that says, um explore these Alternatives and also um even if we put like uh waiting for validating admission, to go to Beta as an alpha criteria like that would make sense too.

F

um Or if we want to just like leave the cap open and revisit once we have answers to some of those.

D

um Yeah I think, like David, is saying a list of options or Alternatives in the cap for how to actually do the mutating part, um yeah I think that's until we get experience on the configuration I think uh the part of the piece of value is like how to actually do the mutation uh and I think more options would be or like a compare.

D

That would be. That would be useful um but at the same time, uh priority waiting I'd rather get more progress on validating cells so like if this, if this uh is funging against uh validating cell I'd, prefer to get more progress there. If it's not, then I think it'd be good to get a list of comparisons and I.

D

Don't think it is super important to get it to get this kept merged in this time frame uh right if we're especially, if we're waiting for uh further progress and validating before we actually start implementing this so um I, don't think you I, don't think we should need to rush anything for the uh for the deadline.

D

C

Say that makes sense here, I believe is, is conceptual agreement that we agree. Mutating admission policy is a direction we do want to go. I want to go here, uh I.

F

Think yeah yeah he.

C

Wants to go here.

F

Yeah, that's basically, okay. What I'm looking for is like I'm happy to do. Prototyping and whatnot I just need to know like do. We actually want mutating down the road.

D

um Yeah yeah, no, we definitely want uh yeah. We definitely want mutating because we want to expand the number of web hooks that people can get rid of.

C

Yeah, so uh I am definitely in favor of mutating I. Have my biggest question is about how we figure out what to mutate uh and then uh I will have a look I think there's a couple use cases that we have. That are unusual, where we have one area of an object, point to another area of the object and say mutate here. uh Yes, so um I want to want a chance to add that in there um I don't want to discourage you but I'm, not confident that it'll be ready for implementation. When 127 starts.

D

Yeah another another thing that cap should uh highlight is: uh are we going to permit these cell Expressions to make any sort of uh like network access, call look up other objects, things like that um I, don't even know if I have an opinion on that, but the cap definitely needs to definitely needs to tell people what they can expect.

D

Basically, we need to decide if you're doing some sort of external something.

D

Does that lock you into making a web hook, or are you eventually going to be able to do uh do that with a cell expression, um yeah.

F

I I, uh yeah I would I would think anything requiring network access to anything. External would defer the web hooks, but I do plan on supporting, like parameter objects like validating, and you can use the value of a parameter object to set mutate some field in the current object, or something like that.

D

Yeah so yeah- maybe maybe that's good enough yeah. That would be an interesting use of yeah. That'd, be a good thing to write down and uh talk about uh like I I could I could even see like um since API server has nearly everything cached anyway. uh Let it do a cheap lookup of something.

C

um No hang on I think I have a recording of you saying not doing that for validating.

C

Phase two list so.

D

I I uh I I, I, I, I I'm, saying it should be explained. Why or why not in the in the cap, um I'm not promising I agree with I agree with that.

C

Okay, I, don't think I have strong opinions. uh Namespace metadata is something that uh sell the validating admissions supposed to pick up. I think this release see.

D

If you can get everything into a parameter object and that's not inconvenient, then uh there's not much else to do right. Yeah.

F

Yeah agreed and that'll depend on what the whole binding pattern ends up, looking like for beta, so okay for that to kind of mature all.

D

F

D

Thank you. Should we give everybody 10 minutes back.

A

Yep looks like record all the topics. Thank you for the good discussions. um I will upload this recording later today, posted in the channel and we'll see you hopefully in two weeks, stay safe.

A

All right, see, ya, see you next time, bye.