Cloud Foundry CF on K8s Forum, 6 Sep 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Cloud Foundry On Kubernetes Forum Call 06 Sep 22

Description

[KB] Manifests and Processes
What's the expected behaviour?
read the code
ask the App Runtime Interfaces team
ask Tim
App Manifest Attribute reference
we could have a similar document specifying which things are supported in Korifi
[GC] Docker lifecycle support proposal
[GC] Helm option in the Distribution proposal

A

Okay, I will do it. We have exactly one item uh by kieran about manifests and processes.

B

Okay, um yeah, giuseppe- and I were looking at us today, um just slightly curious about the existing functionality in cf of what happens in manifests when you get rid of processes from them.

B

So it looks like if you create a manifest with process a and process b and do cf push with it. You go and get process a b and then the surprise web one.

B

If you get rid of process b from the manifest and push again, it stays there. If you add, if you get rid of a and b and replace it with c and do a push again, you'll end up with web a b and c, um and it doesn't appear to be anywhere in the cli to delete those extra processors.

B

um So it's like from the the kate side of things you'd expect that to be like a declarative um opinion of what's on the system, and I would kind of expect the processors to be deleted, um just wondering if that was the intentional thing on the cfo vms.

C

I'm guessing it's intentional, but tim might have some more context on that. From the cloud controller perspective, I think a similar thing happens with environment variables, where it's they'll they'll be upsetted into the set of environment variables for the application, but if you remove them from the manifest they still stick around because you've got other avenues to configure them.

C

So you have to unset them manually. If you don't need them anymore,.

B

Now my processes you'd, have to do a curl, which is a bit crimp.

A

Yeah, I think the main issue here is that there's no super rigorous, like speck of how the manifest will behave like or I haven't, found one that says. Okay, you know you remove something you stick. It will stick around but like, for example, for roots we've just completed a story that is for exactly the opposite: behavior like when you take out the uh default root flag or something or the no ru or wait.

A

When you flip the the no root flag it will, it will, if needed, delete the existing route, which is an example of the clarity of behavior where, like, if you take stuff out of the declarative of the declaration, things go away because the reality is modified to reflect that description.

A

That declaration, so I guess the trick he the tricky bit more than issues with the behavior. Like I'm sure there is good reasons to behave in both ways. I think the issue is: how do we figure out what the behavior is, what what's the behavior that users expect so that we can reproduce it like? We can replicate it without just either reading the cc source code or potentially just do lots of pushes with lots of lots of manifests and kind of reverse engineer it, but yeah, maybe maybe tim, has some insights.

A

Otherwise, I guess we'll have to read the code. It's probably the easiest thing.

C

This isn't an unreasonable request of the app runtime interfaces working group either to have some clearer definitions about the intended behavior.

A

Right, I should should I take some notes here. Maybe I should.

A

A

Now that's the right spelling of behavior. Sorry suggestion is wrong.

A

The current stories we're working on are about just kind of augmenting the existing behavior more than anything else. So it's not like. We want to change it for now, but we will have to understand, understand it because we'll have to change it a few times so yeah. I think that would be valuable so that it's really like, I think, every other endpoint that we implement is very easy to kind of implement in a way that tracks cf pretty closely because it they're very straightforward.

A

It's like and like documentation is kind of exhaustive, but like this is an endpoint that is actually an avenue to a whole. Almost to incomplete language inside cf, like manifests, can be of arbitrary complexity and then allow you to do all sorts of things.

A

So it's it's that time. It's one end point with this massive surface, it's very which is very hard to cover, and we don't have to cover it all, but the one that we, the things that we do. We should do the same way as you have. So that's a bit tricky.

A

uh Okay, yeah, like another point, get going well.

D

I know I was gonna say too, I think more specifically for the asthma runtime interfaces team. I think specifically we're asking them to be more declarative around their documentation around like what they're you know what, if you know it, this is more of like I guess, a higher level ask from of them than it is the specific of this situation. It's more like hey. Is there a chance?

D

You guys can be a little bit more um specific in some of your documentation around this because, like you, like, you said, like you can't find this, you can't find the answer in the documentation and that it's kind of a bummer.

A

It could be an opportunity to just contribute back to see to the cf dogs, because in this case we just want to do exactly what cf does. So, it's not karif's specific behavior yeah. I don't know if it's some, because it's almost its own thing so like it could. This could be part of the api docs, because in the end it's an im. It's it's I'm hitting an end point and I'm sending some input and it should. But it's it has its own schema.

A

It's the ammo instead of json, like it's kind of special in many ways, so there could be room for like some sort of cf manifest manual or reference where, like we really go deep into it, but it would be a lot lots of work, which is, I guess,.

C

A

There's already.

C

A page in the docs that collaborates on that, I think it just doesn't explain like what happens when you remove stuff.

A

There's a yeah there's an app manifest attribute reference yeah.

C

A

Is quite thorough already, so maybe it's a matter of just augmenting this or reading it.

C

I would be willing to bet that they're they're not specific enough about what happens when you remove values right from things that are list or set valued.

C

I mean maybe a good test would be. Do they say anything in the environment variable section about what happens when you remove environment variables.

A

Environment variables, you must name, do not use yeah, they don't yeah, I don't think they do but yeah. This is good as a starting point and uh even our doc like we, we could also have a document that tracks that, in the similar way, we have a document that tracks the api dock. Well, like we for each item, we say this is fully supported.

A

This is partially supported beyond support this and that we could have a similar document for this, where we document we properly document what we support in the manifest, because now I think there is a brief paragraph in the in the api document where we say okay, we only support these fields, but we could be more thorough. So that's another good thing, okay, so this is the app manifest attribute reference.

A

I could say we could have paid documents, uh especially.

A

A

B

I mean I just wonder if it was intended like that, though, like we can document what exact behavior is and help with that, but I think.

A

It could have just happened.

B

By accident, maybe.

A

Yeah but then good luck changing it now like if they change it in cf, like in in traditional cf like everyone's manifests, will suddenly start behaving differently and potentially we'll start deleting stuff from everyone's.

A

You know foundations and it's not going to be fun, so I suspect, even if it not. If it wasn't intentional, I don't think they're going to change it just because it would be so disruptive unless they introduce some v2, manifest, for example, and then they tell you okay, the scheme is actually the same but like if you flip, v1 to wii, 2 will start deleting stuff, so it kind of makes it deliberate.

A

And I hope they don't do that, because it will be an item to support for us if we had to support two versions of the manifest. So.

A

Okay, uh next I've put an item on this yeah like yet another puzzle that I started to write about darker life cycle.

A

Just a heads up that I've started doing it today I was playing with kieron, so I couldn't carry on with it. It currently mostly contains a description of what the current behavior is and some doubts. I had that I've put in comments for people to potentially answer and then what I plan to do is to describe in detail how we could implement this and then, if everyone is, is, uh if everyone agrees we can. We can create the stories.

A

I think we have a pretty straightforward path towards support and what's what's good about, kurifi is that uh basically container images for us are kind of this lingua franca like every way we no, it doesn't matter how we build the app, but they all boil down to the same artifact type, which means from pa from one point onwards.

A

It's there's no changes to make like in cf the droplets derived from build pack. Apps are different from container images, so they need to treat them separately all the way down to execution. But uh for us, that's not the case once you've once you get to a container image. What happens from that point onwards is shared because both parts in the end end up building container images and they're slightly different container images like there's some details.

A

That vary because the build pack container images have this like multi-process thing where, like they, they have some metadata attached about all these different types of processes that can be run, while usually docker images only have one process so we'll have to add some conditionality in or at least like support, both cases in but other than that.

A

Everything else should be relatively straightforward and the generic interfaces we have in place so the build workload, the workloads we won't need to use for docker images, because they're already built and run and the app workload already takes an image as an input, so that doesn't have to change, which is really which is good news.

A

So I'm confident that we can do this relatively easily, which is why I picked it up in the first place. I think it's a change that has a good impact because it allows you to push your docker apps with via the same tools you use for the other apps, and it should be relatively straightforward to implement.

A

Although this will come after the other two epics, so I don't know where we start.

A

Oh and another thing uh I think, we've.

A

We've added a new option to the distribution proposal to which, which is about basically importing everything, to help and basically ditching customize completely uh so now the proposal has these two options and people can kind of express our preference, and hopefully we can all agree on one of the two and then so that we can proceed.

A

uh I think we had the original deadline set to maybe today or something but given there have been so many changes. Maybe we could wait another week or two and see what people think.

A

Let's see if I can find a proposal so that I can link in the document.

B

Yeah, so we've just done it.

A

Beautiful, even better nice.

A

So yeah proposals proposes proposals, uh I'm done so do we want to wait for tim or like or if there is nothing else we can also call it unless tim had anything urgent to talk about which I don't think.

D

So didn't sound like he did.

A

In that case, we can just call the meeting if everyone is happy.

D

That's fair yeah. We just.

A

D

Slack about the manifest question see if he has thoughts.

A

Yeah, why not cool.

A

Okay, uh thanks everyone. I guess I'll see you at the next one. Thank you.

D

Thanks everyone bye.