VMware Pinniped Community Meeting, 4 Feb 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Pinniped Community Meeting - February 4, 2021

Description

Pinniped Community Meeting - February 4, 2021

This meeting dove deep into api design and the upcoming release of v0.5.0, featuring multiple pinnipeds.

Notes and meeting information can be found here: https://hackmd.io/rd_kVJhjQfOvfAWzK8A3tQ?view

A

Cool all right.

A

All right welcome to the first community meeting of february 2021 um for those that are joining outside the community even right now we don't have anybody, but I just want to make the statement that abide by our code of conduct read and abide by it while you are in this meeting and that is listed on the notes.

A

So if you need to find the code of conduct, it is in the agenda notes at the top, uh I will just kind of go through those who have input anything and then, if you have anything uh to add at the end after the status updates are given um feel free to do that chime in, but I will go for the first one margo.

A

Let me share my screen.

A

All right so margo do you want to talk about what you put in here.

B

Yeah, so I've been working on the impersonation proxy track, um trying to uh make it uh possible for clusters that are cloud hosted to be able to uh use pinniped.

B

And so I think matt's also probably gonna talk about some of the other stuff, but one one of those pieces was um detecting cloud-hosted environments so like. If we can tell that you're running on uh gke or uh eks, uh then we can uh use that information to spin up an impersonation proxy um for you and if you're running on kind, then uh we don't need to.

C

Cool, I can go next, um a few items here.

C

One kind of minor thing I did this week was hooked up um codecov.io to our repo, so it tracks our coverage data and leaves these comments telling on each pull request telling you whether you made coverage better or worse, I can see how this could be annoying, so I wanted.

D

C

Just take a moment to get like a gut check. Do folks feel like this is useful or noisy or like you're, not sure yet.

E

So I I will admit uh I have not worked with many projects that have these tools, but the ones I have worked with that have them. I completely just tune them out like they're like it's. Just is this noise because it's not usually actionable for me like it, doesn't encourage me to write more tests.

C

So I think the the use case I have for it is not so much on my own pr's. It's reviewing other people's prs and I can go look at your tests and I can try and figure out what you've actually covered in tests. But it's nice to just look at the bot and say, like oh yeah,.

F

C

Probably added the test that I don't know.

E

Yeah and to be fair, I don't mind it. I I I I'm very used to like 18 bots, showing up and yelling at you every time you open the pr but like one more, is not like a problem.

C

Just so everybody knows there are a bunch of settings we can still tune on that like we can actually leave the bot enabled but turn off the comment posting, so it tracks the coverage in the background you can go to that website and look at it, but it doesn't. Actually.

C

Anyway, we have options um next status item. I worked on a design for some of the api changes related to the impersonation proxy feature um mark, and I worked together on some of that earlier in the week and I think we.

D

C

I I filed a bunch of github issues, centered around one particular design, and then I think we decided that's not. That may not be the right design so later in the agenda. Here. I've got like a a full-on discussion about a second design that I I like better.

C

um This week I wrote a blog post. um I think a lot of you already took a look at it, but give it a read, we'll plan to post this like today. I think and then cut 0.50 and uh I guess yeah we're we're cutting 0.50 today. So that's good, except you.

A

Want to go a little bit more in depth to yeah.

C

Okay, so so this blog post, I think, is not quite it doesn't quite fit the pattern that we might have in other releases, where we we write a blog post, announcing the release and talking about all the cool new features that we shipped in the release, because the feature that we're shipping in this release is pretty small, and it's only interesting to some niche cases like most pen. Pet users won't care about this feature at all.

C

So what I thought was interesting to blog about was not the feature itself but kind of how we built it in the api machinery um and that it might be interesting to other developers who write kubernetes controller apps. um So that's what I focused on and uh we'll see. I expect.

D

C

This may get some positive attention, but also may get some negative attention we'll see. I think.

D

A

C

You know I wrote, I wrote it, you know expecting that so.

D

uh Why the expectation of negative attention is it.

C

Just because it's a little it's a little hacky I mean we. This is the best it's the best thing we can do right now, um but it's a little hacky.

D

Sounds familiar yeah yeah.

E

I was uh on the on the zero five zero release, like I I saw like yesterday, ryan and margo had opened their pr, so I was trying to figure out. Do we feel current maine.

C

Yeah, do we want to have some live discussion about that? I I read the comments and I still don't know if I have an opinion one or the other. Maybe we could add a discussion topic for that.

C

uh I can do that uh when I'm done here- um and the last thing I wanted to mention is like welcome back pablo we've been having discussions about road map stuff and I guess that would be a good point to hand over to pablo.

D

Yep um thanks I'm glad to be back like uh it's day- three, I guess um so mostly catch up with the team and trying to get a sense of what's going on with like in-flight work, as well as how the team has been thinking about upcoming initiatives. I got some of that information. I think we have some. I scheduled some meetings with the team over the next.

D

I guess two weeks that will help us make some decisions that will inform, um when I say a short-term roadmap, I'm thinking like roughly six iterations and then those will also be foundational for a longer term roadmap. Also, as I work a little bit more closely with dan to understand some of the specific outcomes, we believe that we're trying to drive specifically with pinniped as it exists, kind of in a broader umbrella of stuff. um I know that's rather ambiguous.

D

I hope that next week I can speak a little bit more clearly on what that actually means, um but yeah happy to be back.

C

Oh, we skipped over uh ryan and andrew and mo. If you have anything you want to add yeah.

A

I I intentionally skipped over them. Next.

C

Time added to the duck.

A

um But andrew, do you have anything that you wanna.

G

uh No, it just mostly was helping with the 050 release this week.

A

Cool and mo ryan or ryan.

F

uh I was working with andrea and mo and building the features that we were just talking about.

A

E

I I've actually been sort of busy on some of the downstream efforts for upcoming.

A

Yeah I've been seeing that that sound seems like a lot of fun.

A

No comments um all right, discussion topics, review api design proposal.

C

Yeah, okay, so um I posted this earlier in the week, so maybe folks had a chance to read it. This is uh this is a proposal about the api changes that go along with the new impersonation proxy feature. I don't think it necessarily changes that much about actually how the the code works to implement the impersonation proxy. It's mostly about how do you configure and describe the status of of the impersonation proxy?

C

um So this is a departure from what we have filed as sort of stories right now, in github um goals were to make the concierge work, with no configuration in as many cases as possible. I think that's like been our goal. Since we started was like most cases should work with no config, you just install penpad and it works correctly.

C

um I also wanted to leave room in the leave room in the api so that we can eventually configure everything that might ever need to be configured about how it behaves even if right now, we don't have all those knobs yet um and then I also really wanted to get rid of the credential issue or resource, and I don't know if I justified very well why I want to get rid of it. But it's mostly because it's I don't like having a singleton api like it's, it's kind of a weird api pattern.

C

I think it's not obvious why most people would care about that resource anyway, because it's actually none of our clies, for example, use it anymore at all, um rcli used to read it if it doesn't anymore.

C

um I just thought this.

D

Would be a good chance.

C

If we're reorganizing things a little bit, we can also get rid of that um non-goals. I don't necessarily intend to add all the configuration knobs from like the version that we shipped next. I think we just need to leave space in the api so that we can add them later.

C

So the changes I broke down here, the first one you can scroll down a little the first one here is basically the change that marco talked about, which is start adding some auto detection of when the impersonation proxy is needed, and we can make this fancier later on, but, like the simplest place to start is just. Are we running on one of the three major hosted cloud provider, cluster types and they're? All marker? I hope I'm not.

C

I hope I'm not wrong, but they're all relatively easy to detect because they all use like labels on on the node object, since you can just uh make a little api call and tell if you're on one of those, so in the next version of pinniped after the one we shipped today, we would uh detect that we were in one of those environments. If we are in one of those environments, um generate and persist, a ca which we have code to do.

C

That's sort of just a few lines of new code to turn that on create a service of type load balancer. And then, when it has an external name assigned which might take a minute.

C

We load that external name in and then issue a serving certificate for the external name and basically use that to serve the impersonation proxy. So all of this is basically just sort of like one one little controller that takes a bunch of code we've already written uses it to do this new thing.

C

um I think uh the uh if you could go back up for just a second, the there's, a bunch of cloud provider, specific annotations that could be useful in certain scenarios, but I don't think we need any of them to make the feature work in this version. It just would just be a just a load, balancer service, um okay and then the next thing.

C

Second change um is: take the status information that currently, we kind of keep in the credential issuer api and start putting it in these in a new status field of the authenticator objects. Instead, so we already have like some common types between the jot authenticator and the token web hook authenticator.

C

This would just be like another common type in the status that represents the the way that the concierge is serving that authenticator. Currently, so it's a status of how to use that authenticator in the cluster, which is kind of what the credential issuer is today.

C

um The uh the slightly awkward thing about this is that it is basically the same information on each authenticator object. So if you had a hundred authenticator objects, that would be pretty wasteful, but in most scenarios you have like one and even in more complex scenarios, you probably have like two or three or five, so it doesn't that doesn't feel that bad to me. um I have an example of what I think the api should look like here.

E

If I, if I could make a comment, yeah yeah, please copy the same information. A thousand times is a kubernetes pattern. uh Note the root ca publisher. There is no global config map that has this singleton object is copied via controller into a known location in every single namespace, so totally totally fine. This is well within exactly what cube would tell you to do.

C

Yeah so in this object the the spec and the metadata and everything- that's that's! That's what our api looks like today. Already the new part in the status field. Is this concierge strategies field um which tells you for each type of of strategy that we support, and that's that's the name that we use right now, I'm open to changing that name. I think strategy is a little bit generic word.

C

um You know we have basically the existing strategy that the concierge uses today, which is the token credential, request api, and we can report on whether that's successful or not, and we can report on if it's successful, it's api, endpoint and the c8 you use to talk to it and that's what you need to then build a coop config that targets that strategy and then the new section, then is the impersonation proxy, which is turns out to be almost all the same fields.

C

That's kind of an accident, though, like the fact that in both cases, what you need is a url and a ca bundle, it's kind of an accident, they're, actually kind of semantically different fields.

C

But again, that's that's the information that you need to connect to the impersonation proxy in a coup config and then for backwards compatibility. We can take the status information and we can. We can continue to maintain the credential issuer for another release or two just in case uh anybody's, depending on it. We can mark it deprecated uh in o60.

C

And then, finally, this is basically the space that I want to add the space that I want to reserve for future configuration is then in the config map configuration of the of the concierge. So I think, almost all of the things that you would want to configure about how the concierge works are things that you would know when you installed it. So I like that, for example, on the supervisor I like that you can come back and dynamically reconfigure it with a new idp. I think that's really powerful and useful.

C

I don't think it's necessarily useful to dynamically reconfigure, the concierge to operate in some different mode, because it's it's a component that you would probably deploy um like as a cluster add-on, and you would kind of know when you installed it kind of the parameters that you wanted to use. So the the initial uh in in 060 this section would just be empty.

C

We wouldn't actually have any new config some point after o60, we would add some config and some things we could configure are this mode, which would be either forcing the impersonation proxy to be on or forcing it to be off or the default could be the o60 behavior, which is detect cloud providers. Basically, um I think it detects cloud providers or something- maybe maybe I think, maybe a fancier heuristic than just detecting cloud providers. Maybe we can find another another uh heuristic that gets us to like be correct. In more percentage of cases,.

E

Question on: is this config stuff or zero six zero? Are you proposing any config change to the concluding that.

C

No yeah, no config at all.

E

Okay, I was gonna ask uh if we are going down the route of having, in the future, more sort of elaborate config for our config mount, but there's more and more stuff in there. It might be a good idea for us to start like versioning that config, just like we do all of our.

C

Yeah I mentioned that in slack, but yeah we could add an api version, even though it's not I don't. I don't expect it to be a kubernetes object. Yeah.

B

C

It's just a way like the way that kind uses version configs for static files, um so yeah- and I I mentioned too like the this section of the config I'm talking about- would also be a place if we want to add configuration for the coop cert agent behavior. We could add that into um but again this.

D

Is basically like.

C

Future future api work, um the example here I gave oh something else important in the config. If we scroll back up for a second uh something that I think we'll want to be able to do in the future is disable the automatic creation of that load, balancer service and let the user configure that out of band so say like maybe load balancing, doesn't work in my cluster, but I have a host port. I forwarded correctly, and I know the external name of that host.

C

I know the external endpoint that you use to connect to that, and I know what ca bundle I want to use, so you should basically be able to statically configure all of that. If you want to- and if you do that, then we wouldn't create the load balancer service, but we would still like run the proxy.

C

Okay, so the first example uh this would be on a cluster where the like, on a kind cluster, um where the token credential request api works. So you can see that it has a success status and then the impersonation proxy would be disabled because it would be in this auto mode where it detected that it wasn't on a cloud provider cluster, and so it just turned itself off.

C

The second example is the other case where you are on a cloud provider cluster and so the token token credential request api right now would would still attempt to run, but it would, it would error out. We could make this fancier, but it.

D

Would error out and then the impersonation proxy.

C

Would start up and it would have this connection information um and then yeah. One alternative api idea is just a structural thing about how that strategy status information is laid out. I think this is like a style question. I don't really know what the right answer is in the in the first exam. In the the main examples, each of the strategies has its own status type.

C

I mean this example like they share a common strategy status object. That then has like some specific information under it. um I don't know what the right answer is. um Okay, sorry, that was a long read through. I wanted to make sure there's some comments that I wanted to get to that are further up in the dock um nancy. If you want I'm happy to share too, if you want to uh either way.

A

You want to drive yeah.

C

A

C

C

I could tell I.

D

C

C

No, that's the wrong doc, this one okay! So one question was about.

C

um uh Oh, I think I think I kind of addressed this the example at the bottom. We can. We can talk more about that. um The implementation, um I think, essentially we just need, like some in-memory cache of like what the status of each of the strategies is and then in our authenticator controller we can have a controller that copies that into the status of each authenticator.

C

um I'm not I'm not sure exactly what the implementation would look like, but I try to mostly focus on the api design in this dock, but it seems feasible to me that you would have um some piece of code that when the when the status of one of the strategies changes it broadcasts that out and applies it to all the current authenticators and then maybe in the authenticator controller. When a new authenticator is created, it needs to go pull that in I, it might be a little bit complicated like.

C

I think there might be two paths that actually set that status um or we'd have to like make a informer, basically make a fake informer that that feeds the existing controller code. I don't know mo mo. You may have.

E

Ideas about how we do this yeah, it's not that bad! You just need to be able to reference one from the other.

C

And then this was another good question about: can we basically can we get away without having um any config in o60?

C

Because if we do that- and we always have just this auto detect mode, we won't be able to test this code in kind, we'll have to only test it in in the cloud provider clusters which I think is a legit concern.

C

um We could start with just a really basic config that just forces it to be on, and that would be enough for testing. I think um we could. Even I think I mentioned we could even do that with like an environment variable that we really don't expose as an api at all. Yet um because we even even though load balancer services, don't work in kind. The service, the cluster ap part of the load balancer service does work. You can actually talk to it through squid, so I think we could.

C

I think we could make a test work in that way.

C

I'd also be willing to accept that, like this functionality only gets tested on real cloud provider clusters- and we just have to maybe maybe pull one one of those cluster types into our pr pipeline. Then.

F

All right could, I add, a comment there yeah, I feel like we should not, because it's it's easy to test this in kind. I feel like this. We shouldn't give up what we have today, which is that you could run all the integration tests on your laptop.

F

They all run immediately uh early in the pipeline, and it would also be nice to do what you said as well to add a real chicken e cluster or a real aks cluster, to make sure it really works here as well.

C

Yeah I mean, I think yeah I don't. I don't think it should be impossible to get this to to test and kind, um and I know like really easy right. Yeah it shouldn't be, it shouldn't be harder to let it run.

F

Let the surface run, you don't have to do anything special for a load balancer.

F

The only thing.

C

The only thing that might be need a little bit extra work as if we have a controller that creates the load balancer service and then wants to read the external name that gets put there.

C

um Nothing in kind would ever set that external name field. That's how you would kind of know that it wasn't working, so we might have to in our test reach out and pretend that it got an external name and just set that field.

C

um But that would be fine.

E

I would be in favor of, like I don't know, cube does cube underscore, so I would say, like pinniped underscore unsupported underscore force enable maybe.

C

Maybe yeah I mean I don't think it's very much work to go ahead and add the little config section here and just have just this. Just these config fields.

E

C

E

And force not necessarily.

E

Yeah, they believe in means right now.

F

So we come down to um how good we think we can do auto detection.

F

I don't think we have a solution at the moment, but the library that we were looking into, I think, isn't gonna work well for product, detecting, maybe.

C

We can find a.

F

Different approach: okay,.

C

um Those are the main main questions and then I think the last comment was about basically is oh. First of all, I guess I want to ask: is this ryan what you had in mind as like another type of api uh structure,.

F

Roughly, that's that's more similar to what we came up with for today's existing api. I don't feel strongly about it. I remember we had a bunch of conversations when we designed the credential issuer api, and this is what we came up with yeah.

F

I don't know if there's any huge advantage to it being an array. I think we at the time. If I remember right, I think we were thinking about like if you were going to write the client side code, which, which would be easier for the client side code, to look.

A

F

um And I think we lean towards an array for that reason.

C

Yeah having it as an array lets the server express and preferred ordering, which seems interesting like if we have things in the future that we think are better, then the client can just loop through this array and choose the first kind that understands how to how to do it more.

E

Maybe I should you like very carefully explain the difference between the two I'm looking at them.

C

Okay, yeah, okay. So this is.

F

C

Yeah, this is an array where each entry of the array describes the status of a particular strategy, and all of these fields are all like one type here and here you're looking at like the same type and then there's because each strategy has some strategy specific, like configuration status, there has to be this extra little sort of tagged union field inside there. That has the specific data for if the impersonation proxy is working, here's here's how to connect to it and there would be a similar little tagged union field for the cons.

C

The uh token credential request api- that's different from here where this is not an array, it's just a object with two fields that each has each of these fields in is a totally different type. So actually this status field here and this status field here are two different. Go.

C

uh Type members struck members, so I think if you write code that handles this, it looks like a bunch of if statements.

C

If you write code that handles this type, it looks like a for loop that loops over things.

G

I mean: isn't the isn't the client just gonna, so I'm thinking about a client of this authentication thing and isn't the client just gonna wanna know. Where do I make my http connection and like maybe what do I use for a proxy? What do I use for a ca bundle? What do I use for a api path, something like that.

C

Yeah, so the client of the client that would actually be reading this status information is mostly the pinniped git coop config command.

C

So you and when you run piniped get coop config, you would say which authenticator do you want to use? It would go read that authenticator status and say: oh. If I want to use that authenticator, I can tell that it's running in impersonation proxy mode, so the kind of coupe config I need to target. That is one where, for example, the server and the ca and the coop config point at the proxy and then the command that's embedded inside. There is the version of the command that wraps up the token for the proxy.

C

um So I think the client we're talking about here is is that git coupe config command, and then you can also imagine like other downstream cases where they copy that status, information up somewhere else and but end up pulling it down and basically using it through some other data.

F

Path once very small advantage of an array is if, uh if the user, installs pinniped- and they ask they forcibly say, please do not run the impersonation proxy. If we support that option, then the server could just omit the entry from the array. It just wouldn't be there at all.

C

That's true, I would almost think we would still have it there and have it say, disabled by config, or something like that. So it's obvious one other thought I had is that with the with this shape of api. This is this is a really trivial thing, but in this shape of api we could pull out the status fields of each of the strategies and actually pull them up into the uh the column output of get the the coupe ctl output.

C

So if I do cube ctl get john authenticators, I would see here's an authenticator it's running in impersonation proxy mode. um That I think, is harder to just describe in open api.

C

If it's an array, I don't know we could we could solve that a lot of other ways that we could have like a summary status here. That says like this is ready and it's in whatever mode.

C

I don't know. um Also I mean something else to note about the api here is that it doesn't prevent a particular authenticator from having both strategies working, which I think is something we want in case. We add in the future a new strategy. We want to keep one of these old strategies around for existing clients, but have something new. That's that's newer and better. That should work. Okay, I think.

B

Had the discussion in the past, it seemed like people didn't want to keep the other stuff around. If we like say got stuff upstream, is that I don't know good.

C

Question yeah, maybe.

B

We got something less happy, you know we wanna. Do we wanna.

C

Maybe so I did also. That was another thing I guess I I did try to use this is this is partly just kind of an example.

C

I don't know if this is the exact string we'll use, but I tried to describe this strategy as the token credential request api, not necessarily the use the cube, signing cert api or strategy like actually we if we have a future implementation that uses the csr api to get certificates, it doesn't really matter from the client's perspective, because, basically all they all the client needs to know is that the token credential request api is working um that'd be part of it.

C

I think the other part of your question, though, is yeah in the future, when we might make some design decision about what to support and what not to support, but at least we have the option if we have the option structurally in the api, if we want to keep supporting old stuff, we could.

F

Separate from that concern, it's also nice that you can run both strategies at the same time again for testing reasons.

C

Yeah yeah um another side effect of having the api structured. This way that I think is interesting. I don't know if it's useful, but I think it's interesting. You could have different authenticators that support different subsets of strategies. So one example is, I could imagine.

C

A strategy maybe a future strategy that did some transport level credential binding, so meaning like a client certificate that wouldn't work over this api. It wouldn't work with this strategy, but it would work on the impersonation proxy, and so we could actually say hey that this future, like cert, authenticator client. Third authenticator, is publishing a different set of strategies than the token authenticator. On the same.

C

Cluster, so anyway, I I don't want to. I don't want to uh drag down too long here. um Do folks feel like we can move forward with this.

F

Maybe we maybe need a little more investigation into how how good of a job we think we can detect auto, detect these particular cluster types, but assuming.

D

F

Figure that out.

C

Okay, that's fair. I think it's good that we've started that work already. Hopefully.

F

I don't think that, actually, if, if we decide that we can't do a good job auto detecting, I don't think it actually changes the design very much. Then it just.

D

F

With manual uh enable disable- and maybe a manual auto, give me a load balancer or never give me a balance, or it would become the two option.

C

Yeah yeah, that's another another detection strategy we could use instead of having it trying to specifically detect like these three cloud providers, which hard coding like detection of three specific club first is kind of janky.

C

um um We could also try to detect, do load, balancer services work on this cluster or not by creating one and waiting for it to get an external name.

C

um That would be also a valid way to kind of detect kind clusters versus other clusters.

C

I think, though, I think the one I think moe dropped off the call, but um the one problem that mode mentioned with that is uh on a cluster.

D

C

Both of the the current strategies working, we actually don't really want to use the impersonation proxy unless we have to like. So if the token credential request api works, it'd be better to not even run the impersonation proxy at all and uh that's awkward because of how kind of eventually consistent all of our logic for creating this is.

C

Okay, um I think maybe.

F

I think it's another you're mentioning. If, if the api is an array, then the server could kind of insert its priority decision by giving the order.

F

Well, I guess we could do that on the client side too, we could put priority decisions on the client.

C

Yeah, I feel like I did maybe.

C

B

Like even if the client isn't using it, I guess you're running it.

C

B

C

B

C

Did change my mind, I think I do like this api structure router now that we talked about it so I'll probably rewrite this. um Okay did mo leave a comment about where he went.

D

He's joining an upstream meeting.

C

Okay, all right.

D

This is gonna seem remedial, but this is largely because I just got back this design. Is this the design that you all have moved ahead with for the in-flight story? That's around the minimal impersonation proxy, or is there more here that we haven't actually prioritized yet in terms of.

C

Api work, the work so far, so there's, I think, there's sort of two pieces of work so far. One is just the the runtime behavior, the one runtime implementation of running the proxy, which is actually independent of all of this. This is all just like how we tell how to run the proxy or when to run the proxy or whether to run the proxy um in the case where we do run the proxy. We have that code now. Essentially, maybe it's not completely done, but it's there.

C

Then. The other work item is the detection of uh detecting these different cloud provider. Environments, um which I think is uh I don't know mark, do you have any status it sounded like the status was the first thing we tried didn't work very well.

B

B

With the the auto detection stuff, I don't know ryan pointed out that we could pretty easily detect that you were on.

B

Like that, you were on ws, but not necessarily a ks, specifically.

B

um Or I don't know the same like right, where it's hosted and not necessarily the type of cluster where, like theoretically, you could spin up your own on their servers.

C

Yeah, there's a bunch of.

B

uh Actually, the same, and it wouldn't be uh like cloud hosted in the way that we're interested in.

C

Yeah, um I think I think, there's enough metadata in the cluster that I'm confident we can find a good heuristic because, like there's the the node the field on the node object- which I think is the thing we started with, I think as a problem you're mentioning there's also like the version info of kubernetes and most of the providers ship, a version of kubernetes, where the version string is specific and has has the name of the provider in it.

C

um Another thing is looking at the node objects and finding the nodes that are labeled as control plane nodes, and if you don't find nodes, labeled control, plane nodes, then um you know you're you're, probably on a cluster, that's not self-hosted um anyway, I yeah, maybe maybe we need to. We do need to so what I'm looking at the issues here.

C

uh This is the story, that's finished, but not delivered because we haven't uh merged. We were basically waiting for o50 to land. um The this story, I think, goes away.

C

Maybe- or maybe we add, we rewrite it, rename it to just add one field to our config map to do the like force enable uh this is the status information, so it needs to be rewritten to say that you've discovered this information via the authenticator status.

C

um So we can take that after this um and then these two stories actually stay exactly the same. I think so and then maybe there's another.

A

C

Auto detection.

B

Yeah, I think, that's a separate issue. Those last two stories are there's already like uh uh work for those um on the impersonation proxy branch. um I anticipate that changing with the implementation of the new authenticators back, um but there's already like stuff in flight there. um I think the branch is like kind of.

B

The impersonation proxy branch at the moment is kind of an amalgamation of a few different stories and isn't quite like easily teased out into that minimum impersonation proxy. uh You know this story that story just because we've been of holding stuff back until um go 5.0.

C

That makes sense, um okay, so the last agenda item nancy.

D

C

Can turn it back over to you if you want, or I'm happy to just finish this out? The last agenda item um is about this story or that this pr, which might we may we may or may not want to ship today in the release and we may or may not want to emerge. I haven't I've, read this issue and I feel like I didn't, really understand it and I don't really have an opinion.

C

um I know that mo had an opinion, so maybe we just need to table this and and talk about it when moe's back. I don't know.

G

We should we should try to talk to him like as soon as possible, like after. This call like.

C

After this call, because I would like to cut the release like in an hour- yeah, okay, I think that's fine um cool window- shout outs this week. I guess, but we're here we're waiting.

A

uh Okay, so anything else, anyone wants to bring up before we sign off.

A

No all right! Well thanks everyone for joining um the community meeting if you're watching this uh from home after it's been recorded. Please join us live for the next pinniped community meeting. That's happening happens every first and third thursday of the month. So today is the first thursday and we will meet again on the third thursday of february. So we will see you then, hopefully than that. Thank you.