Cloud Foundry CF on K8s Forum, 11 Jan 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Cloud Foundry on Kubernetes Working Group Forum Call Recording 11th Jan 2023

Description

2023-01-11
[GS] Almost ready to release v0.6.0
Breaking changes in helmchart
Replaceable networker
[GS] App revision
Kubernetes API conventions
generation: a sequence number representing a specific generation of the desired state. Set by the system and monotonically increasing, per-resource. May be compared, such as for RAW (read after write) and WAW (write after write) consistency.
[GS] Next EMEA epic
Labels/Annotations + things from the US TODO list in the github project
[Ram] I'd love to see some blog posts or live streams on Korifi soon now!
Need some comments around "6 months of Korifi" or "½ way to v1.0" or something like that.
Ram to start a doc with an outline/some prompts for us to pitch in async

A

Hello, hello, hey.

B

A

Happy New Year.

C

Happy New Year.

D

Happy New Year I.

A

D

If I said Happy New Year to both of you so yeah, but that's not here to do it again, just.

A

D

A

Least, it hasn't changed right now. It's not.

D

Like a question, yes, exactly.

E

A

I wonder if we're getting more people or I feel like we should.

C

It's a different Kieran are in, so they should probably join any minute. Okay, it.

E

Looks like both literally and figuratively. A lot of people are still in a holiday mine.

A

That's right, don't judge me.

A

C

Will be wait for more people, hello,.

A

How are you going.

A

You know I think Georgie. These are all it's all your topics, obviously others can add more too.

C

It's uh it's there from the whole India part, basically I just nodded them to the dock, okay, cool! So yeah shall we start with the first one then promise to typing in something but I guess we can also add them as we speak.

C

So yeah first thing is that we think we're almost in a position to do. A new release uh have a meaningful chunk of work, which is the replaceable networker, and we also did a change to um Converge All. The controllers in one pot.

C

I think this was something that we were discussing uh for a long time that we should do it and because it will scale better and all that, so this will be the main thing in the release. uh I guess it comes with some breaking changes in the helm chart because of how Helm validates. Basically, some keys will convert from dashes to camel case. I guess I'm raising this so that uh people in America uh know that they have to choose their scripts I, don't think it will help. It will cause big problems.

C

The replaceable, Network I, think was pretty much requested by sap and it will probably be used by US, um but it's still a nice thing you can now bring in Easter or some other I think you will then be able to write your own networker and plug it in.

C

uh So that's the first one really more or less. It's notifying you about the breaking changes that will be a part of zero six zero, which will probably come out soon.

C

Yeah, if there are any comments.

F

They're also zero five came out since uh we had this meeting last time so that.

C

F

Thing happened: that's.

C

True, actually it's a big one right Amazon, it's.

F

Basically, it's basically uh yeah Amazon support, plus any other things that went in in the meantime, but yeah mostly Amazon support at the domains. Api endpoints are in there yeah. You can check the release, notes.

C

Cool stuff yeah guys this first one is not controversial, so maybe it doesn't need a discussion um which I shall move on to the second one. Then uh it's uh yeah we're talking about the approvision I, think we discussed that I think last week on the internal sync and we then machamped in in the issue uh saying that we should shouldn't remove that provision, because we wrote up a story uh trying to resolve some of the problems around our provision, suggesting to remove it and implementary Style.

C

By doing something else, like maybe delete the not that poor cold but the CF process, or something more Cube native. But then Martin said that uh some of the VMware stuff probably depends on the revision. We should maybe leave it there and you I, guess we're fine with this, but we were wondering whether that provision should actually be numbers that increment, because so far it that has been the interface.

C

But it wasn't working like it was flaking, meaning that the numbers could increment an unexpected uh amounts right, not one zero one, two three, but sometimes you you miss a number and so on. So we were wondering if it will be acceptable actually to convert this up revision to just a random good that changes on every restart.

C

Do you know have any thoughts on that.

B

Because my my thought on that is, like I feel like when we added that logic, we made a mistake and the mistake was that we partially copied the observed generation pattern as used in controllers all over the place, but we didn't fully copy it, and probably most of the flakiness is because we didn't actually do a very good job of fully copying. The generation observed generation pattern, so we kind of loosely copied it um that uses numbers and I.

B

Don't know if I guess the thing that we would lose if we go away from numbers is like you wouldn't know. If the storage thing is newer than your thing or older than your thing.

B

um Having said that, I'm not aware that we're relying on that anywhere like we don't actually compare these things to each other, I, don't think and I think we do. But operators might rely on that right, but I I guess just in general I feel like there's an established pattern of having generations of these objects and observe Generations in the status, and it would be nice if we could convert it to following that pattern explicitly so that we act just like a whole bunch of other objects that have controllers.

C

But it's a generation a number starting from zero. What does it actually look like.

D

Here's a dock for it. uh This has a monotonically increasing number.

C

I see yeah I, guess that.

F

Doesn't mean it means it can skip a beat basically, but it would never go back. Never.

C

F

D

That's just that's what it says so I assume uh that's very formatted.

F

um Api conventions, it's a convention I see because we've been assuming that having a number that keeps incrementing is just impossible.

C

F

What's the problem we observe now, what is it that sometimes it stays? The same is.

C

Still the same, and sometimes it's uh bumped too far, it was different, like it was flaking in different ways.

D

And and that's our thing right, the app revision that stays the same or gets bumped too far.

B

C

Yeah yeah: that's our thing that I'm talking about not I, don't have a lot of uh observations with observed. Generation, I haven't, haven't seen it much I, don't pay attention to it, but um yeah I mean maybe we can put it back in the controller and just let it Skip and then I guess. The test can be made more flexible to check that it's strictly greater than which will also make sure we don't repeat a revisions, because that's not good.

A

C

D

F

We can keep the.

C

Yeah go ahead, I.

F

Was saying like if we can keep the concept of our revision that it's better for everyone, because it means we have already have it it just doesn't work really well, if you can just make that what we already have work well, I guess that would be a win-win, but if we I think we've been assuming, we cannot.

B

Yeah I I think it might be interesting to go. Look at the code where folks have implemented this observed generation pattern because they might have already solved these problems right with something slightly different.

C

And I'm wondering, if they're, in an easier position than we are because it's taken care of us by some core controller of kubernetes. Although I don't know if that will be very different from what we're doing.

B

Yeah I mean we have access to that code too. Yeah.

F

Yeah, it says it's set by the system and monotonically increasing per resource it may be compared, such as for raw and wall consistency. What's wrong, r, a w or WAW raw I. Don't know, read and write re read after right.

D

You have to write.

F

And right after right right so it looks like kubernetes sets it for you.

B

F

And then you keep the and then what's what's the observed. So observing is another field.

B

Yeah so I mean I think they basically observed generation the gist of it. We have something very similar with our revision right. We observe the revision in our status, so I think the object we would just switch to using observed generation, and then we don't have to it means we don't have to take the burden of it. Increasing the revision.

F

B

Just use generation instead yeah.

F

Exactly I guess the problem is: if we try to maintain this counter ourselves, we will never be able, because we just the system, isn't robust enough, like we don't have enough guarantees.

F

Well here we, the system like kubernetes, is giving us a number. We can.

B

F

On I guess this idea: okay,.

D

Yeah I wonder uh we might still have to set it ourselves, I'm, not sure if they they do for us like the way that this is nested under conditions and everything.

F

So what they're saying is: okay, you, the system gives you the generation number and then you put the generation You observe in the condition. So you say: okay, this condition was set with this when, when I set this condition the value of generation was this and I guess an observer can say: okay, the condition is this, but the generation is not that anymore, so things might have changed. Slash probably have changed, I guess that's the idea. I don't know if we need all of that.

F

If we just need to find the PODS of the current, maybe we can just use generation, because we we just put it in the pods that when you want, because in the end, what we use it so that we can know which parts belong to the current generation of the app right, for example, for logs. So if you store that generation in in the pods as a label or something, then you just query for it and you're guaranteed it gets incremented.

F

The problem is, it probably doesn't get incremented when we want it to be incremented yeah.

B

F

Take a life cycle doesn't match the cf1.

B

But we could just like instead of incrementing, where we're incrementing it, we could just copy it into status.

F

Which means that number will probably keep skipping it will. It will not be account, it will be sure yeah, because the number will the generation would have probably been incremented many times since last time you restarted your app, but we don't care as long as it's a unique number. Yeah.

D

F

E

D

Even the good would be fine for the way we use it, but.

D

I'm not arguing against using observed generation for us with.

C

I'm just saying.

D

It should be fine if it skips.

C

Yeah, because the the benefit of the glitch, that is uh just a just, the controller, can default it or a default or can default it without much logic around it. But I guess copying the generation into the status could actually it's not very complicated and the skips are probably not going to be a problem and things can still be compared and all that and you can lean against a number that comes from kubernetes.

C

But then uh we want to sit on the upright and the app is something that is created by the API or the cubecado user. So where do we get it from.

F

C

In the metadata.

F

C

The metadata of what, because, if you're doing a controller that reconves a resource and turns it into another resource, you can can have the First Resource and and get its generation Oh you mean when the API creates it. We can copy it from there I see because yeah we in the controller can take it from from the status because kubernetes put it there for us. Is that what you mean.

B

D

I think so, even if they.

B

D

Put it there for us there's a mechanism at that point to get it and then start start setting. It I think like I'm, not sure kubernetes will put it in the status without us telling it to, because resources are free to put whatever they want in this status. But there might be something in the in the metadata.

C

Yeah yeah, it doesn't matter actually.

D

C

Yep yeah, this is actually this could work, I guess and we can preserve it as much as possible as a monotonous integer, but then like.

C

If you imagine what the restart endpoint does right now and if you take bumping the revision out of it, it's pretty much doing a no-op which looks weird, so we were wondering whether we should change this experience a little bit like have a cubecutive user, and you have to tell them how to restart it will be weird to tell them well, they needed to stop them, say this to start and that's it like it's you're, not waiting for a condition or anything you just saying it to another status and then back to the to to the first status, and it just looks weird so I guess we're arguing in the team whether we should just delete something because this might be like.

C

If you want to restart the project, deployment, delete the Pod and then then it gets recreated. So can we do the same with the CF process? Maybe from the aviation.

F

You restart an app, though right.

F

So if you want to restart a map, an app that has many processes, what do you do? Do you? You have to delete all of them. I.

C

Guess I have to do it mainly for each process, which is not ideal as well.

B

C

I guess the alternative is always to introduce some sort of condition that you can wait on. So you stop it wait, it wait for it to be stopped, and then you start it again, which is not the most yeah and.

D

Also to be clear, we're not deleting processes right, we're deleting the app workload for each process, because I I think if, if we start talking about deleting the CF process resource, then that will cause a bunch of bad things such as like that's where people say, they're like overwritten process commands and everything yeah.

F

Because they're defined in the Manifest, so if you delete them, you kind of.

D

They're they're defined.

F

D

The Manifest, but you're also able to use imperative endpoints to modify them further so like. If, if you delete them wholesale, then you.

F

Might you lose information, basically yeah, you.

C

Delete the Old State database they're.

F

Not completely reconciled from something else, yeah.

D

But the app workload that's derived from them may be something that could but I haven't fully thought through the implications there like it's there's, probably not the best, something with status and conditions that would tell it to roll is probably better.

C

You have an Explorer, so I guess we don't need to find a solution now, but we just wanted to know more about the revision. I think yeah.

C

This was useful, the things that we talked about, so we might reshape the Explorer a little bit then see what's the best uh user experience for restart, but for the revision, I guess I think the Observer generation I think was raised even before I think we're more as converging towards using this thing as the revision.

F

Replace your rail with its title: why not.

F

That's really neat.

C

C

So on to the to the third one in the the list, we were having some discussions around here. What our next epic should be after we release zero six zero and there were different uh ideas like maybe we should pick up the level annotation the metadata stories and finish that work as we put down earlier. I think Giuseppe had other ideas as well, so I wanted to discuss that with you a little bit uh if you may be have some good candidate for our next Epic.

F

Mostly I wanted to ask if we could like how much of the current uh us to do. We could just borrow from uh because I think, for example, the labels and annotations epic. We had picked it up and then we put it down because something urgent came up.

F

We could pick it up again, for example, there's another epic, which is the build and run workloads, epic, which has like a couple of stories left. So maybe that would be worth finishing Maybe it's because been on for a long time. um I think this is about Stacks possible, there's other interesting stories in there too. If you, if you're, not touching them any soon, we will probably we could probably just steal stuff.

F

Or stuff that I don't know makes sense that we think we have con enough context on the label. Annotations, definitely I think we should just finish it because it's been it's.

B

Just busy forever anybody can do it.

F

Yeah, no one and no one wants to do it's not fun, but.

B

E

F

Get done with it, we also had ideas like while working on that we had ideas on how to kind of Mom, let's say improve validation, because current validations have a bit.

B

F

We don't like the error messages, for example Etc. That could be another interesting piece of work, but it's not necessary for finishing the Epic. We could finish the Epic, what we have now and then and then think about that.

F

So if you see, if you see things disappear from that from your backlog, it's us I, guess just picking stuff up.

A

Yeah, it's very I think I got Instinct on that was labeled annotations too. Even though I know it's not the most exciting work.

A

Like it makes the most sense, it's like half done give or take.

F

Yeah that wasn't.

C

Yeah we have one more by Ram if we're done with this one.

A

Foreign, are, you, are you around.

E

Yeah I'm here yeah.

A

This last one's yours so.

E

Yeah I think um um it's been a while coming, but uh there hasn't been a proper sort of into three blog post on the cloud: foundry.org quote-unquote official blog about karishi um and I thought we'd either pick like either a V 0.5 or like a um six months of development into Qureshi. And so um you.

C

E

At a point where we are starting to think a certain way and build this out a certain way or um we could just pick on the epics that we're going to work next and what we've accomplished so far and um something like a retrospective of the past six months, and um you know what we can expect um in the weeks and months to come more or less so I'd love to get something on that team out there and and if anybody can like volunteer to help.

E

You know give the points or um you know, write it by themselves. Anything is welcome at this point. To be honest, so I'm happy to be the Scribe um and you know jot things down and get things going.

E

um But if folks have any ideas around that I'm happy to take those as well, there's um also like a few things that we could publish uh to external um Publications like the new stack or the container journal, or things like that.

E

um However, um the content and some of the you know, quotes and we'd love to have some input from the actual engineers and the PMs and the other folks that are working on this and um give it more of a personal touch. I guess so that's um really what I wanted. So, um let's you know together, publish something, um let's also try and get some quotes and other things that we can give to our PR team so that they can be placed um at the right places. Foreign for marketing purposes, mostly.

F

If you want to gather inputs, slash info like from the slack Channel or just opening threads, that could work, or we could just organize some sessions if you like I guess, if you have like specific ideas and specific questions, I think that would I think it's easy to, and the team is, is super available like having having some getting someone of us to some of us to to write the the post from scratches, probably harder but like if you need us to fill holes or just or provide you with uh information or stuff like that, I think that's that could be done.

F

Asynchronously with.

E

Slime, you can.

F

Have dedicated meetings I don't know.

E

Okay, I mean I, think.

E

uh Jot a few ideas down um and then depending on how that goes, maybe um towards the end of the week I'll try to pick a time or we.

C

E

Just you know get together on slack or something yeah and hash things out and see if we need a meeting, um but let me uh get a dog going and um I think it's easier to uh fill in gaps and uh get very specific inputs at this point, uh rather than get folks to like um sit down and dedicate time towards um composing like a whole piece by themselves. So totally agree with you there um so yeah I mean the general themes are um what have we accomplished so far?

E

um Where do we expect it to go in like the next six months or so, and uh anything specific that folks want to say in terms of who this is for and um how can it help like a Persona, a or a Persona B um like let's.

C

E

It help developers or how can it help I, don't know Java developers or how can it help like people writing stuff on, go and struggling to put it on kubernetes, or you know stuff like that. So um I'll come up with a few specifics. We can obviously change it if it's not accurate enough um and I'll come up with some generic stuff as well. That people can just comment to or add their inputs to, and hopefully that will create some something that's composable and Publishing a publishable or something is.

F

That yeah I think that the dogs work really well I. Think last time we did it for maybe the conference, but like we had to come up with some. Maybe uh what was it some fly out or some some material that.

A

F

Wanted to give out to the conference and yeah we all.

A

F

It yeah and we we converged to something so we can use the same model. I think that works pretty well, because so that everyone can can jump in asynchronously, yeah.

E

F

All scattered across time zones and stuff.

E

E

Sounds good I'll get that going then and I'll I'll start shopping later on.

A

Any other late breaking topics.

A

Okay, well, there's nothing else. We should get out of here.

A

All right, I'll see y'all later.

C