Cloud Foundry CF on K8s Forum, 3 May 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: CF for K8s Working Group Forum Call May 3 2022

Description

[GC] Go vote for the logo!
[GC] Is the rename (#931) done?
[GC] Nominating Clint as an approver
[GC] TaskWorkload proposal?
[TD] Remember to review and give feedback on Support Interchangeable Build and Run Implementations
[RI] Should this document/Working group be renamed? On Slack?
[RI] Install process - stuck at domains :(
[KB] RoleBinding latency
[KB] HNC explore

A

B

C

Cf on yep I'll get the training started. Well, thanks again, everyone for coming to the bi-weekly cfo kubernetes working group form. We have a number of topics to cover. There is a link in the chat and we will just get started on the first topic then. So the first topic is go vote on a logo yeah. We have a.

A

C

Options and we have a pull up, but I think.

A

Yeah we have uh you.

C

Want to elaborate on this.

A

We have eight uh logo options, plus five uh logo type options and then we'll vote. We we need to vote on both and then the combination of the two will win and.

A

We already have like 18 votes, so that's already almost twice as many as we got for the name, but I guess uh the modem area. So I think we want to close it, maybe by the end of this week, so I think we can keep it open until friday uh afternoon. Oh do you think we should like establish like a very strict deadline, uh because technically yeah I mean I like to close it on either. We close it on friday end of day like midnight.

A

Basically, and then I will get the numbers out on monday or we I take some hours at the end of friday. What do you think.

C

Yeah, um I think friday is a fine deadline.

A

Because I could say friday my lunch break as the deadline and then in the afternoon I crunched numbers, which is what I mean, and we have the logo by friday end of my day.

A

Otherwise I'll just push everything back a little bit. Okay, let's do that. Yeah.

C

A

Have 18 votes there's need I.

C

Think half.

A

A day is not going to make a difference, so I'm going to post a message saying that that line is whatever the utc is. For my lunch break.

C

Cool sounds good. Yeah it'll be interesting to see what uh shakes out of that.

A

Yeah, of course, uh giving a sneak peek at the the data, but I won't say yeah and also the the whole ranking system means uh it's not super obvious to tell just by looking at the votes uh you mean you can see, you know some are definitely more liked than others, but uh the beauty of the system is that it's in the end. It's a compromise right. So we'll see what comes out.

C

Cool awesome: well, regardless it's going to be exciting that we finally have some traction on this. So.

A

Yeah and we have a readme story so hopefully, once the logo is ready, we can pick that one up and have a readme with a logo and some useful information in it and that's gonna be another step towards the release. I think at this point we're very close.

C

C

uh Let's see next topic speaking.

D

Of voting, I I did manage to get a copy of uh the electo project up and running on cloud foundry, although I didn't try on grief yet uh with the python built back. um So that could be useful in the future, uh especially.

A

D

Have a community-wide one that people.

A

D

A

uh I looked at the thing. I don't remember what system they they use, because I, what I really geeked out on is like the different systems of ranked voting etc. In the end, uh I I chose two just to compare them and they always yield the same results which I guess is good, but it'd be used to see which one it uses.

D

I mean it's the same one we used with that cornell system last year with uh uh condorcet rankings.

A

Okay, I'll check it out. Yeah I mean. Do you remember looking at the project, it's a python web app, okay,.

D

Yeah kubernetes and that canada they've been using it for their various selections.

D

E

Yeah yeah, it says it's it's for cncf, very nice cool, I'm doing it the native way exactly the way it's supposed to be done.

C

Yep cool, uh so the next step we have is the rename done which has a linked github issue.

A

Yeah, so that story has been sitting for a bit. I think we got stuck because at some point we couldn't decide whether to rename the secrets repository and then we all agreed. We will we're not going to rename it. So I think akira closed all the closer ball that needed to be closed like for that thing to be called over.

A

I was wondering if there is anything left, because otherwise I'm happy to just press close on it and that's one fewer story in the in our 0.1 milestone.

C

Yeah, I think it's effectively done. As you noted, the one outstanding thing was the sort of boolean value that the cli transmits, um which it has not been renamed, because obviously that then requires a change to the cli and all that. So I think we can consider it done with the knowledge that that is one of those remaining uh threads that we need to decide. If we want to do anything.

A

All right because it's called cf1k it's the flag.

A

I mean on one hand we could argue it makes sense for it to be generic, but on the other hand it's a very specific implementation. So it's not like it would work with anything but creepy. Just because griffy knows exactly how to handle the headers but yeah. Maybe it's not worth yeah uh a breaking change, because then people will have configs around. I mean it's just us really.

F

Yeah, like we kind of talked about a few weeks ago too, and decided not to do anything with it and if, if we truly wanted to in the future, like you can just support both for a while and migrate people over. But it's like doesn't.

A

Matter, that's probably the best thing to do. Okay, yeah, I mean okay, it's pretty much invisible. No one is ever supposed to edit that file.

F

Yeah, okay, just.

A

F

In the past, that's what we did so like the logger, gator and log cache is an example like both of those are are in there and then eventually you can. You could like theoretically drop one off, but it's it's not a huge cost. To just add another line to that json.

A

Okay, so I've dragged it into reviewer approved and I guess I don't really need to accept this. So just close, it.

E

Cool boom gone nice.

C

Awesome um continuing down the list, we have nominating clint as an approver.

A

Yeah, so it's not here, but um we've been waiting for a while for clint to reach the requirements to be able to be nominated as an approver of the project, and the requirements have actually changed recently to include like a wider range of contributions and with this new criteria I checked and yeah he's. He qualifies really well and he's been contributing for like three months, so I think it makes sense. I have created the pr I don't know like I've added georgie as the other lead to approve it.

A

I don't know who else needs to prove it? I guess once we have consensus among the leads, we're fine, we don't need anyone else to prove it. So maybe I'll just proud georgie to to approve it next week and not next week, it's not friday uh to approve it tomorrow and then uh we can get it in and you can finally start pushing code like everyone else.

D

Cool yeah I'll be curious.

E

D

Logistically on the community repo, if uh we can merge after georgie gives his approval, you mean permission wise. If I can do it myself, no, no! I think we need, like some um some other approval on it, but if it's like good enough for him, just with whatever permission scope, he has on the community repo right now so should I add someone else's on a as I remember.

G

I just I'll I'll.

D

Pay attention to it as a tsp.

A

D

Needs like a rubber stamp from someone.

A

D

A

um I was wondering like there's no automation in place yet for this stuff, so, like I once that's in, I will manually add them to the group of approvers by myself.

D

Okay right we've started discussing um setting up automate automatic generation of the github teams in the cloud foundry org from the contents of the working group charter yaml. But um it's not done yet. That's kind of the.

F

D

Step in regularizing, all the teams that are in the org.

A

I had some ideas about it, but it looks like the thing is progressing by itself, so.

D

A

D

A

I mean yeah, but I was like I I was. I had an idea of kick-starting the thing, but it looks like it's already. The conversation is already there, so it's good and then I guess once that happens, we'll yeah we'll have to deal with existing groups, but yeah we'll think about it. When it's time.

C

Cool yeah uh exciting to have people reaching those milestones, so we can continue to have a active group of people, so the next topic is task workload proposal.

A

uh Yeah, so the context on this is I'm working on the tasks proposal and the task proposal, I'm proposing that our tasks implementation relies on some underlying obstruction for running like one-off things, and this is so that we don't couple ourselves to any like to. I don't know the implementation details of the job resource or whatever right exactly like. We do for apps, like we have this intermediate long-running process thing.

A

We do the same for tasks and we are in the middle of proposing a the introduction of these new abstractions to replace the irini ones for the long-running stuff for the building stuff as well.

A

That proposal does not include anything for one-off stuff, so I wanted to ask the group what do people think about like which of these things should go? First, like we have different options. We have we implement tasks using irini and then one day we will introduce this new interface and switch.

A

We can block the tasks epic and have like a new epic for introducing the tasks or a new proposal to introduce the task workload, or we can even extend the existing proposal to introduce the task, workload, abstraction and wait for that to be implemented before we do tasks honestly, I'm inclined to just do the first, because that way, I think it's easier for us to work like in parallel.

A

It's it might require some rework when once we switch interfaces, but I'm starting to think it's not going to be much anyway so and in exchange we get some some more agility like fewer dependencies across different tracks.

C

Yeah, I think if the cost is relatively low, the rework cost. Then that makes sense because you sort of enable that task workload earlier on, and it then maintains some consistency where you have everything implemented with one set of workloads and then later we can abstract it and uh probably is even somewhat reusable at that point.

C

If we find a sort of more generic interface, then you at least have the groundwork, blade and kind of uh pull it into somewhere else.

C

um But if the cost is high, if you, I think you're a little more familiar with the workings of that. If the cost is high for the rework, then we might want to consider one of the other options, but.

A

Yeah, I suspect the cost is going to be low because it's just kind of a just, a very narrow interface. It's like you know when you create a task. It's not like. You have many things to specify.

A

I can't honestly, I don't remember exactly what what the arena one looks like, but it's probably like a com, an image, a command to run, and that's it.

F

It should be very similar to lrp it's the same stuff. It's just. It terminates right.

A

Mvars all that kind of stuff yeah it needs to go in probably.

F

A

F

Implementation will look very similar to the process controller.

A

Yeah- and the only thing I can think of is like the this status enum versus conditions array like if we're gonna do some work to translate from a conditions array to a statocenum and vice versa.

A

That could all be avoided if we skip the irini thing altogether. But maybe it's not that big of a deal. It's like a for loop. That goes through an array and figures out. What's the most recent condition and use that like it doesn't sound incredible, maybe I'm just you know overestimating the problem, the problems with that one so maybe yeah. We just use arena you're right that it's nice to have everything points to erini, and then we can kind of potentially swap the thing all at once, and maybe at least in different releases.

A

So we're going to have a release that just points to irini and I released it. Just uh he's completely decoupled from irene it'd be nice. If we can coordinate the the the epics that'd be nice.

C

Yeah, I think it especially even if we were to wait until we decoupled it. There would still be a certain amount of work to go back and ensure parity with irene uh and any other task uh workload that we want to implement.

A

Yeah, I'm honestly, I'm keen to to to fill back the the european backlog, because now I think we have a bunch of chores but, like we haven't done any feature work in a while. Thank you to I'm keen for the for the team over here in mia to um start doing some some feature work again.

E

Cool, it should be up.

A

C

Makes sense, let's go for it if anyone has any dying desire to or concerns that they want to bring up, then they can either through the next meeting or slack or whatever. But I think it sounds like a good plan to just move.

H

C

C

Cool unless there are more comments on that, we have a remember to review and give feedback on the support, interchangeable, build and run implementations.

C

There's a document attached to that.

F

Yeah, um so that's the proposal that matt had put out for the other two abstractions the build and and run workload as as they're called in there. I know um there has been some more feedback on it and stuff and um so far like there's nothing.

F

I've seen that disagrees with the the proposal like at its core or anything, um and in fact, matt has started writing stories for the build side of it, because that's also um much less like I, I don't think any of us truly controversial, but there's been less like feedback or like anything on that. So I think um one thing that would be useful for him uh would be some more feedback on just what that run.

F

Interface looks like like whether or not we want it to be pod, speckable or if we found value in like the some of the lrp abstractions that the irene lrp has. So I think feedback on that interface is is something he's looking for. So just sharing this out again.

A

Yeah, so I added just a comment on the name. Just I think I I think that run workload might be a bit generic, but that's just a detail. I guess um regarding the uh interface hot speckable interface versus not I kind of put my hands forward and it was like.

A

I was telling people check that out, because you know it's see if you like the prospectable thing, but I looked at the proposal and it's not speckable in the like it doesn't have the pods back in it in the proposal.

A

uh Does it mean we've already given up on that or do we want to bring that back and see if people like it or not? um Well, because I my understanding is that there will be pros to that, even though, of course it comes with cons but like maybe, if you're not convinced, yet we could bring it back and have two alternative designs and let people discuss on that, while it's early.

F

Yeah, that's a good point actually um reminds me. I forgot something there uh yeah, so the the cr definitions in it aren't, like the end, all be all matt wanted to actually like start working on the implementation to to fill out what what worked and didn't work in them before like presenting that part so yeah this. This form of the proposal actually is like.

F

Does the concept of this resource feel? Okay and like does this make sense? What we're doing um but like the concept, is independent of like what what it actually looks like at the end of the day, you can always massage things further and back and forth and stuff.

A

And I think we have wide consensus on the fact that it's a good idea to do this thing. Like we've been talking about it for a long time, uh there might be disagreements like on the specific of the interface definition. I don't know if you want to solve them now via this or if we want to do it in the future, with other proposals or draft prs.

F

Or whatever yeah, I think um no, that's that's a good point. I I think it's difficult to discuss it without having discreet things, to look at and comment on. There.

A

F

A

It's it's I mean if you have, if we believe both interfaces could come with their own advantages, then it's a shame to kind of been one just because you assume that people won't like it. Maybe maybe it's not. Maybe I don't know it's good to uh just show them both and see see what people think or maybe we can come up with something in between. I don't know.

F

Cool well um that all sounds good. I'm it's good to hear that the core of this is like acceptable and stuff, we'll let matt know today. What are you saying.

F

You've uh put your name on it as a person who reviewed it. So that's good.

C

Yeah uh definitely gonna have to take a closer look myself and if anyone else wants to drop the link and chat.

C

Make sure everyone has it cool all right? uh The next topic is, I believe, from rob, which is, should this document working group be renamed on slack?

C

um I think this comes from the perspective of gaining an actual name for the newest iteration of the project being carrifie.

C

I can offer my two cents immediately or you can. If there's something specific you wanted to drill towards, you can do that, no nothing specific or code for it. Okay, um I think the feeling was that the cf on kubernetes working group form is certain umbrella that works on or maintains responsibility for several different projects, and while the newest flavor is the one we're really concentrated on, it's really a form for anything that is in the kubernetes space.

C

That is cloud foundry related, um so that would be still like having uh cf for kate's under the umbrella for any topics, people need to bring up as well as anything else that is adjacent any like projects like irene and all that.

B

C

B

Can you leave it like that.

C

Have any thoughts that disagree with what I have said.

D

A

Think it makes sense.

D

Yeah, this came up in the toc discussion um earlier today when we were just reviewing pr's on the community repo.

D

That was the vantage point that I advanced as well, so that we we don't want it to just necessarily be scoped to creepy, but that's the active thing we might want to rename the slack channel, though um I don't know.

C

D

hmm Maybe like just cf creepy dead.

A

Yeah, I guess it could be. It will be easier for people to find. I guess if people look for help on the project, in fact yeah. That means we don't have like a working group channel anymore. I.

G

Was going to say, do we do we want a working group channel because I see there's a convention for other working groups, so they have wg working group name.

A

Yeah, I think it will be very redundant for us just because we only ever work on one thing so like on paper. It makes sense, but in practice we'll have yet another channel right which one we won't be using. I don't know either we I don't know I did.

A

The argument for the slack channel named after the project is strong because, like yeah, if, if I were someone who was curious about this and I joined the cf slack and I would be look I'll be looking for corifi and at the moment, if you search for korea, nothing will pop out. I don't know if there's a maybe a way to associate keywords to channels or something just to make it easy to find, and we could keep the current name, but at least make it easier to find for people who search for korea.

A

I don't know if there is anything like that, like labels or metadata for channels, I don't know otherwise, maybe it's worth renaming and if one day new projects start popping up and the need for a working group channel emerges, then we can create the working group channel.

A

Maybe there's no there's no rush unless there's like a risk that someone steals the name, but I don't think that's a problem. I think we could co-opt it in that case, yeah exactly the powers so yeah, maybe maybe yeah we we should rename it. What what are the.

D

Questions I'm making a private.

A

Channel name that, so what what are the consequences like do? We uh do we break stuff like I was wondering if maybe there was some automatic redirecting.

D

I think slack will.

A

D

If you renamed a channel and like I'll say this used to be named safe, kids, dev or whatever and.

A

How much automation we have in place that posts on the channel, but those things could break, although yeah, I think actually, like computers refer to channels on slack via ids that the channel is actually just uh it's like your twitter handle it's actually a just a label. The actual id is a number or something. So maybe it's fine yeah. I can take that on to to do the rename if everyone agrees or do we want.

A

Maybe I'll do a quick check on like I'll post a quick message on the channel first see if we have, because I don't see many people here see if everyone.

C

Is on board and then.

A

C

I would do that. That seems like the right thing to do is post a little message, give people a little bit of time to react and respond and then we'll go from there. Okay, cool, okay! um Next topic: it looks like the install process. Has some rough edges, perhaps um there's a document linked which looks like a bunch of steps.

C

uh What particular lee are you seeing? um So we can kind of quickly assess how much we can help you right now versus async.

B

Yeah, I think async would be best because this might go down a rabbit hole, but uh by way of background, one of the things that we did with like cf on cf for kids uh was to have very specific installation docs, which is very step by step, that that pertain to different infrastructure providers. And that was that made the whole thing slightly more relatable, and this is like you know,.

H

Install cf on kubernetes.

B

For dummies kind of uh approach, um so that's one of the things that I was trying to do for curry fee as well, and the first one that I picked was google kubernetes gke.

B

I'm stuck at the point where I'm unable to do a cf push, and I think I posted the error message. I got like a bunch of different feedback from different folks, um I'm able to install it and log in reliably when I follow these steps, but the push itself isn't working and that's the only part. That's uh failing. So I'm going to try and do kind clusters this week or switch to a different provider this week. But I don't know if it's a problem because I'm using like a wildcard domain provider and things like that.

B

But I imagine if like login works, I guess cf should work technically, but I don't know I'm out of options and.

C

uh That sounds good. I can try to run through your little instruction set later and see what I find uh off top my head. You need to make sure that you do have the sort of default domain uh provided for the cluster and, typically that's done by just doing a cube. Cuddle apply, but you've probably.

H

C

Done that so it might be something else, but if you haven't done that, try that and see if it works but uh yeah. Definitely anyone here that can provide some support.

C

Let's try to make sure we can get this working, because it's definitely important to make sure that the out-of-the-box install process is not uh painful or difficult um cool. I just wanted to welcome. We got one more person entering uh the form so welcome. We have a couple more topics to go, so, uh let's keep on rolling.

C

So there is a topic about role: binding latency, yep.

H

um So I've put this on here because it's another, it's a problem, we're seeing now in the the unit tests. It's not really the unit test, it's the repositories, testing testing against xampp test.

H

um It's strange because in github actions you see like every five runs or something it goes, and does a random error saying that you don't have permission to do something.

H

um So we've been looking at this a bit recently um so from the kubernetes channel. We found out that we shouldn't make any assumptions about you having a permission once you've created a role, binding, there's, definitely latency built into kubernetes and the api or whatever handles your authorization will need to catch up with. What's in xcd um and that's what we seem to be seeing in github actions, you create a role binding. Then you try and do something that requires that role binding and it says no computer says no.

H

And yet, when you run the thing locally, um you never seem to see it. um So we've worked out how to make it happen locally now, so it turns out. Removing the race flag from the ginkgo test enables sort of our side of the testing to run a bit faster and that allows it to beat um kubernetes a bit.

H

So if you run the repository suite with race turned off, um you get one or two errors. Every time in out of every um test run, which is good and I've been um seeing, which tests fail. There's total random distribution through the whole lot of them different verbs, different objects, um so it seems, like we've, got a real problem there that we need to address um so vaguely thinking about two ways of doing it.

H

We can go back to the old idea of wrapping our kate's user client to try and automate um some exponential back off of retries on if we get a forbidden error that seems to work pretty well for um most cases, apart from our case, where we list resources across namespaces, so there we're just picking a whole load of name spaces that have any old role binding in there for the user, um and we expect a certain number of forbidden errors potentially and we don't want to go and wait like 30 seconds or something like that for each um each time we hit one of those still be trouble anyway.

H

That's that's one thing and we can look at maybe doing something slightly different for this thing and then the other thing is maybe we um when we create the role binding. We do the similar thing, that's in the organ space creation at the moment for hnc and wait until we can do something that involves that role.

H

It's binding bit more tricky, though, because I'm gonna have to change every single before each and the test to go and create roles via the repositories rather than just using, creates client um anyway. Just thought I'd bring that one up um for everyone's awareness um yeah. So previously I mean we had eventually in the code. I think um I think danny was particularly keen to get get rid of those, because no hiding problems in the real code, and now we've actually seen the problems in the real code. So we'll do something about that.

C

Yeah, I've definitely seen this as well, and it's a little bit unfortunate that we don't have a guarantee from the kubernetes side. But uh there are probably very good.

H

Reasons for it: oh yeah, another thing! So when we were struggling to reproduce this, uh we had an idea of doing a sort of chaos, monkey thing and introducing artificial latency on the role binding creation. That's interesting as well! If you do that and like create role bindings in a go routine with a a sleep beforehand, then you get to run the tests without the role binding being there when it should be there, um and then you can fail about 290 out of 300 repositories tests.

H

um So I think those that's the list of all the ones that are vulnerable to it all the ones. We have to look at yeah.

C

It's a significant number of them, yeah.

H

All the ones expected to work correctly.

C

Well, I wish I had a magical solution right now, but yeah. This will probably take some thinking and sort of massaging.

C

um Any other comments on that before we move forward.

C

Looks like nope, okay, cool, then the next fun topic is the hnc explorer.

H

Yeah, so I was just looking at what's on on the top of the uh us backlog um I saw it was uh explore to go and replace hnc and see if that's feasible.

H

um I just want to make sure we're doing it for the right reasons, because it has like three things in there saying one: the web books look at every single results in kubernetes and that's a security issue and causes problems.

H

I think two was um uh it was there was a latency thing: wasn't we have to do hacks to make sure the role binding exists uh before we carry on and then the third one was service? Account propagation doesn't work, um so I noticed that the first one with the web hooks looking at every single resource. I think that's just our configuration, um I suppose it's maybe a symptom that it's just coming out of beta and the one zero has only just happened.

H

I mean their their design is that you can decide what objects, what resources will be propagated at runtime by modifying a configuration and it will reload it and then start propagating those and for that to work. The web hook has to go and listen on all the resources and we can just not configure it like that. I mean I, I switch the configuration locally and it works fine if you only listen to role, bindings and secrets and it also restricts the name spaces it's looking at.

H

So I think that answers those security questions um and then the latency thing I was thinking yeah, it's a longer latency for hnc. So when it, when you get a very big busy server, I've seen it take eight nine seconds to get around to propagating role binding, which is annoying.

H

But now we have to deal with that in a small way, at least with uh with kate's, not noticing role bindings for a finite period of time as well. So I was wondering if they could be combined in the same thing, um yeah and then the service account thing. I mean I can't remember what the details were for that not working yeah.

F

I remember that one, um so the problem with that one is the service accounts. It starts competing with kubernetes core, like service account controller. That's like provisioning secrets for the tokens for it and those.

H

F

Names so you propagate ones that refer to secrets that don't um exist or aren't valid for those namespaces, so the agency workaround was just they have some hardcoded thing that ignores all service account propagation, um because there's no other way to solve that. So that's that one, uh the first one! That's a good point. um I don't think I think that's good for us to consider that we could tweak our config for it better, but I think there's still some things that um you can't get away with or like you.

F

It always has to watch every name space right like no.

H

F

H

There's a config option: where you can you can limit it to a regex if you like,.

F

Well, does that limit what's registered with the kubernetes api, though, because um so one thing that happened to me was agency became unavailable and then it basically prevented the deletion or creation of any namespace from from then on. Until I was able to get it healthy again, even ones that were excluded.

H

um It's definitely inside the web configuration but yeah anyway. um It's.

F

Possible on my cluster that it was just also.

G

The original challenge was that, since our open spaces were just named after guides, we couldn't apply a single regex that would just restrict hmc's scope down to our namespaces. Now we can't because everything's prefixed, with either cfo or cf space, so we can say cf star yeah,.

H

G

I think that's what we've done for 1.0.

H

Yes, yes, so the way it works is the webhook's got a namespace selector that matches labels. That says hnc blah blah blah included, namespace and then that's set from something else, one based on the regex and your configuration.

H

So we can now yeah, so the namespaces can be narrowed down, um but just don't change your prefix from cf see.

F

Yeah my um my cluster was before we had done anything with that.

H

Yeah, but I think the main yeah the main thing about hnc is it's um that's the slowness of it when it when the system goes under load that we're having to wait eight seconds. I think that's the real reason it needs to be replaced. So if we can do something better than that or or look at why it's being so slow, I really don't understand why it's being so slow. If you watch his logs, it does a lot of stuff. It wants to delete a lot of stuff all the time.

H

Yeah might just be our use case of bringing up a whole load of namespaces and deleting them in the tests.

A

My fear is that we end up being just as slow just because there is something underlying that we're missing. I don't know yeah like it's important that we ask ask ourselves: why do we think we can be more efficient than they are like? Is it because our use case is more narrow and we can skip some stuff or are they doing things really badly or you know what is the reason we could achieve much better performance.

A

Maybe maybe there's also a point in like pr like if we just find their algorithm or their architecture is really bad. I mean if it's, if it's a big problem like an architectural problem, then no but like. If there is anything we can fix in in hnc, it could be, it might even be worth.

H

The thing we were very keen on was knowing when a a propagation had stopped. Wasn't it like you could create a namespace and know that it's done, except they don't even try to solve that. They just have a queue of things that need to be propagated and when something gets created it goes and adds stuff to the queue now.

A

Like if you implemented that, how would you do it? Because, in.

H

The end it's impossible, I think, like.

A

It's a continuous process like it's, not you never done like you're continuously, watching the thing and propagate, so you can say I'm done for now, so I maybe there it would be useful to have uh an indication of that that the queue is empty.

A

I don't even know if that's possible, though, with with units controllers, it would be like I'm done for now.

H

A

Just wonder if we can ever get rid.

H

Of ugly hacks that are waiting for enough completeness to have to be outside of it. That's that's my worrying.

F

I have a feeling. The answer is: no, you can't truly get rid of them, but I think it would give more flexibility like to knowing if something is almost there or like mostly there, but um I think these are all like valuable things like uh just some with what you just said. Maybe you could also be good as a comment on this so like this. This explorer is not like to just like go out and do it those to make a proposal for some of of this discussion.

F

It's just to be informed when we're when we make that proposal about what um what the pros and cons truly are.

A

Yeah, because we, I remember like with the emea team just talking about this many times when we were like initially implementing the first version of orgs and spaces and hitting all these problems.

F

Yeah I mean maybe we can do better. I don't know I. I think we can't do better generically, but we might be able to do better exactly.

A

What we're trying to solve? That's the key, that's the key like maybe our narrow use case, gives us some edge in some things.

C

That's definitely my feeling is that the first part you said, which is, we have a lot more control over what we want to do in this narrow area. So I don't mean there's also.

A

There's also the gain from losing a dependency, so it's like. Okay, maybe you know, even if it performs exactly in the same way but like having this. I don't know. 50 100, 200 lines of controller code for us is worth uh if it replaces a whole dependency that we don't have to track, for you know that we don't have to install, don't have to check for for vulnerabilities. We don't have to check for com. You know compatibility with different versions of kubernetes all that kind of stuff. Maybe it's worth it anyway. You know yeah.

C

Yep, I think you kind of nailed it there is. uh We can see potential benefits, but we can't say for certain those will materialize the way we want them to. So we want to kind of check it out and see what makes sense.

H

On the hnc side, I did see the um there's a developer. That's looking at performance on that as well, and I think his pr's were deferred to the 1.1 release.

H

I don't know how much they'll help, but it was stuff, like he's not using concrete, um there's clients that have the concrete object or there's more dynamic ones and they're just trying to replace all the dynamic ones with ones that weren't you know doing um doing stuff on the fly to make it a bit quicker.

C

Yeah, it would be interesting to see what that does and what their schedule is.

C

um We might have a little bit of a race condition there, but it's probably worthwhile, regardless for the aforementioned benefits of not having an additional dependency if it works out. So I think the explorer is still a pretty valid thing to do just so, we can inform ourselves.

C

Alrighty more thoughts on that.

C

Cool uh looks like we have come to the end of our list of topics. um Sure people noticed we had an additional person pop in which is really cool. They want to get involved, they're going to ping rom so happy times, and I think with that, unless people have final comments, we'll break and uh I'll see on slack and elsewhere, thanks for coming, everyone.

B

Thanks everyone bye.